Quality as a Team Responsibility (Part 2)

In my previous article, “Quality as a Team Responsibility,” I touched upon how the addition of Shoulder Checks in the agile development process helps improve the overall quality of the product in the end. I presented the following diagram to show how Shoulder Checks fit into the process.

This article will cover User Story Kick Offs as an additional step in the agile development process that may help larger teams align on more complex features, and in turn increase quality output as a team.

What is a User Story Kick Off?

User Story Kick Offs (similar to “Three Amigos” or “Design/Dev Boxes”) are short meetings (10–15 minutes) that Developers initiate just before they start to code a feature. These meetings normally include a Developer, QA, Designer (if applicable), and Business Analyst (BA) or Product Owner (PO). The overall purpose of these short meetings are to align on requirements and flows, and to ensure that everyone has what they need to start development on that feature.

“Talk about the concerns of the ticket be it testing, business or user ones. Note down on the ticket any important points.You are testing assumptions and the shared understanding of the work. Clearing up misunderstanding early on saves time later on fixing defects and bugs.”-Thomas Shipley

In a scenario presented in my previous article, there were multiple iOS and Android Developers working on a particular mobile application. I discovered that the UX was executed differently between iOS and Android. Additionally, Designers would end up repeating explanations on animations or UX to the various Developers working on a feature.

In order to address this inefficiency, User Story Kick Offs were born into our delivery process. The process would add a quick Zoom session before a Developer started each big feature to make sure we were all aligned and had the required tools. As a QA, this allowed me to plan how I would test a feature, determine what I needed and estimate the time required to test this feature earlier in the process. At the same time, this helped the relevant team members working on this feature to be aligned on how and what is supposed to be implemented.

How it Works

In my experience, User Story Kick Offs are the most useful when working in very large teams with multiple platforms. Here’s how it works:

• Developers will initiate a User Story Kick Off just before they pick up a JIRA ticket and start coding. They clarify any questions around the feature they are building and ensure they are aligned with backend implementation. They can also go through their interpretation of the acceptance criteria.
• Ideally, the session would include all Developers working on this feature (i.e., iOS, Android, Backend).
• Developers discuss the technical details and implementation strategy.
• Designers present prototypes, screenshots, video recordings or animation and will walk them through with the team to ensure everyone understands the flow.
• QAs strategise how to test with Developers and ask for test data. QAs can also present test cases they are planning on testing and get them reviewed by Developers. This is also a chance to discuss the risks, edge cases, negative cases, test data, and automated tests requirements before implementation.
• PO/BA will ensure that the requirements are understood and aligned.

Hot Tip: Anyone in the User Story Kick Off (I normally did this as the QA) can take down notes and post it in Slack to ensure no details are forgotten after the User Story Kick off.

Another example of a User Kick Off summary:

Coming out of the User Kick Off, the relevant team members should now have a clear idea on how to implement a feature, how to test it, and how it is supposed to look and interact.

How is it any different from sprint grooming?

You might be wondering, “Isn’t this what Sprint Grooming is for?” On larger projects, imagine having 13 people grooming multiple stories for two hours remotely. It’s human nature to lose your sharpness and even interest over this extended period of time. In many of the grooming sessions I participated in, someone would ask a question and there would be complete silence because everyone stopped paying attention.

How 2 hour grooming sessions are like

User Stories should be discussed and groomed enough to be able to estimate effort (or point values) in Grooming sessions but getting into the smaller details can be tough during long meetings with large groups.

User Story Kick Offs also allow team members to remind each other of some small details that may or may not have been covered in grooming. In the Simple Push Notification User Story Kick Off example provided above, we were able to discuss how to test the push notifications. Additionally, we found that Android may have needed its own custom icons. Ideally this would’ve been discovered during Grooming, but it’s not always certain that we will always be able to cover everything during those sessions. Having these additional User Story Kick Offs provide another layer of a quality gate.

In the T&Cs example, the backend engineers were able to coordinate with the mobile Developers the URL of the endpoint they would be creating and the parameters for mobile Developers to use.

How I’ve seen it benefit

Overall, this should help with alignment cross platform and cross teams. There should be less misunderstanding of user flows, implementation and test strategy. The addition of User Story Kick Offs may reduce the time in the Shoulder Checks since most of the acceptance criteria and different scenarios have already been closely discussed among the relevant team members.

For Designers, User Story Kick Offs for bigger features allows them to present the complex flows and designs again closer to development. They can point out nuances and specific design notes to the targeted Developers working on this feature.

For Developers, this automatically sets aside 10–15 minutes for every big feature where they can discuss with other relevant developers how to implement this feature and some technical aspects. This also allows Developers clarify design/requirements and have it fresh in their mind as they are about to start development shortly after a User Story Kick Off.

As a QA, the addition of User Story Kick Offs encouraged me to research and/or at least think about test cases earlier on because I wanted to be prepared with my test cases and questions to discuss at these User Story Kick Offs. Ideally QAs would start writing test cases at the start of a sprint. Realistically, writing test cases either comes right before the feature is ready for testing or even sometimes after it has been tested due to time constraints. Additionally, I had less clarification questions during Shoulder Checks or while I was testing because this feature was discussed in great detail during the User Story Kick Off, which wouldn’t have been that long ago in the process.

The increase in team collaboration in the development process should help produce a better quality product that meets the requirements or business needs of the client.

Tips

• Try and investigate a ticket before the User Story Kick Off, and come prepared to discuss your questions, testing notes, strategies, and user flows.
• Time-box it.
• Write up a quick summary of the important things discussed during the User Story Kick Off and post it to the team so nothing is forgotten.
• If anyone feels that a feature is big enough to do a User Story Kick Off, call it out during the Sprint Grooming. A Designer may feel that they have some nuances to describe and go through with Developers.
• As with shoulder checks, keep this flexible. For example, usually a Developer would initiate these User Story Kick Offs. However, in the beginning I sometimes had to initiate them to get the team use to adding and initiating User Story Kick Offs.