Sprint Planning

Sprint planning is a time-boxed working session that lasts roughly 1-2 hour for every week of a sprint. In sprint planning, the entire team agrees to complete a set of product backlog items. This agreement defines the sprint backlog and is based on the team's velocity and capacity and the length of the sprint.

Responsible Entity- Scrum Master

Frequency- Day 1 of the sprint

Output- Sprint goals, Sprint backlog, subtasks and planned capacity of the team members

Sprint planning typically involves the entire team.

A product owner identifies the candidate product backlog items and their relative priorities, as well as proposes a sprint goal.

The team members determine how many of the product backlog items they forecast they will be able to complete and determine how they will deliver those product backlog items.

A scrum master or coach typically facilitates sprint planning in order to ensure that the discussion is effective and that there is agreement to the sprint goal and that the appropriate product backlog items are included in the sprint backlog.

How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

Sprint planning is typically split into two parts:

Part 1 – Scope

The team selects which items from a prioritised list of ready product backlog items (usually expressed as user stories) they forecast they will be able to complete during the sprint.

Here’s a sample agenda for the first part of sprint planning:

  • What is the goal for this sprint? Use this as a decision filter to determine which product backlog items to include in the sprint.

  • What product backlog items are ready and contribute toward the sprint goal?

  • Who is available for this sprint? Identify any vacations, holidays, other activities that will impact everyone’s availability during the sprint.

  • What is the team’s capacity based on everyone’s availability

  • What items will the team include on the sprint backlog based on the sprint goal and the team’s capacity.

  • How confident does the team feel that they’ll be able to meet the sprint goal.

Part 2 – Plan

The team discusses in more detail how they will deliver the selected product backlog items. This may (but does not have to) include identifying tasks for the product backlog items, whether there are any dependencies between the items, and signing up for the initial product backlog items that each team member works on .

Story Estimation- We follow Planning poker technique to estimate the stories. Teams starting out with story points use an exercise called planning poker. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. Then everyone holds up a card with the number that reflects their estimate. If everyone is in agreement, great! If not, take some time (but not too much time–just a couple minutes) to understand the rationale behind different estimates. Remember though, estimation should be a high level activity. If the team is too far into the weeds, take a breath, and up-level the discussion.

Story Estimation for Distributed scrum teams: Working with a distributed scrum team there is hesitation and bogging down in details - do they wave fingers at the camera, shout out estimates, use a tool, or revert to text chat?

All of these have issues:

  • Waving fingers is difficult to sustain and it is inevitable that some users' fingers will wonder off the screen making it hard to record and communicate the result. Contrast can be an issue when skin tone matches clothing.

  • Shouting out estimates leaves everyone talking over each other - impossible on a video call - or else influencing each other's results. That undermines the value of the gaming format.

  • Reverting to text is clunky and breaks everyone's flow. Some users will have more or less screen real-estate at home, with some monitors still trapped in offices. This creates an unequal experience and more complexity.

  • Screen real estate issues also affect online tools, but there is the added issue that if team members are looking at a tool they are not looking at each other's faces..

  • As a solution we can have bright high-contrast cards with a visible edge that are easier to pick up on video compared to fingers. It will also be easier to keep them waving while everyone takes in the results and keeps a note.The obvious continuity with the prior real-life experiences is also a welcome relief from the constant imposition of new lifestyle changes.