Predicting Mileage
Suppose I were considering leasing a new car. (I’m not, but it makes a good story.) I’d want to be sure that my mileage would fit within however many miles are included in the lease. To figure that out, I’d look at how many miles I’ve driven the past few years. In 2006, I drove 12,000 miles. I drove 10,000 in 2007 and I’m on track for 6,000 this year.
I could use Yesterday’s Weather and predict that I’m going to drive 6,000 miles per year in the future. Or, I could look at the decreasing trend and predict that I’m going to drive somewhat less in the years to come. Either of those options would likely cost me money at the end of my lease because they leave out an important detail: I’ve been a traveling consultant. For me, a year is not a year when it comes to driving. I only drive when I’m working at a client in Denver. Over the last three years, my time at local clients has varied:
In 2008, I’ve traveled far more than in the previous years. In 2009, I hope to find more local work and travel less. (Obligatory plug: If you’re in a Denver-area software organization that could use some help becoming happier and more productive, contact me.) So if I predicted 6,000 miles or less and signed a lease on those terms, I could well end up driving 12,000 or 15,000 and spending a lot of money on miles at the end of the lease.
Since I can’t use my miles in a past year to predict my miles in a future year, I need to get more granular—to a level where there’s more stability in my mileage—and extrapolate from there back up to the year. Dividing the total miles per year by the weeks at home shows that my weekly mileage when I was home was stable across the three year period.
It’s likely to remain that way going forward. (There’s only so far you can drive in Denver.) So if I can predict the number of weeks I’ll be in Denver in 2009, I can predict how many miles I’ll drive that year.
What Does This Have to Do With Scrum?
In Scrum, velocity is a measure of work per unit of time. I usually see work measured in story points, ideal time, elapsed time, or task count. Time tends to be measured in sprints, days, or hours. Most Scrum teams measure their velocity in story points per sprint. For the ideal Scrum team where all team members work exclusively on a single project this high-level measurement is a simple, fast way to predict how much work the team can do in future sprints.
For many teams, however, a sprint is not a sprint. Team members do work on other projects, maintain production systems, go on vacations and holidays, go to training; for a variety of reasons, the team doesn’t work the same amount of time in each sprint. Measuring velocity in work per sprint, then, doesn’t give us the predictability we need to make commitments.
(Note: As a coach, I try to get an organization to transition to fully dedicated team members, but that’s not always a quick change and I’d prefer not to defer predictability until then. Regularly missing commitments is discouraging.)
For these teams, we need to get more granular. So far, every team I’ve seen has been stable at the work per hour level, so I usually go there. Just as we can use points per sprint to predict a future sprint’s capacity…
…we can use points per hour…
.
At the end of a sprint, I look at how many points of work the team completed, and I ask them how many hours it took to complete that work. I want to know not just time spent on their tasks, but all the time they spent on the project. (By asking that, I now have an empirical way to handle overhead instead of just guessing at a buffer or reducing hours per day.) I ask how many hours they plan to spend on the project in the next sprint. From there, I can solve for the points they are likely to be able to complete in that sprint.
The least granular velocity measurement is usually the easiest to track and use, so when I have a team measuring velocity in points per hour (for example), I’m checking at regular intervals to see if the team has stabilized at points per day or points per sprint so that we can start using that less granular measurement instead.
Related posts:
