Giving realistic estimates

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*.

Giving realistic estimates with planning pokerTo 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!
So understanding the stories is a nice by-product of planning poker. Matt Wynne goes one step further and says that the estimate is a mere byproduct of planning poker.

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.

One thought on “Giving realistic estimates

  1. Playing cards is fun. Yeees. Nico and me have been playing this game for not for so long ago.
    I noticed myself that one tends to look into the problem from a very high level view, which is necessary in the beginning. Specially when you are building the story. But at the moment of making my ToDo list with the time estimation it happened that I put big tasks that may require days to complete in my opinion. Then, I begun the project and found out many many nasty details that need to be addressed. Those started adding up time to my original estimations. Ahhh panic panic. Yeah, for many software engineers that may not be a surprise.
    One of those days that I have to do an estimation again someone told me, let’s play cards. What kind of joke it is? I tought.
    I accepted and we begun.
    When I played the poker for the first time with Nico I wanted to use the big cards (yeah my list had big points), but he said “No no, we only use low values” Ouw!! I got shocked. Oh no!!! Now what, Do I have to split my task in subtasks? And the answer was yes!. Divide and conquer approach is what basically the game led me to do. And all the things Nico wrote here happened with my time estimations.
    Since that first time I refuse to give time estimations on the fly even tough sometimes people try to force me to do so. You hear things like “how difficult this can be? is just changing a number here and making a list there”. “But this is very easy. Common give us a number” “You already have experience with this, you should have an idea about the how long”
    Of course nothing is absolutely perfect and/or apply to everyone. But to me it proved to work pretty well. The delays still happen for various reasons, but at least they are a loot less than before.

Leave a Reply

Your email address will not be published. Required fields are marked *