fbpx

How to introduce Story Kickoffs to your team

You may have heard of an Iteration Kickoff, but how about a Story Kickoff? Essentially, a Story Kickoff occurs when a Story is ready to be started on. The team gets together for roughly 10 minutes to discuss the details, and leaves with a clearer understanding of what is required of the Story.

This sounds great in theory, but how does it work in practice, how can it be introduced to your team, and why would you want to?

 

Who is involved, and who runs the Story Kickoff?

The Story Kickoff session will generally be facilitated by a Business Analyst, though some teams may agree that a Developer will run the session. It is the responsibility of the facilitator to ensure everyone that may have an input or provide some insight into the Story is present. This includes: Business Analysts, Developers, Testers, Product Manager, User Experience Designer… and anyone else that should be involved. It is important that everyone is present to ensure time is not wasted on repeating conversations, but also to avoiding missing any details and seek clarification to successfully kickoff the Story.

 

How is a Story Kickoff run?

Running the Story Kickoff workshop will depend on whether your team chooses to write Acceptance Criteria before or after the Story is started within the Iteration.

If Acceptance Criteria is written before the Iteration is started then the following processes should be used:

  • Walk through Wireframes and read through Acceptance Criteria
  • Go to a Whiteboard and list out what the Story covers (Refer to a real life example below)

The aim is to gain clarity and to ask questions to determine if any details are missing.

Alternatively, if your team has decided to elaborate Stories during the Iteration, then the approach will need to vary. Some details may be elicited and analysed by the Business Analyst beforehand, but the premise is that the Acceptance Criteria will not have been written as yet. The main approach is to identify what will be covered by the Story. The In and Out exercise (as shown above) could be used in this instance. This is to give everyone a basic understanding of what needs to be done, so that work can start immediately. Acceptance Criteria will be written after the Story Kickoff, and the Business Analyst will update the team when it’s ready.

 

What do you discuss in your story kickoff?

Although I’ve briefly covered how the Story Kickoff is run, what is specifically discussed?

  • What is this Story about?
  • What does this Story cover (and what it doesn’t)?
  • Review preliminary work done, and identify changes from what was originally planned (Reference 1)
  • What are some of the detailed aspects of the Story, and have we missed any Scenarios?

It’s important that everyone is clear what is required by this Story when the Kickoff is finished.

When can you start, and why would you want to start?

A great time to agree on using the Story Kickoff is during the initiation/inception phase of the project, but this doesn’t have to be the only time and place. You could raise it as something to try during your next Retrospective, and introduce it at the start of the next Iteration.

So why would you want to start holding a Story Kickoff?

  • To avoid confusion as to what the Story is about – This is particularly important in Software Development where context switching is a regular occurrence, and the team is constantly moving onto the next Story (Reference 1)
  • To avoid missing details in the Story – Identifying missing details before work starts, which will reduce the amount of time wasted (Reference 2)
  • To avoid rework – 45% of project costs industry-wide are rework! (Reference 3).

Story Kickoffs are a short, sharp workshop with the team to understand the details of the Story, and ensure everyone has all the information they need. I have used them successfully on my projects and feel they are an essential piece of the Agile ceremony with regards to Acceptance Criteria clarity. I’ve also listed a few of the reasons why you would want to introduce Story Kickoffs, and how to do so. What do you think? Do you see the value in introducing Story Kickoffs to your team?

 

Further reading:

 

2 comments

  • Steven Wadley

    Hey Ryan – how do you relate the story kickoff to what you went through for the story estimation prior to iteration start? Presumably the stories are somewhat elaborated prior to iteration start otherwise your sizings and expected increment may be off target?

    • Ryan McKergow

      Hi Steven,

      It really depends on how your team deals with Story Estimation. My preference is that all known Story Cards are estimated during your project initation/inception phase. This is to give you an idea how long you initially think the project will take, and assist with release planning.

      I would also encourage Story Cards to be re-estimated at any point in the project, if the team feels as though they didn’t understand what was covered in the Story Card. This could either naturally happen at Iteration Planning when you are talking about what to work on or the Story Kickoff when you are talking about the details of the card. The realisation that a Story Card is under-estimated if the Story Card has been elaborated prior Story Card being started may be easier during these sessions, but you will never really know how long something will take until it’s actually happened.

      As much as under-estimating Story Cards and having to report this to your Project Sponsor or Steering Committee may be disappointing (or even scary), it’s important to be honest with them, and let them know what is really happening in your project. That way they can make an informed decision of whether they need to increase time, decrease scope, or add additional resources.

      I hope this helps! There have been many, many blogs written on Estimation, and it’s not an easy topic to cover.

      Cheers,

      Ryan

Leave a Reply

Your email address will not be published. Required fields are marked *