In Scrum projects, everything revolves around sprints. Stories are grouped in sprints, the team is always focused on one sprint at a time, retrospectives are sprint-based and so are the releases. But the critical predecessor for all these is efficient and realistic sprint planning.
Let’s have a quick recap on crucial aspects of the sprint:
- A sprint is a defined period of time, usually 2-3 weeks, during which a specified chunk of work will be completed.
- A team will work ONLY on the planned set of stories during a single sprint, nothing more and nothing less.
- The expectation is that all stories included in a specific sprint will be fully completed by the sprint end.
The third statement here is the most important one to keep in mind when planning sprints. Let’s analyze it for a moment.
Why do we need to know team’s capacity
To make it more likely that all planned work is fully completed within a sprint, we must not plan more than a team can do. To be honest, we can plan way less than a team can do, and the likelihood of all planned work being completed will be much higher, but that would be unlikely regarded as an accomplishment.
So, our task when planning sprints is to help our team do as much work as they can, but at the same time, not plan for more than that.
With that in mind, there is relatively simple math that we can use to determine how much work our team can handle and, based on that, which issue goes into which sprint.
How to estimate team’s capacity
Let’s say our team has five developers, and we will be running two weeks sprints during our project. In each two weeks sprint, there are ten working days. Initially, that might sound like each developer can do ten days worth of work in a single sprint.
Wrong! We know that unexpected things can and will happen all the time. Company meetings, personal days off, sick days … who knows what else. Ignoring these sources of ‘noise’ and disturbance inevitably leads to overloaded sprints, underdelivering teams, and a lot of frustration. Thankfully, there is a simple method to avoid the negative impact of the unknown.
Let’s assume that ‘unplanned’ events, on average, take away 20% of someone’s effectiveness. That leaves us with eight days of effective work that each developer can do in a single sprint.
The 20% loss factor (or 80% effectiveness factor, also called ‘focus factor’, it is all the same thing) is not made up. It is a widely recognized industry standard in project management.
Once we establish those metrics, we can, with decent confidence, claim that five developers can accomplish five times as much in a single sprint: 5 developers x 8 days worth of work = 40 days worth of work.
By doing this calculation, we established the capacity of our team – 40 days worth of work per sprint.
Capacity is defined as “the amount that something can produce”. In our case, ‘amount’ is 40 days of work, and ‘something’ is our team in a single sprint.
If you find these statements confusing, especially how 40 days of work can be done in 10 days, we must clarify what capacity, effort, and duration mean. Do not confuse them, they are very different things, often used too loosely resulting in flawed and misleading plans.
Effort describes what it takes to accomplish something. If it takes a single person two hours to mow a lawn without taking any brakes or being slowed down with anything else, then we can say that the effort to mow a lawn is two hours for one person.
Capacity represent how much can be produced by something. If there is a team of 2 people, and each person can work for 4 hours per day, then this team can provide 8 hours (4+4) of work each day. The capacity of this landscaping team is 8 hours per day.
Duration defines how long it takes to do something from start to finish, including all stops, breaks and slowdowns. If this team is contracted to maw all lawns in a street where there is a total of 12 lawns, it will take them three days to complete that work: 12 lawns x 2 hours per lawn / 8 hours per day = 3 days. The duration of the job to maw all lawns in the street is 3 days.
Duration = Total effort / Capacity
How to use Capacity to plan sprint backlog
Therefore, when we place stories from Backlog in individual sprints, we should ensure that the sum of effort estimates for all stories in a single sprint is not more than 40 days. That is not straightforward and requires some juggling, but it is certainly possible and if done properly it increases the chances for successful completion for project sprints.
How to use Capacity to estimate total number of sprints
We can apply the same logic when planning Scrum projects. Assuming we have created effort estimates for all items in the Backlog we can add all of them to establish the total effort required to complete the whole Backlog. Let’s say the total effort is 180 days. We also know that capacity of our team of five is 40 days of work in a single sprint. The total number of sprints to complete everything that is currently in the Backlog is 180 days / 40 days per sprint = 4.5 sprints. We can’t have fractional sprints, so we will round up to 5 sprints to complete the project.
Capacity is NOT velocity
Therefore, when we place stories from Backlog in individual sprints, we should ensure that the sum of effort estimates for all stories in a single sprint is not more than 40 days. That is not straightforward and requires some juggling, but it is certainly possible and if done properly it increases the chances for successful completion for project sprints.