Estimation Myths Debunked!

Estimations cause pain and panic.

Estimations make everybody’s life a misery.

No?

We’ve recently conducted a short internal webinar which we’d like to summarize to combat some stereotypes you might have of this issue and help you understand why it’s important to estimate - in fact, to estimate right.

What is an estimation?

Estimation is a guess. By definition. However, you can take steps to ensure that it will be at least a well-informed guess - and here are some tips and tricks on how to do it better!

So the basics - who should do the job? No, not your client. And no, not a developer who isn’t in your project. No, not the project manager, either.

The people who could do it right are you and your project buddies since you’re the ones who will actually be involved in the implementation of whatever it is you’re sweating over. And you can always try planning poker. That helps a lot!

For better understanding of the feature / app you will be developing, prepare yourself:

• Do your research - carefully read the brief/ specification of the functionality.

• Ask your client, PM and UX questions.

• Research, research and research again - you will definitely find out something that will help you to pinpoint the potential issues and ways to deal with them.

• Know what you want to use - do the research and choose the most appropriate solutions, tools, gems etc.

• Ask around - you can bet your life that your colleagues are a diamond source of knowledge; a question posted on your company chat could unleash lots of handy insights.

With the above in mind, never estimate unexpected things on a call with your client and always ask for some research time. Even the easiest things can turn out to be monstrous.

How to estimate a feature?

After doing research keep in mind what an estimation of a feature actually involves:

feature = planning + actual work + tests + code review

Remember that time for all of this needs to be added to the initial feature estimation. Without it you will probably underestimate it. Well, we all have situations when we are not 100% sure about something - a number of unpredicted variables may and probably will pop up during a project. Call it risk management and add some padding! You never know what the future brings!

Wrapping up - we’ve prepared a short checklist to remember:

DO’s:

1. Gather requirements (ping pm/ client if needed) and do your research (mockups, APIs, edge cases...)

2. Ask when in doubt and explain when something’s amiss

3. There is always room to screw up and for things to go wrong - add padding

4. Track elapsed time and learn from past experiences

5. Ask around - check with others / internet / seniors / grandma / PM /

6. Use more than one method to arrive at an estimate, and look for a midpoint among all of them.

DON’Ts:

1. Never estimate during the call!!

2. Don’t let someone estimate for you

3. Don’t estimate without checking that you have everything

4. Always predict the worst-case scenario

Bugs - to estimate or not to estimate?

Ok, we have features covered. You might think that’s easy peasy but what about bugs? How to get them estimated? The answer is - don’t. No, seriously - DON’T. Bugs and chores always crop up over time, and while they are a part of your project, they can be a constant drag on business-valued output. In addition, if they need to be fixed that means a developer has to do lots of digging into the code to find out what might be the problem.

But if you really have to estimate a bug - you need to emphasize that it’s a bug and the initial estimation can change drastically. A good way to do so is to indicate it somehow in your project management tool, e.g. give it a ’no-idea’ label. Also it’s very important to track the progress and if necessary own up if your guess was wrong - it’s always helpful for all sides to see/ hear an explanation why it’s taking more time.

Failures in estimating sometimes happen. What causes them?

1. The presence of hidden or unknown variables that are difficult or impossible to anticipate, and sometimes even more difficult to resolve.

2. Our often-idealistic views of our own capabilities. We frequently believe that we can achieve much more than is possible in the available time.

3. A strong human desire to please other people by telling them what they want to hear. (After all, who wants to be the bearer of bad news?)

Always let your project manager and client know in case of any unexpected delays & blockers. Don’t be shy - they won’t bite but it will help them to plan other work and reflect on how to manage deadlines.

There is rarely a way to execute responsibility taken during the estimation process. The feedback loop however helps developers to do this more efficiently and project managers to know their team better and help them improve in that field.

Sit down and review estimations with your team during the retrospective. Also, as a developer, if you have a bigger feature or a bug - track your progress in the meantime and check it regularly with any blockers. Finally, confront it with your initial estimation - this will help you to learn a lot.

The more of these exercises you make, the better your estimations will be.We are not trying to pull the wool over your eyes and convince you that you won’t make mistakes, though. In the end, there are only estimations ;)

Also, enjoy the presentation by Błażej prepared for our internal webinar.

Thanks to Małgorzata and Błażej for contributing to the post!

If you're into project management, you probably dread bugs as much as we do! Our Project Manager Agnieszka shared a few thoughts on dealing with bugs within an iteration.