Stepping Away From Team Velocity

Velocity, is a commonly accepted metric for communicating how much agile teams deliver. Velocity is based on the idea that teams take individual work items, often call stories, and perform relative estimation on them, expressed as a count of story points. These story points have no unit of effort in and of themselves. Rather, they are just a means to relatively rank each story in terms of complexity and effort. The team then estimates their typical velocity as the number of story points delivered end to end within a short time period, often a couple of weeks, frequently called a sprint.

Teams can use clever techniques like planning poker, to ensure the entire team gets an equal voice in coming up with relative estimates that everyone can agree on.

So what is wrong with estimating points and tracking velocity?

1. Points are an unnecessary level of abstraction
2. Velocity is a time-boxed metric that breaks down when we try to understand progress across larger portions of value creation than engineering
3. Teams often sink a lot of time and effort into estimating at a level of granularity that is meaningless to the overall flow of value.

Don't Estimate, Count

For starters, for a story to be a story, we accept it must be small, sized so that teams can and will deliver quite a few of these in a short period of time. If this is true, then points serve as a needless extra layer of abstraction. We can make the exact same observations by simply counting the number of stories that flow through our system of work.

The biggest value of estimating stories in points is to ensure that we only work on stories that are small. Once we have accomplished this, the difference between the complexity of one story vs another will be averaged out over time. Stories being small, have a small amount of inherent variation. What we really want teams to do is watch out for items in the backlog that are not small.

In other words we need to be careful that our stories are actually stories, and not masking a much larger piece of work, when this happens we need to break it up into stories before we start working on it!

So we can get the most valuable part of point estimation, by simply making sure work is broken up into small stories. Some call this approach #noestimates. I disagree a little, I like to call this approach estimating when variation requires you to do so. An emphasis on throughput can save a lot of time and effort from the team, they no longer have to debate small differences in complexity between each story, differences that do not matter if we look at the medium or long term.

Throughput is a much more accessible number to people outside the team, most stake holders can be shown what a story tends to mean for a particular team, we can provide them an example of a larger story and a smaller story. It then becomes very easy to express plans and progress in terms of throughput of stories. How many stories do we think are in this feature? How many stories do we think we can do over time? How many stories have we tested so far?

Value Creation Throughput Trumps Team Velocity Every Time

Throughput also allows us to look at capability outside a very narrow time horizon such as a sprint, and across a larger part of the value creation process, ie more than than just engineering. This lets us track the throughput of items that can take longer than a single sprint to deliver.

Let’s take an examples, using flow metrics we have determined the capacity of a team, in this case they have delivered 90 stories over the last 9 weeks. This gives us a team throughput of approximately 10 stories /week or 40 stories /month.

This throughput can be measured at the beginning of the value creation process, as well as for the final parts. We get a more systematic view than team velocity.

Reserve Relative Sizing For The Longer View Of Your Backlog

When a team is good at decomposing their work into small, incremental, testable units, and delivery them then we can use the team’s story throughput as a measure of a teams ability to deliver, and then estimate items in the backlog in terms of number of stories, in each item. By item I mean a coarser piece of demand, something that is only partly understood, an epic, a feature, a thin slice, what have you. It is with coarser units of demand that estimating using relatively sizing can really shine! We can use relative sizing to quickly size new work by asking how big is this piece of demand compared to something that the team has previously delivered? Is it bigger or smaller? Is it less or more complex? By a lot or a little?

I like to relative size visually, by placing the work on vertical axis and encouraging the team to place previous work initiatives based on a complexity scale. Estimating is simply an act of placing new items in the right spot according to relative complexity.

Go Deeper where you Need to, But No Deeper

Initially this is just a swag! We want experience to inform the conversation! Where there are to many unknowns the team will need to spend more time exploring the work using techniques like impact mapping or story mapping. It’s important however to not facilitate these exercises with an eye towards doing a complete analysis. The team needs to take the vantage point of an explorer, you want to go wide for the most part, and go deep in order to uncover assumptions that are getting in the way of doing a reasonable, low precision sizing effort.

This relative sizing can be done with successive waves of refinement based on how soon the delivery start date is. Starting at the initiative level, then doing deeper dives to get a better understanding of the smaller increments of value, such as features, thin slices and eventually stories.

Again, taking our example team, if they have been demonstrating a throughput of 40 stories a month, then the team could relatively size future work in terms of stories and get an at least reasonable understanding of when they could start a particular piece of work, assuming reasonable prioritization was done on the work.

Again the point here is not a highly precise estimate. We are using reasonable approximation to make imperfect information visible. 

What if this a new team? What if we don't know our throughput ? What if we think it wont be stable. Well, in those cases get the team to estimate their throughput, and use that to guide planning. Of course the estimate will be wrong, but aren't they always?

In closing, if teams really want to stick with velocity and story point estimation than by all means they should be allowed to do so. We can glean useful information from team velocity based approaches, and it is relatively easy to fit team velocity into a larger throughput based strategy. It is also easy to super-impose the two approaches and compare the data. In my experience many teams are able to see that throughput is simpler and supports a more holistic perspective.