Agile: features estimation

Estimating software development is difficult because product development involves uncertainty.

We may not fully understand the problem. The solution may change as we learn. Technical complexity may only become visible once development begins.

Agile estimation does not eliminate this uncertainty. Its purpose is to help teams make useful decisions despite it.

Start by Understanding the Work

Before estimating a piece of work, the team needs a shared understanding of what it is trying to achieve.

One common way of describing a requirement is through a user story:

As a [user], I want [goal], so that [benefit].

For example:

As a returning customer, I want to save my payment details so that I can complete future purchases more quickly.

The value of this structure is that it connects functionality with a user and an intended outcome.

However, not every requirement needs to be expressed as a user story, and writing stories should not become a mechanical exercise.

A technically perfect user story is of little value if the team does not understand the underlying customer need.

User Stories Are Conversations, Not Specifications

A user story should create a conversation rather than replace one.

Before estimating or building, teams should understand:

• Who has the need?
• What are they trying to achieve?
• Why does it matter?
• What does success look like?
• What assumptions are we making?
• What remains uncertain?

This is where delivery connects with product discovery.

Discovery helps teams decide what is worth solving.

Delivery planning helps teams understand what is involved in building and releasing a solution.

What Are Story Points?

Many Agile teams use story points to estimate work.

Story points are a relative measure rather than a direct measure of time.

A five-point story does not mean five days of work.

Instead, teams compare pieces of work based on factors such as:

• Complexity
• Amount of work
• Technical uncertainty
• Dependencies
• Risk

If one piece of work is significantly more complex or uncertain than another, it may receive a higher estimate.

The exact number matters less than the relative comparison.

Estimate Relatively

Humans are often better at comparing things than estimating them in absolute terms.

It may be difficult to predict exactly how many hours a piece of work will take, but it is easier to say:

“This looks roughly twice as complex as something we completed recently.”

Teams can therefore use previously completed work as reference points when estimating new items.

A common scale might be:

1, 2, 3, 5, 8, 13…

The increasing gaps reflect an important reality: as work becomes larger and more complex, precise estimates become increasingly unreliable.

A very large estimate may therefore be a signal that the work needs to be better understood or broken into smaller pieces.

Don’t Convert Story Points Into Days

One of the most common mistakes is converting story points directly into time.

For example:

1 story point = 1 day

Once this happens, story points become disguised time estimates and lose much of their purpose as a relative measure.

Different teams may also assign completely different point values to equivalent work.

Story points are, therefore, most meaningful within the context of the team that uses them.

They should not be used to compare the productivity of different teams or individual developers.

The Cone of Uncertainty

At the beginning of an initiative, uncertainty is usually high.

As teams learn more about the problem, the technology, and the environment, the range of possible outcomes narrows.

This concept is often described through the Cone of Uncertainty.

The important lesson is not that teams should somehow produce more accurate estimates at the beginning.

Early estimates must be treated with appropriate caution.

When uncertainty is high:

• Estimates should be expressed as ranges where appropriate
• Assumptions should be made visible
• Plans should be revisited as new information emerges
• Large commitments should acknowledge the level of uncertainty involved

An estimate is not a promise.

It is a forecast based on the information available at a particular point in time.

Reduce Uncertainty Instead of Debating Estimates

Teams can spend considerable time debating whether something is worth 5 or 8 points.

Sometimes the more valuable question is:

Why are we uncertain?

Perhaps the team does not understand the requirement.

Perhaps there is an unknown technical dependency.

Perhaps an external system has never been integrated before.

Perhaps the proposed solution itself is still changing.

In these situations, more estimation may not improve the forecast.

A small investigation, prototype or technical spike may reduce uncertainty far more effectively.

Break Large Work Into Smaller Pieces

Large pieces of work are inherently difficult to estimate.

Smaller items are easier to understand, build, test and deliver.

Instead of treating an entire feature as one large piece of work, teams can look for ways to deliver value incrementally.

The objective should not simply be to divide technical tasks into smaller tasks.

Where possible, teams should create small vertical slices of value that can be built, tested and potentially released independently.

Smaller work creates faster feedback.

And faster feedback creates better forecasts.

Account for the Work That Actually Happens

Forecasts become unrealistic when they assume that every available day will be spent developing new features.

Teams also spend time on:

• Fixing defects
• Maintaining existing systems
• Supporting production
• Addressing technical debt
• Responding to incidents
• Improving infrastructure
• Collaborating with other teams
• Investigating unexpected problems

Rather than pretending this work does not exist, teams should use historical evidence to understand how much capacity is typically available for planned work.

From Estimation to Forecasting

Modern product and engineering teams are increasingly interested in forecasting rather than perfectly estimating every individual item.

Historical delivery data can provide useful evidence.

For example:

• How many items does the team typically complete?
• How long does work usually take from start to finish?
• How variable is that time?
• How often does unexpected work arrive?

Metrics such as throughput and cycle time can help teams create probabilistic forecasts based on what has actually happened rather than relying entirely on subjective estimates.

This does not mean that estimation has no value.

It means that teams have more than one way to reason about the future.

Estimation and Continuous Discovery

There is another important source of uncertainty that estimation alone cannot solve:

We may be estimating something that should never be built.

Continuous discovery helps teams test assumptions about customer needs and possible solutions before making large delivery investments.

This changes the conversation.

Instead of asking only:

“How long will this feature take to build?”

Teams can first ask:

“What do we need to learn before deciding whether this feature is worth building?”

A prototype or small experiment may answer the most important question without requiring the full feature to be developed.

Reducing product uncertainty can therefore be just as important as reducing technical uncertainty.

The Purpose of Estimation

Estimation should help teams make decisions.

It can support prioritisation, identify uncertainty, expose dependencies and help organisations understand what might realistically be delivered.

But an estimate should never create a false sense of certainty.

The goal is not to predict the future perfectly.

It is about understanding uncertainty well enough to make a sensible decision with the information available today, and then updating that decision as new evidence emerges.

The best teams do not become better at predicting everything. They become better at learning, adapting and forecasting as uncertainty decreases.