Story Kick-offs

What is it?

• A joint walkthrough/explanation of the story by the product owner with the pair of developers who will be working on it; right before development starts
• The developers (and others) use this opportunity to get their questions answered and task out the story or re-validate the tasks.
• A final check-point to ensure that the scope of the story has not changed or if it has, what to do about it.

Why use it?

• Time Lag - In a Sprint Planning Meeting, the team ends up discussing the various stories that are likely to be picked up next. There might be a time lag between this discussion and when the story is actually picked up which leads to a loss of context. This is usually due to real world factors like carried over stories, critical bug fixes, leaves etc.
• Lack of deep dive - In addition, during an IPM, the in-depth story deep-dive may not have happened (this depends on the team and the project) due to a number of reasons like time pressure, pending decisions etc.
• Change in context - Even if a deep-dive has happened and technical tasks have been detailed out, the context may have changed between the IPM and the time the story was actually picked up.

A story kick-off gives the opportunity to both refresh the need as well as perform a more in-depth analysis/validation of the story.

How to do it?

Pre-requisites

• Story - The Product Owner should have the story ready with the analysis done. This means that the goals, users & value of the story should be clear. Acceptance criteria & assumptions should also be present. In addition, mock-ups, data, scripts etc may be required depending on the context of the project.
• Participants - Ideally, the pair of developers who is going to work on the story and the quality analyst(s) who will be testing it are required at a minimum. Sometimes, there might be the need to bring the User Experience designer or UI Developer or people with specific skill-sets relevant to delivering the story. The Product Owner or the person who has written the story should be present to do the kick-off.

Time

• Duration - If this is the first story in a feature, the whole team may need to be invited so that everyone is on the same page. Usually, the first few stories in a feature tend to require a lot more preparation and time to explain. Once this is done and the team is familiar with the feature, the time taken reduces quite a bit. Do the kick-off before the developers actually start working on it.
• Timing - A common mistake is to do a kick-off at the end of the day, before lunch, before an IPM or before either of the developers have finished working on their current story. If this happens, it means that some portion of the value of the kick-off is diminished since the purpose i.e. focus on the story, is diluted.

Execution

• Explanation - Walk the developers and the QA(s) through the actual story narrative, clearly explaining the context of the story as well as the acceptance criteria
• Supporting Artefacts - It might be better to keep the application open in a window, the story itself in another with supporting materials like sequences etc. in another. Have pen and paper ready or be next to a whiteboard because nothing beats an explanation with writing/drawing. Pictures of your collaborative explanation can be taken and attached to the story if this is of value.
• Questions - Typically, there will be questions even for the most simplest of stories. Most of these questions can be answered easily if the analysis is clear. There might be minor modifications to stories based on the inputs from the developers/QA(s). Conversation outcomes should be captured in the story for later reference.
• Roadblocks - Sometimes, there might be questions which require more analysis or conversations with other stakeholders. In these cases, the team can take a call on whether to proceed with the story while excluding scope related to the question or parking the story itself until the questions are answered.