The development work that will be completed during the Sprint is planned at the Sprint Planning meeting and involves the whole Scrum Team.
If your Sprint is a month long, then the Sprint Planning is time-boxed to 8 hours. If you have a shorter sprint, then the time-box is reduced relatively.
In Sprint Planning the aim is to essentially answer two questions:
- What will be delivered in the Sprint?
- How will we do it?
What will be delivered?
The Product Owner discusses what they’d like to achieve from the Sprint while the Development Team looks at which Product Backlog Items (PBIs) can be implemented in this Sprint.
Only the Development Team select the PBIs that will be worked on, as they know best what they can achieve.
The whole team collaborates to create the Sprint Goal – a high level objective that will be met when all the PBIs for this Sprit are implemented. The Sprint Goal provides guidance to the Development Team on why they’re building the Increment. It also gives the Development Team flexibility on how the Increment will be delivered – they commit to achieving the Sprint Goal, not the PBIs.
How will we do it?
The Development Team discusses how it will create the Increment.
Product Backlog Items + a plan for delivering them = Sprint Backlog
The Development Team will break down the PBIs into much smaller tasks, of around one days’ effort or less.
A plan for the whole Sprint doesn’t have to be created here – the team only needs to plan work for the first few days of the Sprint. The later work will be planned as the Sprint progresses.
The Development Team can discuss the PBIs with the Product Owner in order to clarify the requirements, and can renegotiate with him if they have too much or too little work.
They can also invite additional people in order to provide technical or domain knowledge.
“By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and the Scrum Master how it intends to work as a self-organising team to accomplish the Sprint Goal and create the anticipated increment.”
– Scrum Guide
When to estimate
I often see confusion around when PBIs should be estimated and each team does it differently. Some estimate PBIs and not tasks, some estimate both PBIs and tasks and others estimate tasks but not PBIs! Below is the way we do it, but remember to Inspect and Adapt to see which way is best for you.
- PBIs in the form of user stories are estimated in Story Points during the Backlog Refinement Meeting. This gives the Product Owner an additional metric to use when ordering the Product Backlog.
- As the PBIs are already estimated, when it comes to Sprint Planning, the Development Team can focus on selecting the appropriate items for the Sprint.
- Before we estimate the effort required, we define the acceptance criteria for a task. This ensures the Development Team knows what’s required to complete the task and allows them to more accurately estimate.
- Once the PBIs have been split into tasks during Sprint Planning, we then quickly estimate these tasks. At this point, many teams will switch to estimating in hours, but I don’t agree with switching metrics. So we again estimate in Story Points. Most of the time Development Teams members will be in agreement on the estimate for a task, but occasionally there will be a larger difference. This can be useful in highlighting technical issues that not everyone has thought of.
As the team matures, it’s possible that they can do-away with estimating individual tasks.
We’ll look at the whole process of estimating, and the different techniques you can use to perform it, in a later post.
Duncan Halley is a certified Scrum Master (PSM I). You can read his blog here.
Follow him on Twitter: @duncanhalley
