The Challenge of Conflating Size of Work and Time of Work
In my Lean-Agile classes, I often ask people how far away something is. For example, if I’m in Seattle I’ll ask them how far away Portland is. I usually get an answer like “about 3 hours.” I respond by asking “I can walk there in 3 hours?” “3 hours to drive.” “What if I have a private helicopter?”
We might think this is just some people being sloppy but if you google “distance between portland and seattle” and you’ll get 2 hours and 43 minutes in a big, bold, highlighted answer with a small “173.9 miles” that’s barely noticeable. The fact is, we conflate distance and time.
In software we do the same thing. We conflate the size of the work to do (distance) with the time it takes to get it done. As in the earlier case, these are two different things. The size of the work is not the same as the time it will take to do the work in the same way the distance between two cities is not the same as the time it will take to get from one to the other. Different people or teams working on the same story may result in two different times to achieve the result. It will also be difficult to tell the different relative speeds of the teams because a team working on a bigger project may appear to be slower than a team working on a smaller project, even when they are more capable. Our estimates will also be off because we typically estimate based on who is best capable of doing the work while they are not always the one who will do the work. This is like estimating based on us all having the ideal vehicle to use in getting from one place to another – no wonder our estimates are off.
What We Really Want to Do
But that’s not the real issue. The real issue is that we have two issues here:
- How fast our teams can build software
- How much time the work in our backlog will take
Doing this might not be so bad if our rate of work was constant – but it isn’t. Interruptions and waiting for key folks often slow us down by a factor of 3-5 times. This may seem like a surprisingly large number but can be validated when one considers what happens when delays occur between coding and testing. What might take a few minutes to fix when testing occurs right after coding might take a few hours (or even days) when the testing takes place weeks later. There are many other examples.
The bottom line is that we want to measure the size of our work and the speed of our teams. This will enable us to do many things which conflating these issues will not provide. Unfortunately, there is no good, consistent measurement for size of work. One attempt at this was “function points.” But these are not exactly what we want. Function points may not necessarily be well correlated with the size of the work.
What works well is some measure of the overall complexity of the work. This will, of course, include the aspects of number of function points, size, inter-connectedness, etc. We call these “story points.” A story point is an arbitrary unit of measure of the size of the work. This has often been called the amount of effort to achieve the result, but effort is not quite the right concept. To accomplish this we must understand what completing the story means. That is, we must agree on a definition of done. I suggest that definition include full testing on the story – so you truly know it is completed. Hence, the complexity of the story will include both what it takes to build it and what it takes to validate it’s been built properly.
One may wonder how an arbitrary unit of measure can be useful but the arbitrariness is not a problem. If story points is our measure of the size of the work we can measure our velocity (how fast we get work done) by the number of story points implemented in a sprint. For example, if we have 120 story points to do and we do 40 story points a sprint, we know it will take us 3 sprints to do the job.
In using story points, we separate these two issues – size of work and velocity of teams. We’ll see how this can be useful, but first a few words on estimation. It turns out that what one story point means is not really that significant. But, to get it on a reasonable scale, we’ll say a story point is about a days worth of work. While doing this seems to contradict some of what we said, it doesn’t because estimating what a day is is not that hard – since a day of uninterrupted work is achievable. However, once we start using story points, we’ll stop remembering where the initial value came from. When moving forward, we’ll decide the number of story points something is by comparing it to something that has already been sized. This is called relative estimation.
The Value of Keeping Story Points and Team Velocity Separate
The value of keeping story points and team velocity measures separate is that both will be more accurate than if they were combined. By having velocity at the team level we will be able to better plan our work. This is particularly important when we have to coordinate teams. If work must be split across teams we’ll be able to accurately predict total throughput by understanding the amount of work to be done and the rate at which this work can be accomplished.
While team velocities may be different, the sizes of the work to be done can be agreed to across the organization. This is analogous to the distance between Seattle and Portland being 174 miles regardless of whether you are walking, driving, flying or biking (and yes, I know the distances will change some, but not tremendously).
By having separate measures we can get better stability of estimating our work and seeing the velocity of our teams.
Hope you found this useful.
As always, please contact me if I can be of any assistance.
Al Shalloway
CEO, Net Objectives
