I described the differences between Velocity and Capacity planning in a previous article, but in this article, I’m sharing the approach for sprint planning that has proven to work well for my teams. By sharing this approach I don’t mean it is the absolute truth. I strongly believe that every team should experiment and find the approach that works best for them. I hope the information in this article will give you ideas for your experimentation.
We break our planning meetings into the following parts:
- The product owner proposes the goal
- The team understands their capacity
- The team breaks down the stories
- The final goal is chosen
I have seen teams skip some of the steps. My teams had stages where we skipped the capacity calculation and didn’t estimate sub-tasks hourly. When you have a team where most of the engineers are working together for more than a year and they are working on the same product area, then the team is in the state of understanding what they can deliver by just looking at the stories.
But new teams or teams that work on a new product area with some unknowns usually need to do detailed capacity planning alongside the velocity planning.
So, don’t consider these steps as written in stone, and try to adapt them to the needs of your team.
Product Owner Proposes the Goal
Every planning meeting has its preparation: the homework that the product owner does. It includes the following:
1. Define the next sprint’s goal
This is the next increment the team should deliver. The goal represents the value that users will get after the successful sprint. I saw teams setting goals like “release software version n.n.n.” This is not a good goal as it doesn’t represent what will our users actually gain.
We usually define goals like “Users will be able to accomplish something” type of stories, and these really represent the exact outcome we will have for our end users.
This is very important because the team should have a clear understanding of the scope of the work they should deliver in the sprint. Also, the goal should point to the only outcome of what users will get from the functionality point of view, and it should avoid including a deterministic technical approach of how users get the value. The team might face blockers that change their tech approach but still deliver the desired outcome for the users.
2. Prepare that backlog
All stories that need to be completed to achieve the goal are included in the sprint backlog. The product owner makes sure the sprint backlog contains stories that total story-points are slightly higher than the teams’ average velocity.
The team understands their capacity
We use the velocity and capacity planning calculator I have created, which helps us understand our allocation and available capacity. Here are the updates we make on that sheet:
- Update the pink cells in columns C; make sure we exclude meetings, for example, if we know we have a holiday, then add 1 in cell C17.
- For every engineer, update the Contribution % and Day Offs. Contribution is used for cases like the on-call person will have 0% contribution to a sprint, or maybe we have a new hire with 0% contribution but another developer will help with onboarding, so we will have 70% contribution to the sprint.
After this, we will know the capacity (available hours) for each role — but I would like to pause and highlight that your goal should be having a single role as the best Scrum team is the one where almost all engineers can work interchangeably. I have seen huge performance improvement in my teams when we came to the state where everybody was doing everything: testing, developing, and helping the product owner define stories. This probably sounds weird, but I will try to come up with another article on this topic.
The team breaks down the stories
In this stage, the team goes through every story starting from the highest priority. For every story, the team brainstorms and defines the sub-tasks of the story that needs to be completed to meet the definition of done for the story.
IMHO, this is one of the most important things to master and do the right breakdown of stories and give hourly estimates to the sub-tasks. Even in the case of a strong team where they know what can deliver based on just the velocity, I still strongly suggest doing a task breakdown by skipping hourly estimates of sub-tasks.
When the story is broken into subtasks, update the velocity and capacity planning calculator to indicate the hours of every role. As the sheet is just a calculator that should be a helping tool, you don’t need to copy all stories one by one, but just make sure you sum up all hours for every role.
In every sprint there is always work that needs to be completed that doesn’t have a story point. For example, you have issues to fix or something to investigate. Hourly estimates of these tasks/issues are also added to the sheet.
You continue adding subtasks and issues until one of the roles doesn’t have more available hours. This is the right time to discuss what can be done like other roles can take to work of the role that doesn’t have more capacity.
For example, imagine your backend engineers are fully booked but you have another story that requires some backend work. This is a great time to discuss with frontend developers and see if they can take and deliver the whole story.
The same applies to the QA role. When QA doesn’t have more capacity, other engineers should jump in and help with testing.
The final goal is chosen
When the tasks are broken down and the team’s capacity is used, the team again looks to the goal. At this stage, they might want to change the goal. For example, maybe the team wasn’t able to take all stories or maybe they had more capacity and had to include another story to the sprint from the product backlog. So, this is the time when the team commits to the goal.
As a hint, I can say that it is not mandatory for all stories in the sprint to be a part of the goal. The goal can represent ~80% of the stories in the sprint backlog.
I suggest doing planning in four main stages: (1) The product owner presents the sprint backlog and describes the next increment that they want the team to deliver. (2) The team understands their capacity. (3) The team breaks stories into sub-tasks. Gives hourly estimates to sub-tasks and issues they have included in the sprint. (4) Everyone looks to the goals again, adjusts to the work they have taken, and commits to the goal.
This approach worked well for my teams over the last couple of years, and I hope you will find some useful points to improve your planning meetings. But again, I would like to highlight that nothing is written in stone and you should adapt things to your own teams’ processes.
Full Article: Gagik Sukiasyan @ Better Programming
Mobile App Development Trends – 21.02
New Observation Framework, Container Transform Animations, Apple's New Sports App and more!
Roblox paid out $741 million to game creators in 2023
Last year, about a hundred Roblox games brought in more than $1 million, with nine games bringing in at least...
What Windows 12 Mobile could be
It's been nearly a decade since Windows phones effectively ceased to exist, but fans still hold on to the memory...
Vortex – High-performance particle effects for SwiftUI
Vortex is a powerful, high-performance particle system library for SwiftUI, allowing you to create beautiful effects such as fire, rain,...
Mobile App Development Trends – 21.02
Core Data migrations, Refining Compose API, State-of-the-art Open Models and more!
Apple Maps Bottom Sheet
In this video, I’m going to show how to place Modal Sheet over the Tab Bar just like Apple Maps...