Effective Sprint Planning – Key to building a valuable product increment

In my earlier blog post on Scrum is RARE! http://agilekingdom.com/scrum-is-rare/, I wrote about the Scrum frame-work and it has rules, artifacts, roles and events. There are four separate events in Scrum and each serves its purpose and it is very important to conduct these events in every Sprint. Sprint Planning is the first event in a Sprint and happens on the first day of a Sprint at the beginning of the Sprint. I often get questions about this and a lot of people have a misunderstanding/assumption that the Sprint starts after the Sprint Planning and that is not correct. The Sprint starts with the Sprint Planning, which is a part of the current Sprint.

Sprint Planning is a time-boxed event for a maximum of four hours for a 2-week Sprint and is used to plan for the work to be done during the Sprint. The time-box is typically adjusted for shorter or longer Sprints. The Sprint plan is created by the entire Scrum Team.

In another one of my earlier blog posts on Empiricism – the foundation of Scrum http://agilekingdom.com/empiricism-the-foundation-of-scrum/, I wrote about the three pillars of empiricism – transparency, inspection and adaptation. It’s an inspect and adapt mechanism where the product backlog and the latest product increment is inspected, to plan for the Sprint and adapt during the Sprint.

According to the Scrum Guide, Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the chosen work needed to deliver the Increment be achieved?

Sprint Planning addresses two topics:

Topic One is when the team plans about what can be done during this Sprint.

The ScrumMaster ensures that the event takes place within the time-box and the participants understand the purpose of it. The ScrumMaster keeps it focused and keeps under time-box.

The Product Owner (PO) leads Part one of the event. The PO sets the priority by clarifying details of the product backlog items, answers the definition of ‘Done’ questions and collaborates with the team to define the Sprint Goal. The PO clarifies the product backlog items acceptance criteria.

The Development Team works to forecast the functionality that will be developed during the Sprint.

The inputs or items that are inspected are:

1. Product backlog,
2. Latest product increment,
3. Projected capacity of the development team
4. Past performance of the development team and
5. Highest priority product backlog items that are ordered

The Scrum Team crafts the Sprint Goal. It is usually a short paragraph of what the objective of the Sprint is, that defines what the team will build/get done. It is not a commitment, but a forecast of what functionality to be built.

Topic Two is when the Development Team decides on how to build this functionality, how the chosen functionality be built to a ‘Done’ product increment. The output of the meeting will be a Sprint Backlog (subset of the product backlog) that the team forecasts to build. The Development Team starts designing the system and plans the first days of the work to be done, decomposed into smaller units of a day or less. The Development Team decides on to “how” to do the work. The Product Owner usually is focused on the “what” needs to be developed. The development team may invite other people to get their input on domain or any technical advice.

There is still room at this point for the team to trade-off or negotiate the selected product backlog items. By the end of this event, the team should have a finalized Sprint backlog. Once the Sprint backlog is forecasted, it is protected. ScrumMaster enforces and ensures that the Sprint is protected.

Projected capacity is the total number of hours available in the development team to work during the Sprint. Helpful advice is to consider any planned vacation or time-off for the team, meetings, training etc.

Past Performance – usually called velocity, is the total number of story points a team completed, in a previous Sprint. It is a historical number.

Sample Agenda/Checklist for Sprint Planning

Topic 1 – What can be done during this Sprint?

• ScrumMaster starts the event, ensures the purpose of it is understood by participants and is conducted within the time-box
• Product Owner leads the discussion on Product backlog, discusses top priorities, clarifies the details of the product backlog and acceptance criteria, and answers definition of “Done” questions.
• Estimate projected team capacity during Sprint – helpful advice is to consider any planned vacation or time-off for the team members, meetings outside of Scrum, training etc., and continuous product backlog refinement.
• Product Backlog Items are usually User stories – ensure the quality and that they are well-formed.
• If needed, estimate or re-estimate Story Points.
• Look at the latest product increment.
• Consider team’s past performance and any additional helpful information radiators.
• Forecast Sprint backlog.
• Craft a Sprint goal. What and why. The goal is always to deliver potentially shippable working code.

Topic 2 – How will the chosen work be delivered?

• The Development Team does the first days of task decomposition.
• Team Analysis and design of the system.
• The Development Team Identifies work activity dependencies.
• Negotiate or trade-off analysis before finalizing Sprint Goal
• The Development Team may consult with SMEs outside the team.
• Finally, the Development Team presents the Sprint Plan to the Product Owner. Importance of planning. SM, PO and Dev Team.

Conclusion

Effective Sprint Planning is of paramount importance to accomplishing the Sprint Goal. The two topics of focusing on the “what” and “how” to plan for the Sprint is the starting point of a Sprint. The Scrum Team crafts the Sprint Goal and the Development Team plans on how to accomplish the Sprint Goal to deliver a potentially shippable product increment.