The Kick Off

What is this?
This document describes an internal(team) designed and agreed mandatory rules for the process that just precedes the development of a story, This process is commonly known as the "Kick Off".

Why?
The main reasons for this are:

• to make sure that the team is aligned/understands the story that is about to be developed
• distil the requirements given to the team by the business analyst and early spot errors in them
• revisit and adjust the scope of the story if necessary 
• create a mandatory repeatable process so the risk of early introducing an issue is less
• agree upon work that need to be done

THE KICK OFF

1. Read the story description independently
   Regardless of if we work in a pair programming environment or not, we(each member of the team individually)  will take some time in our own to read the requirements that were written in the ticket management tool(e.g JIRA). The time this first glance takes is somewhere around 5' and 20'.
2. Gather questions
   We must understand that the kick off is a team activity. We are not expected to understand everything in the requirements at 100% neither to know exactly everything that needs to be done and how it should be done. We will write down all our concerns, doubts, assumptions, questions, etc... in a list and we will keep it for the time of the kick off. Individual solutionising is not an acceptable behavoir.
3. Craft a task proposals list
   Now with our pair programmer or by our own if we don't have one, what we will do is to write down a list of proposed tasks, based on our understanding of the story so far. This list is just a draft, not a final decision. The purpose of this draft is:
   - To make visible to others our views/sense about the story in hands.
   - To make it easier for the developers to spot task parallelisation opportunities.
4. Empty acceptance test
   An empty acceptance test(just text in the Given When Then format) will serve as a conversation starter during the kick off. The propper creation of the real failing acceptance test will be done as an independent task, later since only when all is clarified in what regards to requirements, we can write an accurate and meaningful acceptance test.
5. The Kick Off
   At the kick off all the team gathers and look together at the story. The BA will start by giving a brief summary on what is the story about. Then the developers will show the empty acceptance test they've written. Now is the time to use the questions, assumptions we gather initially. If any discrepancy exist, it will be clarified by the team and the acceptance test will on spot be corrected. At this point, the story is considered to be kicked off with the team(but yet not officially marked as started).
6. Dev's talkWhen the kick off is complete and we know exactly what needs to be done, we will huddle with the rest of the colleagues to distil the proposed task list we made and agree on what tasks we can parallel. It is highly likely that after the kick off toke place that initial draft is no longer accurate at 100% so the devs will revisit it and distil the final version. This final task will be published in the same place where the requirements were published, so the progress of the story is transparent to everybody.
7. Start development
   The developers will now prepare their tools for development(e.g rebuild local DB, synchronise VCS, awake zombies...). When this is complete the developers will move the story into "dev in progress" and development begins. Good time for a coffee now ;p