Throughout my career one of the biggest sources of tension between the development and management teams has always been estimation.
“How long will it take to implement feature X?” asks a roving manager, unexpectedly disturbing my workflow.
“Uh, I’d have to look into it with the team and get back to you” I reply.
“Just give me a rough idea” they say (hint 1: the ‘rough idea’ will become a firm commitment as soon as it leaves your mouth)
“I don’t feel comfortable giving you an answer until I’ve spent some time looking into it” I reply.
“But it’s just a simple change” they say (hint 2: it’s never just a simple change)
“So I’ll look into it and get back to you” I say.
“Forget it, I’ll ask someone else” they say, and walk off.
Two days later I’ll learn that the client was promised 3 months worth of work by the end of the week after the manager finally found someone who could be bullied into giving a number (the wrong one) and I’m getting chewed out both for refusing to give the manager an inaccurate, off-the-cuff estimate, and not succeeding in delivering the feature to the impossible deadline created after someone else gave an inaccurate, off-the-cuff estimate.
OK, so I’m exaggerating a bit, but I’ve certainly worked in places where that sequence of events would have felt eerily familiar. Software projects are notorious for overrunning, regardless of company size or sector and actually, when you think about it, that’s a bit odd. Software development, for the most part, is decently funded, it’s performed by intelligent, well educated people who specialise in algorithms and problem solving and yet, somehow we can’t answer a simple question ‘how long will it take?’ with any degree of accuracy. Or, more specifically, we consistently manage to underestimate how long it will take to do something.
So why is that? In fact, there are few causes, each of which contributes a little inaccuracy which eventually combine to result in a big inaccuracy. I’ll take each one in turn.
Factor 1: Developer optimism
That’s right – software developers, as a whole, are some of the most optimistic people you’ll ever meet. What? That doesn’t match your personal experience of them? OK – I should qualify: Software developers are some of the most optimistic people you’ll ever meet, when considering the amount of work required to complete a task.
Ask a typical developer how long it will take to add a feature to the system and they will almost always make the following assumptions without even realising it:
- The requirements will be complete and accurate when coding is started.
- No research or training will be needed to complete the work – everyone already has the necessary knowledge and skills.
- All tests will pass first time.
- The same developers will work on the feature from initiation to completion so no hand-overs will be required.
- Every line of code will be right first time and no re-work will be needed.
- Everyone involved will be immediately available at all times – no-one will take holiday, be unwell or be called onto other projects.
Now, to be fair, everything listed above is impossible to predict and therefore impossible to estimate for – how many tests should we assume will fail? How many times should we plan to be sick? But all these things can and will happen over the course of a typical software project and need to be taken into account. Realistically the only way to do that is to add contingency – say a 20% uplift in estimates to take the unexpected into account, but that can clash with another personality trait that is common in developers – a strong dislike of inaccuracy or dishonesty. Adding contingency can feel like cheating to many developers – It’s asking for time you don’t know you’re going to need. Also, adding contingency makes the estimate feel more inaccurate, so even if a developer is encouraged to add contingency to their estimates they might not actually provide it.
Factor 2 – External issues
“How long will it take to do X” asks a manager.
“Uh, actually this doesn’t sound too bad,” I say. “We can probably get completed in a week.”
“Great, I’ll tell the client to expect it by next Friday” says the manager.
“Oh, did you want us to start on it right away?” I ask.
“Of course,” says the manger, “it’s your top priority.”
“What about everything else I’m working on?”
“That’s your top priority too,” says the manager with a smile, and strolls off to make someone else’s life more difficult than it needs to be.
Again, I’m exaggerating a little, but not by that much. Even if your manager understands that you can only work on one project at a time, there’s always something going on that steals time from the project. Meetings, company updates, requests for help from other teams, recruitment, emergency issues with the live system, fire drills, managers appearing out of no where and asking for estimates for the next project, these are all things that will happen and prevent you from progressing the project. Each one might only be a little time here and there but it all has an impact. Also, it apparently takes 23 minutes and 15 seconds to get back on track after being distracted from your main task, so that ‘just 5 minutes of your time’ will actually cost the project closer to half an hour, and those half hours quickly add up.
Factor 3: “Really? That long?!”
Fortunately, in modern times, the stereotype of software developers as weird, socially awkward guys (and only guys) with poor communication skills and worse hygiene has started to fade, but in many companies there can still be a level of suspicion and mutual distrust between the software team and the rest of the business. We can be seen as different, a bit odd, and possibly not ‘team players’, especially when there is existing tension – perhaps due to an existing history of project overruns.
This can cause a problem when supplying estimates to management, as on receiving the estimate, the manager starts to think to themselves ‘ok, is this really how long it’ll take, or have they padded it out so they can spend most of the next month playing computer games?’. They may then reduce the estimate, not because they distrust the developers – of course not! They’re doing it because they believe in the development team and know they can achieve more if given a little push! (and kept off their games consoles). Naturally this will be a disaster if the estimate comes from one of the developers who never puts in any contingency but no-one will realise that until the end of the project (and even then no-one will realise why the project’s overrun by roughly twice the amount of time taken off the original estimate!)
Agile has the answer!
So hopefully by now you’re starting to see the problem – the reason we can’t get accurate estimates is that there’s too much unknown during any given software project – even if we can make a reasonable stab at how long a given piece of work will take, we can’t estimate how many problems will occur along the way, or what else will be going on in the company that requires our attention, and even if we could come up with a figure for all of that, no-one would believe us. So it’s hopeless, right? Well, no – there is an answer, kind of.
The agile approach to estimating is to turn it on its head – forget inaccurate predictive approaches (e.g. guessing) and start measuring things. I’m going to get the big disclaimer out the way now – this approach will not let you tell your manager the exact number of hours a large project will take before you’ve started working on it, which is a shame because that’s exactly what he or she is going to want. Instead, it lets you use maths to give an indication of how much longer a project will take once it’s been started, but that’s pretty cool too.
The approach is fairly simple – work out everything that needs to be done for the project, and this can be as high level as you want, so long as it breaks the project down into multiple chunks (the more chunks the easier this is and the better the results will be, but there’s no need to spend months identifying every class that needs to be changed). Next, score each item on the list, not by how long you think it will take, but how complex it sounds. What makes a task more complex? Interacting with external parties, lack of knowledge in the team, needing to write something from scratch. What makes a task less complex? Having done something similar before, good understanding of the requirements, minor tweaks to an existing system.
Most companies I’ve worked in use ‘story points’ for this which are completely arbitrary and have no correlation to anything outside the project. A 1 point piece should be the simplest thing you can imagine having to do as part of the project, a 2 point piece is twice as complex, etc. To make life easier, most teams use some variation of the Fibonacci sequence so e.g. 1, 2, 3, 5, 8 and 13 and so on are allowed, but numbers in between are not. This avoids getting too hung up on whether a given piece is worth 11 or 12 points – just round to the nearest permitted number. An alternative, especially for teams that struggle to estimate complexity rather than time, is to use ‘t-shirt sizing’ where each piece of work is assigned e.g. ‘XS, S, M, L or XL’. This helps emphasize that scores are not hours or days but you may need to turn them back into points to do the maths later on.
Next, just start the work, but time how long it takes to complete a piece from start to finish. Actually, for most Agile approaches you’ll be creating a fixed time-box and seeing how many pieces of work you can get done in that time, which is better because it takes into account that there are probably multiple people on the team and so some work can be done in parallel, but ultimately the most important thing is we end up understanding how long the work is taking to complete in the real world.
When you’ve completed enough tasks (again, more is better and will give a more accurate result), you can work out the average time it takes per story point. It’s important to understand that we don’t need e.g. every 5 point piece of work to take exactly the same amount of time – some might turn out to be unnecessary and not take you any time at all, others might drag on and on, hitting problem after problem. On average though, if you take a large enough group of tasks of similar complexity, you should find that it takes roughly the same amount of time to complete as any other group containing the same number of tasks of the same complexity and that’s how this approach works.
Finally, count up how many story points have been assigned to all the work that still needs to be done and multiply it by your average time to complete a single story point and you’ll get an estimate of how much longer it will be until the project is finished – taking into account the distractions, rework etc that you’ve experienced so far (again, on average these are likely to remain constant). If anyone doubts your figures, you have measurements and maths to back you up! If the scope of the project is expanded or contracted you can take that into account and provide new estimates for the remaining time required to complete the project. As the project goes on your average time per story point will become more refined and accurate and therefore so will your estimate.
Job Done!
