estimation [Article] How to make realistic estimates when working with software development

[Jimi Wikman]

Estimations for software development seem to be the bane of almost every company, but why is that really? Why is it so difficult to approximate the time and effort required when we do this all the time? There are a few reasons and in this article I will go over how I do my estimations and give you some of my experience on how you can maintain a 90% accuracy in any project.

For a good estimate you need to start with one very important thing: define if you estimate based on time to complete or  time to deliver. These are very different because the time to deliver will be substantially higher and much more prone to variations. This is because in the daily work you will be dragged into meetings, have people distracting you and so on. For good estimations we always estimate on time to complete as our basis.

Stop doing happy estimates

The worst thing you can do is making happy estimates. These are estimates based on the utopia that everything will work smoothly and you will be left in total isolation to focus. It never happens and Murphy is always present. Happy estimates may seem good because the product owner love low estimates, but they hate when you fail to deliver.

Happy estimates usually happen when an architect is stressed and throw out a guesstimate on the fly. It will almost always bite you in the butt because not only will everything seem easy to the architect, so they will underestimate it, they also never consider Murphy.

You do not estimate to be nice, you estimate to give a realistic view on when something can be available in production. If you have a hard time to stop making happy estimates, then implement this very simple rule:

"Any time that is needed beyond the time you have estimated you will do in your own time without payment"

Take your time doing estimates

An estimate is not a guesstimate that you throw out on a high level requirement. An estimate is your promise on when you can deliver and as such you should take your time and think that through. Don't sit around doing arbitrary guess work in a planning poker or play with t-shirt sizes unless you want to avoid doing any estimates at all. That type of guesstimating is for high level requirements, so make sure they stay there.

Break down the requirement and use your experience to guide you to a first number in your estimation. This estimate is how long it will actually take to sit down and build based on the requirement. Make sure that you ask questions to clarify where needed so have the information you need. This is also a good time to start working on a solution design to make sure you have considered things that may not always be apparent. For example validation of data in integrations or extending a JavaScript validation for a new form.

When we have done this, the number is still wrong, but we need it as a starting point.

Add the things you forgot

Now that you have done your estimate, many think they are done. That is rarely the case, so let us add the things that is not included yet. The most obvious problem that I see a lot is that the estimates is usually done by the most experience person, which also usually is the one that work fastest of everyone in the team. So what we do is to look at the estimate and the team, then we adjust based on what the slowest person in the team think is appropriate. This way we know that the base estimate is reasonable for everyone on the team.

The second thing we do is to consider Murphy. Things always happen and based on the complexity we increase the estimate with 20-100%. Not having room for mistakes is in itself a very big mistake. It will almost always happen and if it does not happen for this particular task we will either be able to resolve things faster than expected, or we have more time for other tasks. Either way that is a positive thing.

The third thing to look at are testing. All code should have unit tests and it is often forgotten in the estimate. You also have non-functional requirements such as loading times and browser support that you must consider. As a developer you are also responsible for testing the code and this should be added as a second estimate. For many estimates this alone will add 20-200% or even more to the estimate. This is especially true for frontend development where you often have 18+ variations just for devices and browsers.

These three very simple things easily multiply the original estimate two to three times.

Now let us consider your efficiency!

A factor that is very often overlooked is efficiency. No person in any team will ever have 100% efficiency in the sprint. I do not mean your focus level during the day, even if that also is a factor, I am talking about those pesky things that break your concentration. Things like meetings, stand-ups, code reviews and all those "I just want to ask a quick question", cost a lot of your time during the day. In my experience most teams will have an efficiency of around 40-60% depending on how often they are disturbed.

Depending on if your product owner understand estimation or not you can choose if you add the efficiency in the estimate, or if you have that as an external factor in the sprint itself. If you are new to this part of the estimation I suggest that you start with 50% efficiency and then adjust over time as you get better at estimating your efficiency.

With this step we now add a second two time multiplier and you are now close to a realistic estimate.

This may seem like a lot

This may sound like the estimates always will be very high compared to how you are working today, and you are right. This is why you always feel stressed and why you fail to deliver on promise in every sprint. It is why we invent things like story points to mitigate our inability to take responsibility for things we can't estimate properly. Realistic estimates are just that and if your estimates are far lower than what you get doing estimates this way, then remember this very simple rule:

It is always better to overestimate and over deliver than to underestimate and under deliver.

 

The Quick Summary

1. Make estimations in actual time to complete, not arbitrary measurements.
2. Take your time to understand the task at hand and stop guesstimating.
3. Adjust the estimate to fit the slowest person on your team.
4. Add task for testing and make estimation separate for that.
5. Remember that things always go wrong, so make room for that.
6. Make sure that your efficiency is considered and calculated into the time to deliver.

Making good estimates is based on experience and knowledge. This means that like other skills you can get better at it. If you constantly work with arbitrary measurements like story points and you constantly fail with no change to your estimation process, then you should stop doing that. Not only will you fail at a crucial part of your work, your inability to provide accurate estimates actually cause harm in the form of stress and frustration. It is up to you if you want to spend your time in constant failure or constantly provide estimates that are realistic and dependable.

Learning to make good estimates is not rocket science, just common sense and experience.

So start doing it today.

View full blog article

[Jimi Wikman]

I received the following comment on LinkedIn from Paolo:

Quote

Good article Jimi! What I would recommend is also to consider what is outside of your organisation, that generally you can't control: the customer and any 3rd party (e.g. a payment provider). Will they follow your way of working? Will they proceed at the same speed as you or slow you down? In my experience the complexity increases proportionally with the number of third parties involved.

You only estimate what you control. This is why you estimate time to complete and not time to deliver. External factors can block your progress, but that is waiting time that is not part of your time to completion.

This is where dependencies and risk comes in and that is something you will need to balance in the Sprint Planning and the Sprint Startup to ensure the dependencies and risk are acceptable.

For this purpose you should always have a blocked status in your workflow so you can measure waiting periods outside your control and it is also why you should use dependencies so you can mitigate delays that could affect you.

God point Paolo, I should write about this in another article I think