How to become better at software estimations (Part 1)

In the same way that the chicken comes before the egg (come on, you know I’m right), an estimation comes before every software development project. In fact, much depends on the estimation and in many cases it’s a deciding factor whether there’s going to be a project at all. I hope you understand where I’m going with this — estimations are immensely important.

At Code Runners, we recently had a small internal workshop for our younger developers dedicated to the practice of making estimations. We realise that a great portion of a project’s success relies on starting work at the right note, managing expectations both in the team and in our clients. Here’s what we discussed.

Why are estimations needed?

The most obvious reason is to provide an order of magnitude for size, cost and date about the project. No client will provide you with a broad description of what they want with a time line of “whenever” and budget of “doesn’t matter“.

You need to be able to have concrete numbers that you can measure. This can actually be applied to anything. You need data that you can quantify and based on which you can make conscious decisions. Having a fair estimation will allow you to decide what is a reasonable investment. The more detailed the estimation, the more it enables you to make trade offs of separate functionalities in favour of budget and/or time.

Internally, an accurate estimation gives you information about the team’s velocity and what amount of work can be completed within one iteration. It fits in the agile context, allowing you to break down development into smaller intervals by knowing how much can be completed and released.

Why is it difficult to estimate?

By definition, an “estimation” is a rough calculation of the value or amount of something based on personal judgement. Everything about the term conveys inaccuracy and “give or take” hand gestures. It’s no surprise that it’s so hard to do. Considering that client requirements are often unclear, as a result of no in-depth business analysis, estimating a project proposal feels like a shot in the dark.

Estimating can get increasingly difficult if the technology that needs to be introduced is unfamiliar. A new technology doesn’t mean an entirely new programming language, but even a new framework or a library can cause unimaginable issues, especially if the tech in question is a pre-release version, which still has some hidden bugs and limitations.

Lastly, estimation is a subject to personal opinion and experience, which means separate individuals may give different estimations based on their professional views. This starts to become a problem once programmers make attempts to estimate a task for other team members. There’s even cases where personal pride gets in the way of an accurate estimation — senior devs might not want to admit a feature will take them too long.

Activities that should be included in an estimation.

In order to accurately predict the amount of time it’ll take for your team to finish a task, you need to take into account everything that falls within the process. From our experience the activities can broadly be summarised in 7 categories.

Planning and analysis

This is the pre-development stage, which includes involvement from the business analyst (either from your side or the client’s). It can be structured in so called “grooming sessions” where separate details from the task are being discussed from the whole team and uncertainties are being dealt with. It’s important at this stage to understand why the feature is needed and what needs to be accomplished with it.

Design and development

Pretty straightforward. The phase begins with the discussion of topics like architectural and code design within the developer team. It then moves on the the actual coding.

Testing

Not always necessary, but depends on the client and the specific project. It can consist of Unit testing, Integration testing, Regression testing and / or manual testing on the development environment.

Code review and integration

Again, not always necessary, but generally good to have. You can significantly reduce bugs or other kinds of code imperfections by adding another pair of eyes in the process. At this stage, you need to consider time for the code review itself and for possible changes after the review. Next comes the integration to the main branch and deployment to development.

Documentation

Whenever applicable, useful documentation needs to be properly maintained. Think of it as an investment in time for the future.

Communication

Unavoidable, yet often neglected when considering estimations — meetings take up at least 20% of the time in the development process. It’s also part of the feature development and as such needs to be included in the planning. Different team members (BA, QA, external party, etc.) have different responsibilities and need to pass on their knowledge and work to the next “player”.

Buffers

Finally, always include up to 30% of buffer time in every estimation. It accounts for unclear requirements that may change over time, unfamiliar technologies that developers need to research and potential regressions and complexity.

Check out Part 2, where I’ll share some tips on how to become more effective at software estimations.