Estimations in Agile development – Sprint Planning Methods: Capacity vs. Velocity vs. Feature

The updated version of this post can be found here - in my new blog.

This is the third post in the Estimations in Agile development series.

1. Epics, User Stories and Tasks
   
2. Estimating User Stories with Story Points
   
3. Sprint Planning Methods: Capacity vs. Velocity vs. Feature  (you are here)
   
4. Improving Estimations using Burndown, Burnup and Actual Time metrics

In the previous posts we’ve learned how to breakdown features to epics, user stories to tasks, and how to estimate epics and user stories. We talked about the three prioritization cycles and their importance, and why relative units like story points work better than time based units like ideal days.
In this post I want to focus on the sprint and on the meeting that starts the sprint – the sprint planning. I’ll show you why technical tasks, unlike epics and user stories, should be estimated in time based units like hours.
The Purpose of the Sprint
A sprint’s purpose is to deliver value to a user and receive feedback. If by the end of the sprint, a user doesn’t receive any value or the team doesn’t receive any feedback for their work, the sprint wasn’t successful. Only after seeing real working features, a user can tell that they are, indeed, what he needs.
A “user story” shares the exact same purpose – deliver a value to a user, that means that we should be able to accomplish at least a single user story in a sprint.
Capacity planning vs. Velocity planning vs. Feature planning
The top user story in the backlog is the one that we need to deliver first since it is the most valuable to the user. But how do we know if that user story actually fits into a single sprint?
There are 3 methods to decide how many user stories can fit in a sprint:

1. Feature Planning
   
2. Velocity Planning
   
3. Capacity Planning

Let’s drill down to each of those methods.
Feature planning
This method basically states that by the end of the sprint, a chosen feature(user story) must be ready. This method is usually used when the team has a deadline that cannot be changed like a commitment for stakeholders or an external constraint. The team will literally do whatever it takes to accomplish the feature. Including long hours and even weekends. The team will not be able to keep up with this for long.
Avoid using this method if possible. However if the company does work like this, then it is important to take the right buffers and plan ahead in order to remove the dependency between the external and the internal dates.
Velocity planning
Velocity planning method uses the team’s average ‘velocity’ in order to determine the amount of user stories for the sprint.
Velocity is a metric that defines the amount of story points a team accomplishes in a single sprint.
For example, if a team finished a total of 10 story points 2 sprints ago and another 10 story points in the last sprint, then its velocity is 10 story points.
When planning based on previous velocity, in the upcoming sprint the team should take user stories with total of 10 story points.
This method is obviously better than the previous one. However this method is not accurate enough for a two weeks sprint resolution.
The velocity based planning is relying on addition of relative units – story points. The problem with adding these values is that 1SP + 2SP != 3SP.
A story point is a relative unit that describes a story’s complexity relatively to another story (X is 2 times harder than Y). This unit is great for comparing stories and deciding on their priority, however a 2SP task doesn’t equal to two 1SP tasks. As a matter of fact, 2SP task doesn’t necessarily take the same amount of time that as another 2SP task.
Let’s assume that our project is already running for 10 sprints. We could look back at every user story in every sprint and give it the actual time it took. This will allow us to convert story points to time. Let’s say that after that calculation 1SP is equal to an average of 12 hours.

*Agile Estimating and Planning by Mike Cohn page 162
As you can see that despite the fact that the average is 12, we had tasks that took less and some that took more. The standard deviation becomes bigger as the SP number value is higher (some 3SP tasks will take 30 hours while others may take 45 -50% more). It should not be a surprise – after all 2SP states that it is 2 times more complex than 1SP task, it doesn’t mean that every time it will take twice as long.
Therefore if you plan your sprint using velocity don’t be surprised if some of the tasks take longer than others although they have the same SP value, and that you won’t finish all the planned tasks by the end of the sprint.
Capacity Planning
There are many unknowns when we try to plan months ahead (like in the beginning of the project). However things are different then we plan a sprint (which is only 1-4 weeks long). There are several known facts that allow us to plan more accurately:

1. A sprint’s length is constant (read here why) it can be 1 -  4 weeks longs. Either way it is known, hence we know how many working days there are in the sprint.

2. We also know of how many working hours are there in a single day of a sprint.

3. And we also know how many team members to we have.

For example in a 2 week sprint we have 10 work days, 9 hours a day and 4 team members. 10 X 9 X 4 = 360 hours.
However we don’t actually have 360 hours right? What about all the meetings? The days off and other known wastes.We know most of our wastes when we plan for 2 weeks ahead. We also know another thing – we don’t actually work 9 hours a day, take off lunch, breaks, vacations, support hours and other context switches and it will be more like 6.
Each team member can easily calculate his capacity by simply looking at his calendar, so in order for the total capacity to be accurate, a sprint capacity calculation should consider every team member individually.

That is the sprint capacity (for a 1 week sprint).
The capacity represents the absolute amount of work that the team can handle in hours. The sprint’s capacity is like an empty glass which size is determined by the team members working time (also hours).

The size of the glass is in hours, therefore in order to fill it we also need to use hours. Unlike big features, epics or user stories which are hard to estimate, tasks should be well defined and should require a relatively small effort (no longer than 3 days). The tasks estimation is created using “poker planning”. 

After estimating the first task we add it to our sprint backlog and basically “fill the glass” a little.

We can see that we haven’t reached our capacity yet. Therefore we can keep estimating until we’ll reach it.

We had successfully filled our time with…time! Before the planning we have removed all the known potential wastes and therefore we have a pretty good reason to believe that we’ll complete all the tasks in the sprint on time.
We could wait for the end of the sprint and find out whether our estimations were correct, or we could use some useful metrics to verify daily that we are on track.
We could also use some other metrics that will allow us to improve our estimations over time, and for the grand finale, we can use a very special metrics that will help us to predict the future.
Read about all that and more in the next and the last post of this series.
Estimations in Agile development – Epics, User Stories and Tasks
Estimations in Agile development – Estimating User Stories with Story Points
Estimations in Agile development – Sprint Planning Methods: Capacity vs. Velocity vs. Feature  (you are here)
Estimations in Agile development - Improving Estimations using Burndown, Burnup and Actual time metrics (go here)