Complexity vs Effort Based Estimation

Agile projects often make the mistake of correlating task estimates to how long they will take to complete, even when using relative complexity estimates. This article aims to challenge this way of thinking and encourage more effective estimation practices.

Why Effort Based Estimations Are Inherently Flawed

Attempting to estimate the time required to finish a specific task is difficult to do accurately as it makes a number of assumptions:

• All scope is known up front, and no new complexity will be discovered
• The amount of time available to work on a task is constant
• Every developer can complete the task in the same time frame

Although we strive to minimize unforeseen complexity, it's important to acknowledge that every codebase and ticket may contain unpredictable elements that could affect the amount of time required to complete the task. On top of that, our schedules vary day to day, and often we have unexpected meetings or other distractions competing for our time. And finally, for a variety of reasons every developer will take a different amount of time to complete a task.

As a result, time/effort-based estimates are inherently unreliable and place undue pressure on developers to complete a task within a specific time frame, rather than focusing on completing the task to the highest quality.

How Complexity Based Estimations Address This Problem

Instead of estimating the duration of a task, you should instead estimate the level of complexity of a task relative to another task. When making these estimates, only the scenarios outlined are taken into consideration, and any known or suspected integration details are avoided. It's important to note that exploring the implementation details of a ticket is still beneficial for building the optimal solution, but it is counterproductive to factor them into the estimate.

By comparing complexity and not effort, variability of the elapsed time from when work starts on an item until it is ready for delivery is built into the estimate. Individual tickets may have a higher or lower cycle time, however over the lifetime of a project the numbers should balance out.

A Note About Story Points

Most teams use numeric points to measure relative complexity, often based on the fibonacci sequence. This has the benefit of being familiar to the team/organisation which simplifies adoption, and allows project managers to track velocity and map its trends, as well as predict and communicate when certain functionality can be completed. However, this opposes the underlying goal of estimating complexity which is to avoid thinking about work in terms of time, and so care must be taken to avoid a mindset of correlating points to time. An effective way to avoid this is to use a measurement that cannot be compared, although this requires an organisation that is willing to fully embrace agile.

How to Estimate Based on Complexity

To begin estimating relative complexity, the first step is to determine how to measure the complexity, and then identify stories that represent each level to be used as the initial point of comparison.

When choosing a measurement unit, it is best to use something which cannot be directly compared. Something arbitrary like the colours of the rainbow cannot be compared and can be an ideal way to measure complexity.

Once you’ve determined how to measure complexity, then you can identify a baseline for what each level of complexity represents. For established projects you can use existing stories, or you can come up with a reference list. For example:

• red - text/font/colour change
• orange - create a new ui element in an existing screen, add an animation, change a data model
• yellow - create a basic screen with simple data integrations
• green -?create a screen with complex ui elements and/or data integrations
• blue - very complex, should be broken up

With the measurement system determined and reference stories compiled, all you need to do to estimate the complexity of a story is to identify which reference story is of similar (or failing that, higher) complexity, and give the current story the same complexity value.

Further Reading

Story Points Revisited - Not strictly related to this topic, but is an interesting analysis on how points are used by the possible inventor of them.