Never miss one of my articles: Readers of my newsletter get my articles before anybody else. Subscribe here!

In the last post, I wrote about how you can get started with #NoEstimates when you use story points right now. Today I want to write about different kinds of estimates. [You might be also interested in: What is An Estimate, Anyway?]

There are different techniques to come up with an effort estimate, and the estimates themselves are different. We can classify these techniques and estimates along a spectrum with different axis:

• Direct vs. Indirect: Does the estimate express the effort direclty (time, cost, ...) or does it express something different from which you can derive the effort (size, ...).
• Concrete vs. Abstract: Somewhat related to the point above, is the effort some concrete mesure or something more abstract.
• Fine-grained vs. Coarse-grained: What is the size of the things you estimate (hours, days, months, ...).
• Simple vs. Elaborate: How hard is it to come up with an estimate? How hard is it to understand?

Today I want to write about some techniques to come up with effort estimates. I will also try to classify them within the above spectrum.

Estimating Time Directly

Here you try to estimate the time it takes to implement a feature or to fix a bug. The unit of the estimate “person days” (or something similar). Sometimes the project manager or lead developer creates the estimate based on her experience, sometimes the team creates the estimate together.

Within the Spectrum: Direct - Concrete - Coarse-grained - Elaborate

This approach has many problems. The biggest two are: It is very hard (or maybe even impossible) to create accurate time estimates. We humans are just very bad at that. And all work tends to fill the time available. This means if you over-estimates the time it will take, the task will probably then take the longer time.

I was in two projects that estimated time directly in career as a consultant. In one it did not work at all. A week before the release, everything was 99% complete. On the day of the release, we found out that we had to postpone the release for three months.

In the other one it seemed to work very well: We completed everything in time and within budget for almost two years in a row, even though we did not create the estimates - The chief architect did. It was totally predictable for the customer. So how did we do that? Of course, the estimates were heavily padded. We would often sit around for days and… compile… because new work only arrived after the old work was supposed to be finished. Worse than that, it was next to impossible for our customers to change anything that was already planned. Which is not good.

Estimating Tasks in Hours

A variation of the above, but finer grained. You don’t estimate big features, but small engineering tasks. The unit of the estimate is “hours”. The people doing the work create the estimates. You can then e.g. create a sprint burn down chart based on the remaining hours.

Within the spectrum: Direct - Concrete - Fine-grained - Simple

When I first learned about Scrum, I learned that you should estimate tasks in the sprint planning in this way. Somebody else once told me that you should estimate tasks in quarter days. Because two hours is totally more reasonable as a unit as one hour… Really?

The problems are basically the same as above, but there is another problem: The time spent estimation is probably wasted. Why would you want an estimate for something that takes only a few hours anyway? I think - or I hope - Nobody does that anymore.

Just Count The Tasks

Instead of estimating the time it takes to complete a task, you just count the number of tasks. A task should take less than a day anyway, so you can safely assume that most of the tasks are roughly the same size. You can then e.g. create a sprint burn down chart based on the remaining tasks.

Within the spectrum: Indirect - Abstract - Fine-grained - Simple

This solves some of the problems mentioned above, but you still have to identify all the tasks early to get meaningful statistics. Within a time-boxed planning meeting, you might not be able to do this. And it’s maybe even more agile to not even try to identify all the tasks upfront - This leaves options open.

As far as I know, most teams have even stopped counting tasks and create their burn down charts based on the story points remaining or the number of stories remaining.

Estimating Ideal Time + Load Factor

Some people (in the early days of Extreme Programming) tried to estimate features in “ideal engineering time”. The unit of the estimate is “person days” or “pair days”. The team or a part of the team creates the estimates.

Within the spectrum: Direct - Concrete - Coarse-grained - Elaborate

The total time required would then be much longer, because of interruptions, mistakes, and so on. You can calcualte a load factor that tells you how much longer it will take (on average) to complete something. A load factor of “3” means that you need 3 real days for each ideal engineering day.

Fog Creek Software used a technique like this Evidence Based Scheduling some time ago. I don’t know if they still use it, but as far as I know this technique has come mostly out of fashion.

Estimating "Size" With Story Points

You try to estimate the size of the work and then derive the expected effort from the estimated size. The unit of the estimate is “story points”. The team comes up with the estimate, often with “Planning Poker”.

Within the spectrum: Indirect - Abstract - Coarse-grained - Simple

With all the problems of the direct, concrete estimation techniques, some people decided that we needed something more abstract and indirect. So they came up with story points.

The basic idea is that it might be hard to agree on how long something will take, but you can still agree on the size of the something. Suppose you want me to build a brick wall that is 10 meters long and 2 meters high. I have no idea how long I will take to complete it, but I can agree that the wall is 10 meters long and 2 meters high. Once I have built some brick walls, I might tell you an average duration per square meter. Or I can tell you how many square meters of brick wall I can build in two weeks - My “velocity” in terms of story points.

The problem with this technique is that you estimates will probably still be very inaccurate. One five point story might take a day to complete, another one two weeks. Some people will tell you that the inaccuracies will cancel out, but when you don’t know why they do, your estimates are just numbers out of thin air.

Most teams I consulted so far used this technique.

Function Points do also seem to estimate the size of the requirements, but are more complicated and out of the scope of this article.

Just Count The Stories

So, even story point estimates are still quite inaccurate. And the estimation takes some time, which is possible waste (i.e. not used to produce value for the customer). Maybe we can still come up with meaningful data with something even more abstract and simpler? Well, just count the user stories.

Within the spectrum: Indirect - Abstract - Coarse-grained - Very simple

As with “Just Count The Tasks”, you want most of the stories to be roughly the same size. The idea is that if the stories are simple enough and well understood enough so that development could start, the will be roughly the same size.

Your planning horizon will be shorter with this technique, because you only want to come up with detailed stories shortly before you need them. But this is often no problem, because it creates options for the longer planning horizon. Or you could only use this technique for the longer planning horizon, where you only count bigger features, not individual user stories.

Conclusion

All of the techniques can provide value under certain circumstances. You should not discard one of them because it is “too abstract” or “too simple” or “too complicated”.

But you can ask yourself “Could I get all the information I need with a simpler technique”? And from there, you might find ways to improve.

Do you have any questions? What would you need to get started with something simpler than you have now? Please tell me!