The Objective
This post is in addition to a previous video.
The aim of Sprint Planning is to select a few Product Backlog ordered, “ready” Items and derive a Sprint Backlog and a Sprint Goal.
The Sprint Backlog includes the Backlog Items to work on and a plan on how the team will complete these items to achieve the Sprint Goal.
How Does It Work
You can summarize what happens in Sprint Planning as:
The Product Owner explains the Sprint Goal, provides clarification, and negotiates the scope.
Scrum Master keeps the timebox, preventing the team from over or under-committing.
The team decides how much work is brought into the Sprint and creates Sprint backlog items.
Proper Backlog Refinement will considerably shorten the time needed for Sprint Planning. Most of my teams kept it between 20-30 minutes.
How Can We Populate the Sprint Backlog?
Populating the Sprint Backlog is as simple as pulling Backlog items from the “ready” until we reach the team capacity for that Sprint.
The team and the Product Owner may need to alter the Sprint Goal if all the necessary items do not fit within the team's capacity for that Sprint.
Are There Patterns to Help Planning?
Yes, two patterns help planning and increase predictability.
Pattern: Finishing the Sprint Early Drives Velocity
Yesterday’s Weather: Use the earlier Sprint to predict the next Sprint.
Take the average velocity for the last 3-5 Sprints to get the value for Yesterday’s Weather
If the team is new, you will have to guess!
Consider discarding a too-bad or too-good Sprint as an exception.
Pattern: Handling Interrupts Doubles Velocity
This pattern implements a buffer to deal with the unexpected.
The Product Owner decides what gets into the interrupt buffer.
To “size” the interrupt buffer, take the average velocity loss for the last 3 Sprints to get the value for the Interrupt Buffer.
Capacity Allocation
DO NOT COMPLICATE!
I have seen people using spreadsheets, etc., to calculate capacity.
I always choose simplicity. The example of the bucket is all about simplicity.
After a couple of Sprints (3 to 5), you have a very good indication of your average velocity and the size of the interrupt buffer. You also know how much your team’s velocity/capacity will drop during a holiday or when people go on vacation.
Yes, the team may be new, and you would not have enough data, but apply your experience and ask the team what they think they can get done. Very quickly, you will have enough data to have better guesses, and after a couple of Sprints, a clear picture emerges.
Just remember that refinement is key to having efficient planning!
Here is an an example of how this all comes together:
Consider this:
Your team velocity is 50 points per Sprint.
You have 48 points in the Sprint backlog for the next Sprint.
The next refined backlog items are 5 points and above.
What should the team do?
Remember NOT to complicate the team capacity allocation.
In this example above, it is best to leave a 48. Estimates are not guaranteed; if you finish early, you can bring some new PBI in.
The Sprint Goal focuses the Team on what the Product Owner intends to deliver to the users and stakeholders for a Sprint.
Commitment: The Sprint Goal
The Sprint Goal focuses the Team on what the Product Owner intends to deliver to the users and stakeholders for a Sprint.
Sample Sprint Goals
The following are two Sprint Goals:
Check whether the architecture enables the desired performance.
This Sprint Goal is addressing a risk.
Test whether users are willing to register before using the product features.
This Sprint Goal is testing an assumption.
The Sprint Goal is a maximum 2-sentence description of the outcome the team plans to accomplish during a Sprint.
What about Points and Outcomes?
Points measure the team’s capacity to complete work during the Sprint.
Points are used only for estimation and planning. They focus on Output.
The Sprint Goal focuses on value delivered to the users and stakeholders. The Sprint Goal focuses on Outcomes.
It is not how many points a team delivers per Sprint BUT How much value was delivered!
The outcome is what Matters!
We achieve the Sprint Goal (Outcome) by working together and continuously improving our processes!
Considerations
A team reviewing backlog items during planning indicates that refinement is broken!
If a team fails to increase velocity in a sustainable way over a period… Look for bottlenecks, inefficiencies, and decision delays.
Do not expect significant velocity gains if you don’t increase process efficiency!
How do we execute the work?
The Sprint Backlog, a plan to execute the Sprint Backlog and the team must think about:
What to work on first?
Can we swarm?
How can we help each other?
Sprint Planning Checklist
Notify the team of the time and location of Sprint Planning. | Notify the team of the time and location of Sprint Planning. | Scrum Master |
Confirm all PBIs potentially included in the Sprint are “ready” (refined, estimated* and ordered). | Confirm all PBIs potentially included in the Sprint are “ready” (refined, estimated* and ordered). | Scrum Master |
Average velocity is known prior to the event's start. | Average velocity is known prior to the event's start. | Scrum Master |
Capacity is known prior to the start of the event. | Capacity is known prior to the start of the event. | Scrum Master |
The interrupt buffer's average size is known before the event starts. | The interrupt buffer's average size is known before the event starts. | Scrum Master |
Confirm that team members are going to attend the Sprint Planning | Confirm that team members are going to attend the Sprint Planning | Scrum Master |
Keep the event time box. | Keep the event time box. | Scrum Master |
Prevent under or over-filling the Sprint Backlog. | Prevent under or over-filling the Sprint Backlog. | Scrum Master |
Create the Sprint Backlog | Create the Sprint Backlog | Developers |
Create the Sprint Goal | Create the Sprint Goal | Product Owner and Developers |