Perhaps the most difficult question a developer can get asked is : “How long will it take?”. Developers know the story, give an estimate, ensure PM knows it’s only an estimate and do your best to finish within the given estimate. But should your word really be your word, and should estimating really be a skill you get better at. No and it depends!
The landscape in IT is changing fast, and because of this the only way you can keep up is to learn new technologies. From a company point of view, it is likely you’re using new technologies every so often. Every time you use a new tech, your estimating mechanism needs refinement. Without experience in a new tech, estimating down to the last MD, is going to be tough depending on the complexity of the application, piece of work or task.
Should your word be your word?
Creating a complex piece of software isn’t as predictable as cooking. There are way more unknowns you need to factor in. Let’s look at a simple comparison. If someone asks you how long would it take to bake a cake, you could work out all the steps required, and give an accurate estimation of how long it would take. This is why your wife will often tell you “Food will be ready in 20 minutes”. She knows because unless the house burns down, the food always takes the same amount of time to cook, and there are not many unknowns.
Software on the other hand is complex. You might decide to use a new framework, only to find out there is a bug in it. You might be targeting a certain browser, only to find out it didn’t quite render as you expected. You might end up overlooking some small detail, which turns out to later be a stumbling block and might take you a day or 2 to solve. Connected systems might misbehave, something like a proxy server you didn’t know about or anticipate. The list is long. So long You could write a full book on what can start going wrong, when the task was considered in theory to be “2-3 hours work”.
The correct answer to how long it will take is “I don’t know”, but as a developer you are expected to give at least some kind of estimate. The problem I have found is that all too often a PM understands it is just an estimate, however, You are still required to at least be estimating semi accurately, because the estimate you give will find its way into a project plan, which in turn when the PM does status reporting to the product owner or customer he’ll be using your estimates. At this stage a whole chain of people are relying on your estimates – so without correct planning – don’t commit to an estimate – as “My word my bond”.
Scrum doesn’t solve this issue
You might think, it’s time to scrum up surely well defined sprints can help us meet our deadlines. Scrum (from what I’ve seen) doesn’t really help much. The problem is software development is complex and a lot can (and most likely) will go wrong. Scrum provides a project management framework, but it is not at all concerned with the exact technical issues you might face on a project. Yes it will help you break work down into smaller, more manageable units, but even so there is no way to predict what issues you’ll face without better planning.
Better planning helps somewhat
Estimates in IT are all to often cart in front of horse. You’re often asked to estimate a task, even prior to full blown planning. Sometimes you’ll have a workshop which might last 1-3 hours. After this workshop – the PM jumps into position with the usual question “Ok guys how long will this take?”. Here most devs try to be reasonable, and give an estimation. For example 2-3 days. A week later the PM can’t understand what went wrong, why isn’t the stuff finished.
Workshops are useful, do your quick diagrams on the white board, but before you commit to any estimation take the ideas back to your desk and (depending on complexity) open up Visio and draw up some real flow charts. Plan the whole thing properly. Workshops often are conducted in haste, and stuff gets left out. Workshops, real planning, peer review of planning, and now it’s time to provide some estimates.
Give 2 estimates:
Give a best case scenario estimate, one in which you will only encounter slight hickups but you are confident you can easily overcome. And then give a worst case scenario where you get stuck at all the identified pitfalls, and get let down by logistics and have to wait around for stuff, etc). But obviously don’t quote 3 months for a job that should reasonably only take 2 days. Be pragmatic, but don’t be unreasonable.
Should you be getting better at estimating?
You should be getting better at estimating similar tasks on known technologies. But you shouldn’t ever get to the point where you become so good at estimating you give answers without even thinking. You should definitely be learning how to estimate, but estimating is a bit like Golf, no matter how good you are, you’ll never be 100% accurate at it. What you really want to do is improve your method of estimating, and learn when to say “I don’t know” or “This requires more researching”. Don’t think of estimates as hard values.
Educate your project managers. Make an estimation – and when they get back to you with “You’re late” no matter how politely this gets brought to your attention, you need to make it clear that the initial suggested time, was an estimate.
Raise alarms
If you hit show stoppers, notify your PM as soon as possible. This will mean he can start shifting the estimate. Rather than finding the delay out later when he was expecting a result.
Note to PMs:
If you don’t have a background in IT and are used to working as a general project manager, then acknowledge that the most difficult for a developer to answer accurately is “How long will this take”. Experienced developers might actually give you longer estimates, just because they realize more pitfalls, or because they’re factoring in stuff a junior can overlook. Try to play devils advocate during the planning phase to encourage the team to think about the details of the task at hand, and to minimize the unknowns on any given project.
Michael's Techbox 