I wrote about increasing velocity in my last post, but I just can’t let it be. I have to tell you about the dark side of velocity and why I don’t recommend that teams track velocity.
Velocity is the amount of work a team can accomplish in a fixed period of time. It’s used to estimate the number of stories that can be implemented in a very short time horizon, which is usually between one to four weeks.
The way we compute velocity is variable and because of that, it can’t be used for comparisons. Velocity is a form of estimation that exists solely for the purpose of estimating the amount of work a team can accomplish within an iteration. Velocity is optimized for this one purpose and not for measuring productivity or comparing one team to another team, or even comparing the same team to itself just a few months earlier.
The way we like to say it is that velocity is a capacity measurement, not a productivity measurement. Of course you can say that but it might be a lot harder to get people to hear it and this is one of the main reasons I don’t like to use velocity. Invariably people who are somehow removed from the team see the numbers and think of them as some kind of measurement as to how the team is doing.
Far too many times I’ve seen teams sacrifice code quality for velocity when it was the absolute wrong thing to do. Software development is not a race. Don’t let the terms “velocity” and “sprints” confuse you. Software development is a thoughtful engineering discipline and when it’s practiced well, it’s practiced efficiently and effectively. When it’s being micromanaged, it’s operating at suboptimal levels.
I had the honor of working with many of the top software development teams on the planet. I trained over 2,000 software developers and testers at Microsoft and nearly 4,000 software developers at IBM. I have trained software developers for about a third of the Fortune 100 companies as well as hundreds of smaller companies. In my thirty-year career as a professional software developer, I have seen what goes on in the industry and I perhaps have a better view of this than most people.
We do have a legacy code crisis, but that doesn’t mean we have to freak out and panic. It’s just telling us that there’s a lot of room for improvement in our industry and we do have solutions, we have best practices. We simply have to use them together to reap the benefits.
I do teach teams how to measure and track velocity because I offer Scrum Developers Certification, so I have to. It’s one of the requirements that developers understand the basics of the Scrum framework. Of course, I add the usual caveats.
What is important is understanding that the amount of work a team can get done in a fixed period of time is not itself fixed, it’s variable and it depends on a variety of different factors from the difficulty of the tasks to the weather outside.
The very best teams I know do not track velocity. They just don’t find it a useful measurement. They’re mature, they understand their process, and they don’t find that velocity informs them of much. So rather than track data that’s not valuable to them they simply don’t measure it.
For those who do measure velocity, I would suggest that the unit of measure you select represents effort rather than ideal hours.
I used to measure velocity as “ideal hours” where one ideal hour represents about two real hours. But then I noticed that the team was limiting their efforts in terms of hours. So a “four-hour task” would get done in four hours even if it really turned out to be just one hour of effort.
Measuring effort turns out to be more useful.
To measure effort what we do is we take the smallest story, the one we think is easiest to implement, and we call it a “two.” We call it a two because we may come across one that’s even easier. Then we look at the other stories we have to do in this iteration and we rank them relative to the first story so the next category would be a story that would be about twice as difficult as the first story. The category beyond that would be twice as difficult as the previous story, and so on, allowing us to rank at a gross level the relative difficulty of the stories that are going into iterations. Some teams find that helpful.
If you really want to track work, the best teams I see simply count stories. They’ve gotten so good at breaking stories down into their smallest components that each story is small and somewhat uniform. So they simply measure the number of stories they accomplish in an iteration and it gives them an idea of how many stories they’ll accomplish in the next iteration.
Sounds pretty simple, and it is. Let’s not make things harder than they have to be.
Previous Post: « How to Increase Velocity
Next Post: Collective Code Ownership »