How to Avoid Estimating Time Using the Agile Metrics Velocity and Capacity
I read this article on DEV asking about how to deal with estimates. It's a great question to ask and it reminds me of my days at the University. Teachers told me not to estimate projects in time. Later I became a teacher myself and I brought that knowledge on to my own students. Honestly I didn't really understand back then how to actually do that.
I started working at a company in the Volvo Group concern and my team used points for estimations. Except, they didn't. The truth is they only believed they were doing that but in reality, they used time as a measurement. Roughly they defined each point as one day of work for two developers pair programming. They empathized we shouldn't think about it as time, rather as points. In the end, the points were still bound to time so we were in reality still estimating time.
I must say I was a bit tired of people urging to use points over time when it in practice was the same thing. It was somewhere there I actually figured out how to get time out of the picture completely.
How to Use Agile Metrics to Avoid Measuring Time
Substituting time for points is a great start. It's hard to estimate what time something will take and it's even harder to estimate how much time will be spent on other tasks, assignments, meetings, bug fixes, testing and unexpected hindrances.
The tricky part is how to make the points time independent. The solution to how to do that is to calculate a velocity using the outcome of the previous work. Velocity is basically the amount of story points your team succeeds to develop in a sprint on average.
When you know the velocity, you can calculate what capacity the team has in an upcoming sprint. The capacity is what is left of the velocity points after having removed team member vacancies and time allocated to other work, such as maintenance and bug fixes.
Even though many people know about the terms velocity and capacity, many teams neglect the velocity and fixates the capacity to a constant number instead of calculating it from on the velocity. By doing that they miss the whole point with it. The purpose of velocity and capacity is to make points time independent.
A constant capacity is nothing other than masqueraded time. By recalculating the velocity, the team's capacity will become dependent on the team's actual work effort rather than time.
You Can Not Compare Developer Performance
Not all developers work equally fast. One story can take hours for one developer and days for another. After a couple of month or so, the second developer may have become better and can work faster than before. You can't easily estimate performance of developers and say that one developer works half as fast as another one. I will vary dependent on work tasks and as time goes.
One thing you can do though, is to evaluate performance. That is exactly what is done when you calculate a velocity. You look at the tasks that have been done recently by the whole team to get a concrete number of which velocity the team has. That number can be used to estimate what capacity the team has for the work ahead.
The Process of Planning a Sprint
Enough of chattering. Let's describe how to plan a sprint the agile way and how to get the estimation to be time independent.
1. Break Down Features Into Stories
Make sure you have divided each feature to be developed into small tasks (stories). There's no way you will succeed estimating tasks that are greater than a few days or a week in size. On top of that, destructuring features into smaller tasks will help you plan your work and foresee possible pitfalls.
2. Assign Points to Stories
Let the developer team together estimate how many points each story should be assigned. You can preferably use Planning Poker to let every team member vote without being influenced by other teammates.
When assigning points, you can think of some abstract size of the story. Is it a small, mid-sized or large task? Or, you can actually think in time; will it take around one, three or five days to implement? That may sound strange since the goal is to avoid thinking in time, but it's actually completely fine and it falls natural to humans to do that. Merely by using the approach I describe in this article, you will go from speaking about points and estimating time, to speak about time and estimating points!
If your idea of one day of work is inaccurate, that won't be an issue. When the velocity is adjusted later on, your idea of time will be corrected so the points you assign to the task reflects you real work. No worries if you get headache trying to understand that, we will get back to that later.
3. Develop
You can't spend all time in meetings. Do the work you have planned to do. If you are familiar with Scrum and agile methodologies, this will be you sprint, commonly a period of two weeks.
4. Adjust the Velocity
This is the step most people forget about, which is unfortunate. Without this step you are measuring time and not points! What you should do here is to calculate how many points you had time to develop during the sprint. That is the velocity you had that sprint. Take the average of that velocity and each velocity a few sprints back in time and the result is the velocity your team have.
5. Repeat
Continue the process from the beginning, starting by breaking down new stories and then assigning them points. This time, you will have another velocity than you had when you planned your previous sprint, hopefully better reflecting how much work you actually will have time to do.
Regardless whether you thought in points or if you thought in time when you planned your last sprint, your new velocity will "give you" either less or more points when you calculate the capacity you have in the next sprint.
Note: The example below assumes the complete velocity is counted as capacity. Normally you will count away parts of the velocity when determining the capacity to adjust for absence and maintenance etc.
Maybe you originally had a capacity of ten points for a two weeks long sprint and you planned to do ten one-point stories. If you had time to do some extra work and your new velocity turned out to be 12 points, then each day in the sprint would equal to 1.2 points.
When you plan your next sprint, you can continue estimating the stories the same way you did the last sprint. Your new velocity will correct the estimation error you did when you estimated the stories. What you thought to be one point, or one day of work, turned out to take around 0.8 days (1 / 1.2 ≈ 0.8).
With the new velocity at 12 points per sprint, you will get the capacity to plan 12 points into the next sprint, which is more likely to better match the actual workload you will have time to complete. Repeating this process for each sprint will eventually make your estimations fairly accurate.
Conclusion
All teams try to estimate workload, a lot of them using agile methods like Scrum. Many of them are aware of the concepts of velocity and capacity and knows they should be measuring points rather than time when estimating their stories. Unfortunately, a lot of teams forget to consider their velocity when they calculate their capacity for a sprint.
When a team forgets to consider the velocity, their estimation in story points becomes nothing other than an estimation of time. They will plan each sprint with a fixed number of points, which in turn will correlate to a fixed amount of time.
This is a problem because humans aren't good at estimating time. By ensuring to recalculate the velocity after each sprint, you will be able to measure how much work you are able to finish in reality. The recalculated velocity will adjust for any misestimations you do when the work is planned.
