Introduction

An important element to consider when prioritizing tasks is often the effort required to complete something. The customer might consider feature A more important than feature B. But what if A takes N amount of effort, and B, C, and D, together, only require an effort of N/2? That information could affect the order in which things are built.

It is also important to have a hunch about the effort required to complete the different tasks when planning releases with a date. Is it realistic to expect the team to be able to complete tasks A, B, and C within the given time?

Yet a maxim of software development is that it is very, very difficult to accurately estimate development time. Not only is it hard to get right, it can also be very time consuming. There are many uncertainties and variables to take into account, and a lot can happen during development:

• Software development is not just about writing code. It requires research, communication, debugging, testing, and time to think. Cerebral activity, in particular, is almost impossible to predict.
• Code isn’t written in a vacuum. There are often external dependencies that can be very hard to control.
• Requirements change or are not specific enough. Details that might seem insignificant to the one person can have a big impact on the effort required.
• Interruptions and time spent context switching cannot, with any certainty, be forecasted.
• There’s always a bias during estimation. While one developer wants to look good and offers an optimistic prediction, another might subconsciously plan to over-deliver and is overly pessimistic.
• Unanticipated challenges and uncertainties. Most development work requires the developers to do something they’ve never done before. More seasoned developers might have done something similar before, but there are always new elements and surprises.
• Who is going to implement something might not be known at the time. Experience and other attributes differ between developers and affects the time it takes to complete something.

How do we proceed then, if estimates are in fact important? We start by being very honest and specific about how accurate we need the estimates to be.

Rough estimates

During most day-to-day tasks we can often proceed with a rough understanding of the effort required to complete something. We do not need to spend large amounts of time on creating more accurate predictions.

For these types of estimates there exist a couple of different techniques:

• Relative estimation: We assess the size or effort of tasks by comparing them with each other, instead of using exact time units for estimation. The team chooses a familiar task as a reference point, and then gauges the complexity of the new task relative to this baseline. This process involves the whole development team, utilizing their combined experience and insights for more accurate comparisons.
• SWAGs (Scientific Wild Ass Guesses): Rough estimates our teams use when precise data is unavailable. These are informed guesses based on the team’s collective experience and knowledge, providing a ballpark figure for planning and decision-making.

These estimates can be communicated in absolute time (e.g. days or weeks), or as story points or t-shirt sizes. We typically prefer the former as it is a concept very familiar to our clients.

More accurate estimates

There are times when more accurate estimates are required. When the client has to give another department a general timeline, or when two more more features need to be thoroughly compared, for example.

First we make it very clear that an estimate is, in every way, an estimate. It is a very educated guess, not a deadline or a promise.

It is important that the developers who are going to do the work are involved in the estimation process. Previous experience and individual knowledge is going to have a big impact on the predictions, and the best way to take that into account is by letting the developers themselves participate.

We break the problem down into several small actionable tasks. We analyze each task thoroughly, define the exact scope, and try to identify any unspoken requirements. These tasks are then estimated individually. We try to be as realistic as possible and are wary of best-case scenarios.

We deal with uncertainty by doing research, exploring different solutions with simple prototypes (often referred to as spikes) or wire-frames, and by applying a multiplier based on the level of uncertainty. This multiplier commonly ranges from 1.1 when the level of uncertainty is low, to 4.0 when it is high.

We monitor everything closely when the work starts, and the estimates are continuously refined as progress is made.

The estimation activity should be a first class item in the backlog and prioritized like any other item (and preferably estimated – we seldom want to estimate something if the estimation activity is bigger than actually building the feature we’re estimating).