Software estimation. Ah, a never-ending story. Chances are good that, whenever you’re talking about building software, this subject will pop up soon. You can be pretty sure that basically everyone around has problems with estimation or simply struggles with it. And that’s virtually obvious that there would be a new sexy method of estimation every year or so. The method which is claimed to solve an unsolvable puzzle.
Recently there was yet another question on estimation on Project Management StackExchange. This sole fact isn’t probably worth writing a whole blog post about that, but there was one side thread which is worth focusing at.
One of advices I shared was that whenever you can you should avoid estimation at all. This sprung sort of objection. OK, so the subject definitely is worth wider discussion.
First things first. Why do we estimate at all in the first place? Well, we usually want to know how much time it’s going to take to build this damn thing, don’t we? Um, have I just said “usually?” Meaning, “not always?” Actually yes. It’s not that rare when we either don’t need any estimate at all or we just want to have a general insight whether the project will be built in hours, days, weeks, months or years. In either of these cases just a coarse-grained wild-ass guess should be fine. If it’s needed at all.
OK, but what about majority of cases when we need some kind of real estimate? For example all those fixed price projects where estimates are basically a part of risk management, as the better the estimate is the smaller are chances that the project goes under water. I can’t deny that we need to have something better than wild-ass guess then.
Yet, we still can avoid estimating quite often.
Let me start with one of obvious things about estimation: if you base on historical data, and you apply them in a reasonable way of course, you can significantly improve your estimates. In other words, no matter the method, if you are just guessing how much something is going to take, you will likely to end up with way worse results when compared to a method, which uses your track record. And yes, I just dared to name planning poker “guessing.” It is collective, involves discussion, etc but usually it is just this: guessing.
Cool, let’s use historical data then. What’s next? My next question would be: how precise must your estimates be? Seriously, what kind of precision you aim for? My point is that we need very precise estimates very rarely. This is by the way the reason why I don’t use Evidence Based Scheduling anymore.
Anyway, ask yourself a question: how much you would pay for bringing your estimates to the next level of precision. Think of it like being correct in terms of estimating in years, months, weeks, days, hours, etc. Let’s take just an average several-month-long, fixed-priced type of project.
If I’m wrong with years I’m totally screwed, thus I’d pay significant part of project budget to be correct on such level. If I’m wrong with months it might be a hit on our reputation and also it may consume our whole profit we get of the project, so I’d be ready to invest something around the profit to be correct with months. Now weeks. Well, a week here, a week there, does it make such a difference in this kind of project? Can’t I just assume there is some variability here? Unless of course our deadlines are written in stone, e.g. you adjust your software to law changes. In most cases I’d invest just a handful of bucks here at best. Days? Hours? Are you kidding? Does it even make a difference that I spend a day more on such project?
Now you know what kind of precision you expect from your estimates. Would it be possible for you to come up with estimates of such precision basing purely on historical data? I mean, can’t you just come up with a simple algorithm which automatically produces results reasonable enough that you can forget about all the effort spent on estimation?
Whenever we come to discussing estimation I like to share the story from one of my teams: basing on a fact that we were collecting data on our cycle times and we reduced variability in task sizes coming up with the idea of standard-sized features we were able to do a very good job with estimates not estimating at all. We were simply breaking work down so we could learn how many features there are to build and then we were using very simple metrics basing on our track record to come up with the numbers our sales department requested. By the way: a funny thing is, almost all of that appeared as an emergent behavior – something we started doing as a part of continuous improvement initiative.
Either way, even though we were capable of providing reasonably precise and reliable estimates we didn’t really estimate. I was surprised how easy it was to get rid of estimation, but then I can come back to the point from the beginning of the article: what is the point of estimation? You don’t do it just for the sake of performing the task; you do it for a reason. As long as you achieve your goal, does the method really matter? It means that you can get rid of estimating even if you do need some kind of estimates.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
5 comments… add one
You can never get the right estimates for a software project simply because of unexpected problems and delays. great post thanks
Being involved in such discussions currently, I’d title your post as the previous one “Estimations Are Bad (But Unavoidable)”. You make the very good point about precision. It’ll take so much time estimating in “hour” detail, that the time used could have been used on creating value already.
On the other hand, there are many “agile believers” that truly think that you have to get rid of estimations all together. It’s fine by me if you can deliver. BUT, if that translates into years of delay then, as you said, you’re screwed.
Summarizing: it’s important to estimate in the right level. So first, get the scope, then fine the level, then do the estimate.
And add something for unexpected problems! If we all know that there are unexpected problems, they aren’t so unexpected, right?
@Roger – The point is I agree with “get rid of estimations altogether.” As far as it is possible, that is. I mean, you always need to follow common sense. If your client requires you to make an estimate you can perfectly reject the request and the potential contract altogether. If you have comfort to make such decisions that’s perfectly fine. However I know pretty few companies that operate on such level that they can make such calls very comfortably.
If you are like the rest of us, you will just try to comply with client’s requests. Then, the rules of the game change and you actually have to come up with some numbers. Yet still, you can say that it would be better if you could avoid them at all.
By the way: you probably heard a bunch of stories how switching to time & material contracts, which mostly render estimation useless, improved effectiveness of delivery, e.g. it was faster, adjusted better to business needs, richer in functionality or a mixture of all of those. Of course then we touch the issue of trust between a client and a vendor but anyway it means that you can effectively work without estimation at all.
But no, I wouldn’t say that you should go this way no matter what. Usually it’s not a vendor who sets the rules. We can just try to do our job well and reasonably.
Great post. It clarified something as I’ve frequently landed on the side proposing that we still need to estimate.
What became clear to me is that while we don’t need estimates to execute the project, we frequently do need them to win the project. (At least in my company’s circumstance)
So what do we do? We do the best estimate we can at the appropriate level and then execute the project in an Agile fashion. (and we make it clear how we will execute the project as part of our proposal to set expectations)
For the most part it has worked quite well.
@Terry – I believe that your situation is pretty common for many organizations. Clients very often expect that they will know up front how much time/money/effort this darn thing is going to take. To be honest, I do understand them. Sometimes you are just so clueless that you don’t know whether you discuss a few weeks worth project or a year long endeavor.
By the way, another story to tell is what happens when you go past initial deadlines. In vast majority of cases it isn’t really a problem, as initial deadlines is just sort of negotiation position which is a starting point for getting a bunch of features without changing a price or covering up for not delivering their deliverables on time or whatever else.
I know really few projects that have a deadline really written in the stone. For the rest of them the whole estimation thing is more about setting and managing expectations.