Sprint Planning

The focus is on the most important Stuff first

  • Realistic
  • Define a sprint goal
  • Commitment of the team

Why

Sprint Planning is done at the start of every sprint in order to create focus of the team on the most important user stories and bugfixes.

Prepare for success

  • The key to successful sprint planning is proper Backlog Refinement. Preferably this is done in separate sessions during the sprint, and if not, you’ll have to do it during sprint planning.
  • The availability of each team member is known.

How

The first part of the sprint planning meeting is about the Product Owner[1] and Development Team being aligned on the “why and what” of the individual user stories. If Backlog Refinement[2] has been done already on the stories on the top of the Product Backlog[3], this part will be done quickly. Otherwise, follow the same format as Backlog Refinement to reach that alignment.

The second part of the sprint planning meeting is about the team selecting the work they expect to be able to get done in the sprint, committing to a sprint goal, and making a first plan on the “how” of execution. A good format to execute this second part of sprint planning, is:

  • Scrum Master starts dragging user stories and bugs from the top of the product backlog to the new sprint one by one. Any of the developers will express doubt when (s)he has it.
  • Team will take a confidence vote (1 finger = no confidence, 5 fingers = full confidence), and discuss.
  • By adding or removing stories/bugs to/from the sprint (while maintaining the order set by the Product Owner), and repeating the confidence vote, team finds the balance.
  • Product Owner can participate in this by negotiating with the team about the scope of certain stories.
  • Product Owner and team define a sprint goal together: the reason for undertaking this sprint (this will help setting priorities during the sprint).
  • Team commits to the sprint goal and to working together constructively and transparently. They will give it their very best to reach the goal, and will communicate any doubt or risk as soon as possible to the Product Owner and the rest of team.
  • Team discusses how they will execute this sprint. This may require them to define tasks per user story[4], or more general chores. Some sprints need a technical session for discussing the software design and how User Stories will be built within the software stack.

Definition of Done[5]

  • Selection of user stories and bugfixes for this sprint is done
  • A Sprint Goal has been formulated
  • Development Team is confident they will be able to reach the goal
  • Team commits to the sprint goal and to working together constructively and transparently

Real Life Example

At the start of a Sprint Planning meeting for a parking app, the Product Owner explains that one user story needs to be changed a little bit due to some feedback of a stakeholder during the Sprint Review. This changed story is directly discussed and estimated, and actionable for the sprint. Other than that, all the user stories at the top of the Product Backlog have already been discussed during the latest Backlog Refinement sessions. The user stories that are about to be selected for the sprint, include:

  • manually enter a license plate
  • check at three parking providers
  • display ticket information

When the Scrum Master uses the technique of “Confidence Vote” to quickly identify the confidence that the development team has in this selection, it turns out that the confidence is low. The main reason for this proves to be the number of integrations with parking providers that need to be done. The Product Owner explains that for him the Sprint Goal would be to make a complete round trip: enter the license plate, check at least one provider, and show the result (not necessarily all information). The team advises the Product Owner to move the stories for two of the parking providers down on the backlog. He follows the advice, and the team selects the following stories:

  • manually enter a license plate
  • check at one parking providers
  • display ticket information

Based on the Sprint Goal the team knows that for the last story it is most important to show the result of the check, not necessarily all ticket information.

Notes

  1. Product Owner - The Product Owner plays a crucial role in the development of a great software product. He or she is responsilble for maintaining the Product Backlog.
  2. Backlog Refinement - The goal of Backlog Refinement is to be prepared for the upcoming sprints.
  3. Product Backlog - An ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.
  4. User Story - A user story describes a functional goal from the perspective of an end-user. Who wants to do what with the product, and why?
  5. Definition of Done - A shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.