How expensive will this feature be in the Agile world?

I quite often get the question if hours or story points should be used. The short answer is, you should use both. In this blogpost we will discuss when and how and help you answer the question: How expensive will this feature be and when will it be done? To answer this question I will dive into our best practise about accurate estimates and as a bonus this will give you the metrics to improve you as a team! 

So our goal is to have an accurate planning for a feature and know how much money it will cost. This will help your stakeholders such as business owners and portfolio management determine if they want the feature and if it makes business sense. In traditional organisations this is usually done by estimating in hours, making GANTT charts, setting milestones and then when you start to execute on the feature, have a project manager report progress, chase the issues, micromanage the team to get maximal utilisation, raise exceptions because in the end the estimated hours are not accurate enough.

Agile costs per iteration

If we approach the above question, in an Agile organisation it will work slightly different. First we start with stable teams, teams that stay together for at least half a year but preferably more than two years. There is a team dynamics reason behind this and at the same time it makes determining the cost a lot easier. Because the team is stable, its costs are stable too. You can easily determine the average costs of an iteration. Take the cost of the team for a year and divide by the number of iterations. Now that you know the cost per iteration, we can look at how much we can do in an iteration. This starts by measuring the team's velocity.

Story point velocity per iteration

Usually one can determine the velocity just by looking at the last four or five iterations and determine the trend. As a team you want and need to be predictable. If your velocity is about the same for the five iterations you are done. If there is a lot of difference in velocity per iteration then something else is going on and you might want to fix that first. With the cost per iteration and the velocity per iteration we can now determine how expensive the net hours or the story points actually are.

This is the point where I tell my coachees that estimating stories in points makes estimates more accurate and teams more honest and predictable. They tend to respond with that estimating in points will not work for them and their stakeholders. They say they need hours in their organisation and that they are capable of doing good estimates in hours.

Though if you ask them they also tell you that their estimates aren't that accurate. The traditional approach is to estimate in hours and micromanage all the tasks. Even-though we know that when a task gets bigger then about four hours we humans suffer from planning fallacy, this makes our estimates unreliable and as a result the team, the methodology, the business case etc all become unreliable too. When working in an Agile setting micromanaging teams on tasks, estimates and expectations is not the best way to go if you want to use the power of your teams. You (start to) trust the team and ask them to estimate and deliver stories instead of tasks. You ask our stakeholders to look at the bigger picture. What value will you get out of this iteration or series of iterations and what are you paying for the value?

Estimating in points helps, you don't have to discuss the difference between net and gross working hours, you tend to look at the whole complexity and not break it down in to steps (and forget a few) and you can ignore the overhead, because that is included in the velocity.

Experience the difference between estimating in hours and points yourself

In our Agile Bootcamp training we have an estimation exercise that asks for the total height in meters of 8 buildings in the Chicago skyline. When we ask for an estimation in meters for the total height there are huge differences between the teams (estimate in hours). When we ask the same question in relative estimates in points, where we say that one building has the value of 3, than the difference drops to 5%-10% (estimate in points). If we then convert to meters based upon the known height of one of the buildings the estimates are a lot more accurate (points to costs). If you are interested in this exercise, send me an email and I will send you a copy.

Evaluate the value of a feature

With the iteration velocity and estimating in story points we can determine the costs versus benefits with stakeholders quite simple. The product or feature you are requesting is estimated by the team at five points. We have a velocity of 30 points per iteration and an iteration costs € 60.000,-. Are you willing to spend € 10.000,- on this feature?

Improve velocity

So when do we use hours? Logging the work in hours can help you to see how to improve. You can see your gross versus net work hours and as a result how much overhead there is. See if a story took significantly more time then similar sized stories. These things help to identify places to improve. In this it's important to only log the actual time spent on the stories and subtask and not to log 100% of your gross hours on these stories. If you need that for reasons like billing, keep a separate billing administration. Or better don't invoice on hours, but invoice on team effort e.g. cost per iteration.

But I think one of the most powerful reasons for estimating in points and logging in hours is that you can measure and improve on output, the amount of points delivered. Measuring output in hours can't really improve over time (though a bit on productive time), because there are only 24 hours in the day. You can also improve on outcome, but that's another topic.

The easiest way to In improve and at the same time avoid point inflation or deflation is to base the points on reference stories. The refernence stories need to take the complexity, quality (DOR, DOD) and the tasks (e.g. design, build, test, deploy, etc) into consideration. Teams that keep the same velocity all the time are either not improving or are suffering from some sort of deflation.

Plan and manage expectations

Now we only need to manage the expectation. We need to translate feature priority and points to a planning. In the following clip, it's explained quite elegantly how you can do this in this video.

Next topic?

The goal of the "Working Agile blog post series" is to highlight possible improvements to the way you and your teams work Agile. What are your Agile questions?