Noel Rappin Writes Here

In true blog form, a declarative statement:

Hear ye, hear ye! Any so-called Agile team that ever tries to translate “points” into actual units of time is presumed dysfunctional until proven otherwise.

You’ve done it, I’ve done it, we’ve all done it. Doesn’t make it a good idea.

In the spirit of my last post, allow me to over-explain.

A typical Agile project handles estimation by splitting the project up into smallish user stories and assigning each one a point value, typically between one and five, though different teams have different standards. During each iteration, typically on the order of two weeks, you count up how many points you accomplished and that becomes your velocity, or the estimate of how many points you can do in an iteration. Then, that total can be used to estimate how many iterations are left in your project. (I oversimplify, of course, but that’s the idea.)

At first glance it seems ridiculous to try and estimate time without using time units, but in fact the idea is genius. It actually doesn’t matter how accurate you are as long as you are consistent. Always underestimate things by 50%? You’ll do less points in the first iteration than you’d expect, but once you establish a baseline, it doesn’t matter, you’ll still do about the same number of points each iteration. Don’t know whether an estimate includes testing or refactoring? Don’t want to estimate bugs? That’s fine. As long as bug fixing or testing or whatever is a reasonably consistent amount of time from week to week the point method will still work.

You’ve replaced a very hard task – estimating exactly how long every programming job will take – with a much easier and more accurate one – estimating the relative size of some of your programming tasks.

There are only a couple of problems with the point/velocity method. One is that you don’t get good estimates until the project is a few weeks underway. Of course, with a more traditional method you don’t really have a good estimate either, but you do have the illusion of one.

Also, there are at least two classes of people who really, really don’t like point estimates: people who pay you by the hour, and people with Gantt charts.

People who pay by the hour are a legitimate issue – they have a reasonable need to understand what their costs are going to be. Interfacing an agile project with a client can be complicated, but it’s also not the issue I want to write about today.

People with Gantt charts, by which I mean anybody outside the technical team who is unwilling to accept point-based estimates, can be a real menace to an agile team. In my experience, this starts with the innocent-sounding question, “What does a point stand for?". I maintain that the correct answer to this question is, “I don’t know, but we do ten of them a week” if you are feeling generous, you can add “and we have 75 of them left to do.”

Sometimes that will be enough, either the managerial type will trust that you know what you are doing as long as you hit your deadlines, or the person will do the math themselves and fit it into their own process as needed. For instance, my various managers at Motorola were generally okay with me using points internally to my team as long as I was able to provide them a completion date for an entire release, which was not a problem.

Other places will require an estimate in “real” hours or days for reasons of varying legitimacy. You might get asked to provide estimates for each story in real hours or days rather than points, or somebody might come up with a conversion factor between points and days. The origin of an agile story point is the idea of an “ideal day” of development without distraction, so the thought that a simple conversion between days and points might exist has a certain intuitive appeal.

If you are doing this conversion at the behest of the rest of your team, you have at least two problems right now.

First off, you’ve lost the simplicity of the point estimating task, and you’re back to the complexity of absolute estimating. I know it doesn’t seem that way, and I suppose in theory it’s possible to use hours in a point-style estimate. In my experience, though, when external forces want hours, they want exact hour estimates for each task.

The value of points is that there are a lot of implicit assumptions about consistency: time spent on bugs, time spent on non-developer tasks. That works in the points world because it’s relatively abstract. But talking about estimates in hours places a powerful expectation that you need to separate that time back out into each individual task. So even though hours and points seem similar, in fact, it’s very difficult to actually work with them similarly.

Secondly, if you work in points and then translate that to days, you now have two reasonably similar sets of estimates floating around. Confusion is inevitable. Motorola used to distinguish between “unloaded” and “loaded” estimates, where an unloaded estimate was ideal developer time and loaded estimates made the somewhat optimistic assumption that 1/3 of a developers time would be spent on non-developer tasks. What happened? We were forever asking each other whether an estimate was loaded or unloaded, and forever forgetting which it was. I’m pretty sure that some estimates were converted to loaded multiple times.

All this is indicative of the larger problem that you probably have if you have been asked to start converting points to hours. Ideally, in an agile project, it’s the technology team’s responsibility to say how much a feature costs, and the business team’s responsibility to say how valuable the feature is. The combination of the two factors is what makes up the agile project plan. You don’t want the business team determining the estimates any more than you want the technology team determining business value.

If the business team is driving the format and structure of the estimate then it’s the project equivalent of a code smell. It’s not impossible that your project could still be running smoothly, but it is strongly suggestive that the business side is looking to own the cost side of the equation. In which case you potentially have a very large problem, the most likely manifestation of which is strong pressure to claim lower estimates to provide the illusion of being on schedule.

Which brings us, at long last, back to the beginning. An agile project that is converting points into real units of time is potentially dysfunctional because it’s a sign that a) the advantages of the points/velocity system aren’t being fully utilized or b) the business team is having too much influence on the creation of estimates, or possibly worse. It’s possible that things are still okay, but the presumption is that this estimation style does not encourage good agile practice.