Sprint plannings in Scrum sometimes take long; even when you have all the Stories ready for sprint and estimated. Reason being the team still need to break down stories to tasks, and the Scrum master needs to calculate the capacity and compare the total hours of broken down tasks to the capacity available in order to find out whether the team are committing well, under committing or over committing in order to further negotiate the commitment with the Product Owner if required.
These are basics and widely accepted, but does it make sense to make the team to break down all the stories right at the beginning of the Sprint – during the planning? Most of the time, this breakdown takes a long time, and the longer it goes on, the more the team members get tired and the probability of missed tasks and wrong estimations increases.
On top of that, when the team have all their Stories broken down, sometimes put up on the board, it is easy for software, quality or user interface engineers, that make up the team to pick any tasks from the board, rather than focusing on getting Stories done one by one. By Done I mean Stories meet the “definition of done”. The risks are of course not correctly estimated commitment that may result in sprint failures, failed releases.
So what’s the alternative? The Alternative is using the Just-In-Time, Just Enough approach by doing the following:
- First, the team need to understand which stories are important to start at the beginning of the sprint. This is not straightforward and needs some musing involving the team. Part of the importance comes from the priorities set out by the product owner; the other part depends on the resource planning during the sprint.
- Once these stories are identified the team proceeds breaking down these Stories to tasks, and stops when they have around 2-3 stories broken down.
- Using the data from the already broken down stories, the Scrum Master calculates the predicted size of the initial commitment.
- Calculating the total hours of tasks broken down
- Dividing by the total sum of Complexity estimates of these stories
- Finding the “Average hours per Story Point” coefficient
- Multiply that by the Total Complexity points of the Stories in Initial commitment
Let me show you this on an example:
Say the team wants to commit to 10 stories estimated all together to 36 Story Points:
Instead of breaking down all that stories into tasks before confirming the commitment during Sprint Planning the team chooses to break down Stories 1, 6 and 9.
Story 1 is broken down to 14 hours worth of tasks
Story 6 is broken down to 28 hours worth of tasks
Story 9 is broken down to 17 hours worth of tasks
Based on that we have the rough Average Hours per Story point ratio of about 3.7
We multiply that by 36 and get 133 hours, which is the forecasted volume of the commitment.
The team and the Scrum Master then see how it compares to their available effective capacity and based on their findings either confirm the commitment or renegotiate.
Now, there are tools like Agilo that do this for you automatically, but if you’re using and Agile tool that doesn’t support this you can always do this manually. This is usually very quick, helps the team to avoid the burdensome full Stories to task breakdown, reduces the WIP (Work in progress) by helping the team to focus on what’s important every step of the sprint way!