How Do We Run Our First Sprint Planning Meeting?

Premise

The purpose of Sprint Planning is to allow the team to commit to what they can deliver in the next Sprint - the committed Sprint Backlog.

Sprint Planning occurs at the beginning of the (next) Sprint, after you have completed the Sprint Review and Retrospective of the current Sprint (i.e. the Review and Retrospective are an input to the Planning). Note that there is typically no gap between the end of one Sprint and the start of the next Sprint.

Sprint Planning may be divided into two sessions, be conducted as one session, or occur as a series of shorter incremental sessions. Typically, Sprint Planning is viewed as having two parts:

Sprint Planning 1 - Used by the Team to reach common agreement on Product Backlog items with the highest priority (including their Conditions of Satisfaction), to determine likely items for the Sprint Backlog, and to discuss these latter items sufficiently so the Team can effectively conduct Sprint Planning 2, where they will commit to deliver specific items by the end of the Sprint.

Sprint Planning 2 – used by Teams to determine in detail how they will make and meet their commitment for the Sprint (including applicable Definition of Done criteria and considerations regarding individual team member availability during the Sprint). Most teams do this by taking each Sprint Backlog item and detailing it in terms of the tasks required to complete the work. Each task for an item has an estimate in hours (or, for some Teams, story points) that would take into consideration potential obstacles, risks and dependencies.

By the end of Sprint Planning 2, all Team members should be confident that the worked committed to can be completed by the end of the Sprint or have identified the risks associated with any items about which there are doubts.

Background

The team should use the data they have to help them make good commitments. For example, during the Sprint Planning 1 process the team will have velocity information to help them understand how much they can complete as a team. By keeping a running total of the points a team thinks it can work in the upcoming Sprint, and comparing it to the “normal” velocity of the team, the team can easily gauge whether they are over-committing.

Similarly when the team gets to Sprint Planning 2, comparing a running total of the estimated hours on the tasks to a total team capacity for planning purposes will help the team understand what is truly possible to commit to.

Sprint Planning 1

Purpose: Determine what the Team should build in the next sprint.

Who: Scrum Team - Team, Scrum Master, Product Owner and other stakeholders as required.

Duration: Maximum 2 hours for a 2 week sprint (10 working days).

Summary Agenda:

Clarify Product / Release Backlog items

Collaborate to get common understanding

Define or review Conditions of Satisfaction and/or “Done” criteria

Establish Sprint Goal

Revise estimates

The Team picks from prioritized backlog, taking items to fill to team capacity

Result: A list of backlog items that are candidates for delivery in the next sprint, sometimes called the Selected Backlog.

Sprint Planning 2

Purpose: How are we going to meet Sprint goals?

Who: Scrum Master and the Team, with the Product Owner at least available to answer question if not fully engaged.

Duration: Maximum 2 hours for a 2 week sprint (10 working days).

Summary Agenda:

Determine team capacity

Review “Definition of Done”

Team plans how it will work together to deliver

One approach is to break the sprint backlog into tasks, where estimates on the tasks are no greater than 16 hours.

Identify obstacles/risks Identify dependencies

Identify conditions of satisfaction (tests, inspection)

Make needed adjustments

Review Sprint Backlog to confirm the Sprint Commitment with the Product Owner

Result: Recorded Sprint Backlog against which the Team has committed to complete by the end of the Sprint.

Sprint Backlog

The Sprint Backlog is the result of Sprint Planning. It represents two things:

The subset of the Product Backlog that the Team has committed to deliver in the next Sprint.

The detailed arrangements that Team has made to help them make the commitment.

For different Scrum Teams, the level of detail tracked in the Sprint Backlog depends on each Team. The key information is that the Team makes a commitment, and that commitment is knowable to all stakeholders.

Deliverable

At a minimum, the Sprint Backlog is a list of Product Backlog Items that the Team has committed to deliver in the Sprint and the basis of the information required to generate the Sprint Burn-down chart. In most cases this is a detailed plan of tasks the Team expects to undertake to meet their commitment. This detailed plan is created and tracked by the Team.

Checklist - Sprint Planning 1

Preparation

Scrum Team is invited: Product Owner, Scrum Master, All team members

Product Backlog is prioritized

Backlog Items are estimated

Product Backlog is visible and accessible to everyone in the meeting

Planned absences (e.g. holidays) of team members are known

The room / environment is suitable for team discussions

The results of the Sprint Review and the Sprint Retrospective are available

The Sprint Schedule is defined

Moderation

Make the following items visible to everyone in the meeting:

Sprint Schedule

Sprint Review Meeting results

Sprint Retrospective results (note: these are the public improvement goals rather than, say, minutes of the meeting)

The Product Owner informs the team about the product vision

The Product Owner and the team define the Sprint Goal

If there are Backlog Items missing the Product Owner can add the Backlog Item to the Product Backlog

Results

Selected Product Backlog is well prepared for the Sprint Planning 2.

Checklist – Sprint Planning 2

Preparation

Participants are invited: Scrum Master, the Team members and Product Owner. At a minimum the Product Owner has to be reachable for questions.

The Selected Product Backlog - the Sprint Backlog is accessible for the task planning (Optional)

Material for the planning such as a whiteboard, pin board, sticky notes etc.

Moderation

Team members determine team capacity. An approach to do this is:

Scrum Master leads

Count days available for each person

Do not count Scrum Master, Product Owner

Breakdown to hours, count 6 hours per day

Remove other impacts

Ask “What else” – vacation, moves, other work

Understand who is not 100% on team and adjust

Sum total hours available to team in next 9 working days

Determine percentage of “unplanned” work and breakdown so that you have “hours available for planning purposes” and “hours available for ‘planned unplanned’ proposes.

Team members find tasks for each Backlog Item

Make sure that every piece of work is taken into account to reach Definition of Done – Coding, Testing, etc – to get to a “potentially shippable” state.

If a task effort is bigger than 16 hours, try to split the task into smaller tasks, so the team can understand during the Sprint whether real progress is being made on the commitment.

If the team believes that the resultant Sprint Backlog is too large, work with the Product Owner to remove low priority Backlog Items

If the team believes that the Sprint Backlog is too small, work with the Product Owner to bring in additional Product Backlog items from the Product Backlog

The team commits to the Sprint Goal. An approach to make this concrete is to have the Product Owner ask “Fist of five vote – how likely do you think that you’ll be able to make the commitment?”

Results

Sprint Goal and Sprint Backlog are visible to everyone within the organization. The tasks in the Sprint Backlog are accessible to all team members

~~LINKBACK~~ ~~DISCUSSION~~