Story kick-off is such a natural ceremony/ritual to me that I tend to forget how uncommon it may be outside my organization. Trying to find more information on it, I realized that even if there are some articles on it, the origin of a story kick-off is not as obvious. There’s no one name or organization that I could assign as pioneers. The one thing clear is that story kick-off is very often considered to be an agile ceremony. I fully agree with this description because agile is all about collaboration and people.
Way too often in software development the main problem is unvalidated assumptions. This is why I really like story kick-offs: they’re a chance for us to verify if our assumptions are actually true or not. This helps us avoid rework and build higher quality products before it’s too late.
What’s a story kick-off?
Story kick-off is an agile ceremony in which developers who are about to start working on a user story (or another work item) discuss the story together with other roles from a team like business analyst (BA), quality analyst (QA), experience designer (XD), or even the product owner (PO). I have seen other developers attend these meetings, too, just to be on the same page in case rotation happens or if they’re interested in how the story will be tackled.
The goal of a story kick-off is to have a final alignment on what is going to be implemented. In this usually 10-20 minutes meeting the group takes a look at the acceptance criteria, clarifies any unknowns if there are any, and makes sure to confirm that everyone is on the same page.
Why do it?
If we are working with a mindset of building quality in and want to seed natural collaboration in the team, we need to make sure all roles are involved early on, and that we have as little misunderstandings as possible. Developers may ask BA to clarify what was meant with acceptance criteria or talk through how the testing will be approached with the QA.
In the past, I’ve seen teams skip the story kick-offs and then get the work moved back because of misunderstood requirements.
For example, once a team was working on a tool that involved a login. Acceptance criteria stated, “User logs in and sees this”. After finished development, we realized that for developers who created this feature “user” meant any user, so they created their own auth service and assigned an admin user. What the business analyst and product owner actually wanted was to log in with their own accounts using the auth service of the organization. It was all a big misunderstanding that could have been avoided if we had walked through the story before it was implemented to make sure the expectations will be met.
What about story refinements? Isn’t that the same thing?
You may be doing story refinement or grooming sessions where all the team already takes a look at the stories, provides feedback, and collects/answers open questions. That’s wonderful. Story kick-offs and story refinement sessions are not mutually exclusive. They both can happen and have different benefits. If story refinement sessions take place in your team, story kick-offs act as quick refreshers that go super smooth. Also, when we pick up a story for story kick-off we expect it to be in good shape already and story refinement provides that. If the story is not in a good shape, then we have a higher chance of a story going back to analysis and not actually getting started working on after a story kick-off. It’s better to have more context and better understanding of the story than too little and fill in the gaps with assumptions.
How to effectively run story kick-offs?
Alright, so we decide as a team to start doing story kick-offs, yay! Let’s say a user story is ready to be picked up by a developer pair. They announce that the story kick-off will happen now. A few other team members apart from the developer pair who is going to work on it show up. How do we make sure the story kick-off is actually useful?
We need someone to facilitate it. In teams who are familiar with the ceremony, it comes naturally, almost anyone can take on that role. I’ve seen the facilitation done by BAs, QAs, or a developer who is about to implement that story. Yet if the ceremony is fairly new to you, make sure to guide your team. As a QA, I often tend to take on the facilitator role.
Steps for a successful story kick-off
-
Share the story on a screen (either physically or remotely one person shares the screen, usually who is about to work on it).
-
Walkthrough acceptance criteria: read it out loud, the business analyst, or whoever wrote the story can explain in their own words the context as well and summarize the story.
-
Raise any questions/concerns. Write down the discussion results. If there are some blocker questions then the story may go back to analysis before they are answered, but if the analysis process completed before - it should be very rare for this to happen.
-
(optional) Go through a set of questions that aid you usually.
For the last step, I’ve found that teams can benefit greatly from a set of questions they always go through. In each team I’ve been in that set of questions evolves depending on the team and is never set in stone. If one of the questions starts making no sense, we can easily stop asking that. If we find that working together we always step onto the same mistake and need a reminder on story kick-offs, we could include a question there. Story kick-off question list is a living document.
I like to create pretty visualizations that we could have both physically and digitally that I tend to call artifacts. If we’re in the office, we’d print it and have it in multiple places so that developers could just have easy access to the list and get reminded of it. Here’s an example of a question list for kick-offs I’ve created using canva.com.
Example question list to aid story kick-offs
From more than 2 years of using story kick-offs, I’ve seen multiple questions in this list change, yet, the number 1 question proves to be always useful. How once the story is done we’ll showcase/demonstrate it? Explaining in your own words the business functionality side of things can unravel a lot of misunderstandings. Also, as a QA, I just love asking questions #3 and #4: it’s a chance to clarify that we are not pushing tests or monitoring to a later stage and include it as early as possible.
Conclusion
Story kick-off can become a vital part of a cross-functional team’s work. It helps the team to align on the work about to be done and avoid misunderstandings.
For every team, the decision to do or not to do the story kick-offs, in the end, leads to the question if they bring value. If they do bring value, they also need to be context-driven and adaptable based on the team’s needs.