One thing a lot of programmers are excellent at is giving realistic estimates. Especially when asked at the coffee machine, we’re often right on the spot. Well, ok, maybe not so much. Ok, we’re not even close to it most of the time.
What to Say When Asked for an Estimate
You say “I’ll get back to you.”
You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.
This is what you get when you ask it on Stack Overflow. And guess what? They’re correct! No-one should ever ask you for an estimate on the fly*.
To understand why, we have to dive a bit into planning poker. When you see programmers in a meeting room playing cards, it can mean only one thing: they are playing planning poker. Why does that work?
- Planning poker starts a dialogue about the stories at hand.
- Explaining your problems to others, even a duck, can help you understand them.
- If two peoples estimates widely vary, they can explain why they made this estimate. Most of the time this is a learning moment for both of them.
- Planning poker is fun!
The most important benefit you get from planning poker is the conversation. As part of the exercise, you explore the story as a team, and uncover any misunderstandings about the scope and depth of the work to be done to satisfy the story. The result of this exploration is a shared understanding of what the story means.
The feedback of your peers will uncover new scenarios that would have otherwise been overlooked. The art of software engineering is to model to reality, but simplify it so that it’s manageable in your head. Sometimes a new scenario can mean that you have to change your model, and thus will take a different time to accomplish.
Even if the new way will take about the same time, it’s much nicer to find it out while you’re still in requirements engineering. There are not a lot of facts known in the world of Software Engineering, but one of them is that you want to find bugs as early in the process as possible. How about before it’s even made?
The actual estimate might not even be different from what you would have estimated by yourself, but because you know some of the edge cases before hand, it will be more accurate. So do not give an estimation without peer feedback :-).
If you’re part of the people that need the estimate, just ask “Can you make this estimate for me?” Do not mention the time you think it might take. A lot of programmers might base their estimation on that time, which is not what you want.
* It’s possible to make some estimations on the fly, but only if it’s small and you’re completely sure of the boundaries of the project. It just makes giving realistic estimates harder.