Estimating Unknown Work in Agile Plans

Agile plans are more useful when they account for both the work a team can see and the work the team expects to discover later.

Ignoring unknown work makes a plan look more certain than it is. Estimating unknown work helps teams create more realistic milestone forecasts without pretending they know every product backlog item in advance.

Who This Page Is For

This page is for Product Owners, Scrum Masters, agile coaches, leaders, and teams who need to forecast a milestone when some of the work is still unclear.

It is especially useful when a team has enough information to plan, but not enough information to believe the current product backlog contains everything that will eventually be needed.

What This Page Covers

This page explains how to:

• Distinguish known work from likely unknown work
• Think about oversights and emergent requirements
• Estimate unknown work indirectly
• Adjust fixed-date and fixed-scope forecasts
• Keep the forecast transparent as the team learns

Why Unknown Work Belongs in the Forecast

Most teams can estimate the work they can see.

That known work is represented by the product backlog: the product backlog items the team and Product Owner have identified, discussed, and estimated.

But a product backlog rarely contains everything that will be needed. Some work is discovered only after development begins. Some requirements emerge when users see early versions of the product. Some technical work becomes visible only after the team starts building.

If the forecast includes only known work, it will often look better than reality.

That does not mean the team should refuse to plan. It means the team should make room in the plan for work that is likely to emerge.

A useful milestone forecast accounts for both:

• What the team knows: the visible product backlog.
• What the team does not yet know: likely overlooked and emergent work.

The goal is not to know the unknowable. The goal is to avoid pretending the unknown will be zero.

Known Work, Oversights, and Emergent Requirements

Stakeholder needs usually fall into three categories.

Things Stakeholders Know They Need

These are the product backlog items the team can already see.

The team can discuss them, split them, refine them, estimate them, and order them. This is the known-work part of the forecast.

Things Stakeholders Could Have Thought of but Did Not

These are oversights.

The need existed, and someone could have thought of it with more time, more discussion, or a better checklist. But it was missed during the early planning conversation.

This happens often. Stakeholders, Product Owners, and teams do not think of everything at the beginning.

Things No One Could Reasonably Know Yet

These are emergent requirements.

They emerge as the product takes shape. Stakeholders and users often discover them only after seeing or using partial versions of the product.

Emergent requirements are not a failure. They are part of product development. But they still affect the plan.

The Size Equation

A milestone forecast should account for both known and unknown work.

A simple way to think about this is:

Total size = what you know + what you do not know

The “what you know” part is the estimated product backlog.

The “what you do not know” part includes oversights and emergent requirements that are likely to appear during the work.

This does not mean adding a random pad. It means making an explicit estimate of likely unknown work so the forecast does not quietly assume there will be none.

How to Estimate Work You Do Not Know

You cannot directly estimate unknown work item by item.

There are no product backlog items to point to yet. There may not be user stories, acceptance criteria, or even a clear description of the work.

So estimate it indirectly.

Ask the team:

What percentage of the problem and solution do we think we see?

This question asks the team to look at the current product backlog and judge how complete it is likely to be.

For example, the team might say:

We think the current product backlog represents about 80% of what will ultimately be needed.

That means the visible backlog is not the whole plan. It is only 80% of the likely total.

Example: When the Team Sees 80%

Suppose the team has estimated the known product backlog at 100 points.

After discussing the product, the team believes it sees about 80% of the problem and solution.

That means the known backlog represents 80% of the likely total size.

To calculate the total forecast size:

Total size = known work ÷ percentage known

So in this example:

100 ÷ 0.80 = 125 points

The plan should be based on 125 points, not 100.

The extra 25 points are not padding. They represent an estimate of the work likely to be discovered later.

At the beginning, the team does not know exactly what those 25 points will be spent on. But the team is acknowledging that it is very unlikely the current backlog contains everything that will be needed.

Why This Is Not Padding

Padding is usually hidden.

Someone quietly makes an estimate bigger because they are nervous, want protection, or expect pressure later. That kind of padding reduces trust because no one knows what the added amount represents.

Estimating unknown work should be explicit.

The team should be able to say:

We have 100 points of known work. We believe that represents about 80% of what will ultimately be needed. So we are forecasting the total effort as roughly 125 points.

That is different from secretly turning every estimate into a larger estimate.

Keeping known work and unknown work separate makes the forecast more transparent. It also makes it easier to update the plan later. As unknown work becomes known, it can be added to the backlog, estimated, and reflected in the forecast.

Choosing the Percentage Known

The hardest part of this technique is choosing the percentage.

There is no formula that will tell the team exactly how much of the problem and solution it currently sees. This is judgment.

The team should consider questions such as:

• How well do we understand the domain?
• How similar is this to work we have done before?
• How well has the Product Owner thought through the need?
• How much user feedback have we already received?
• How many technical risks are still unresolved?
• How much of the product will only become clear after people use it?
• How far away is the milestone?

An 80% answer means the team thinks the current backlog is relatively mature. That may be reasonable when the domain is familiar, the Product Owner has thought deeply about the need, and the team has built similar things before.

A 50% answer means the team thinks the current backlog is only half of what will eventually be needed. That is a much riskier planning situation.

Be careful about choosing a percentage that is too high. Teams and stakeholders often overestimate how much they know at the start.

When Too Much Is Unknown

Sometimes the team may believe the current product backlog represents less than half of what will ultimately be needed.

That is a warning sign.

If the team sees less than 50% of the problem and solution, the right response may not be to create a detailed milestone plan. The better response may be to learn more first.

Options include:

• Build a small part of the product to uncover hidden requirements.
• Run a discovery workshop.
• Interview users or stakeholders again.
• Create prototypes or experiments.
• Split the initiative into a learning milestone and a delivery milestone.
• Refine the highest-risk product backlog items before forecasting the whole effort.

A forecast can still be created, but it should be treated as highly uncertain.

When too much is unknown, the best plan may be a plan to learn.

How Unknown Work Affects Fixed-Date Plans

In a fixed-date plan, the date is constrained.

The planning question is:

How much can we deliver by this date?

Unknown work reduces how much known backlog work can safely fit before the date.

Suppose a team has eight sprints before a milestone and a velocity range of 25 to 35 points per sprint. That gives a forecast range of 200 to 280 points.

If the Product Owner has identified 240 points of known work, the work appears to fit within the range.

But if the team believes the 240 points represents only 80% of the likely total effort, the full forecasted size is:

240 ÷ 0.80 = 300 points

Now the plan looks very different.

The known work may fit. The total likely work probably does not.

That does not mean the date is impossible. It means the Product Owner and stakeholders need a tradeoff conversation. They may reduce scope, move lower-priority items out of the milestone, accept more risk, or look for ways to learn more before committing.

Related topic: Fixed-Date Agile Planning

How Unknown Work Affects Fixed-Scope Plans

In a fixed-scope plan, the desired scope is constrained.

The planning question is:

When might this set of work be done?

Unknown work increases the likely size of the effort, which increases the likely number of sprints.

Suppose the visible scope is 160 points and the team believes it sees 80% of the total problem and solution.

The adjusted forecast size is:

160 ÷ 0.80 = 200 points

If the team’s velocity range is 25 to 35 points per sprint, the forecast becomes:

• Faster case: 200 ÷ 35 = about 6 sprints
• Slower case: 200 ÷ 25 = 8 sprints

Without accounting for unknown work, the forecast would have been based on only 160 points and would have looked more optimistic.

Adding unknown work makes the forecast more honest.

Related topic: Fixed-Scope Agile Planning

Reduce Unknowns as You Go

Estimating unknown work is not an excuse to leave everything vague.

The team should still reduce uncertainty where it matters most.

Useful ways to reduce unknowns include:

• Refining high-priority product backlog items
• Splitting large items into smaller ones
• Building early slices of functionality
• Running short technical investigations
• Getting user feedback earlier
• Clarifying acceptance criteria
• Reordering the backlog so risky items are learned about sooner

As the team learns, some unknown work becomes known work. The forecast should be updated to reflect that.

Over time, the unknown allowance should become smaller because more of the work has been discovered, refined, or removed from scope.

Keep Known and Unknown Work Separate

It is tempting to hide unknown work inside individual estimates.

For example, instead of estimating a product backlog item at 5 points, a team may quietly call it 8 because it expects surprises later.

That makes the plan harder to understand.

A better approach is to keep known and unknown work separate:

• Estimate known product backlog items as honestly as possible.
• Add an explicit allowance for unknown work.
• Update both as the team learns.

This keeps the forecast transparent.

It also creates better conversations with stakeholders. Instead of arguing about whether individual estimates are padded, the team can discuss how much uncertainty exists in the overall effort.

Common Mistakes When Estimating Unknown Work

Assuming Unknown Work Will Be Zero

This is the most common mistake. For anything beyond a short horizon, some unknown work is likely to appear.

Hiding Unknown Work in Every Estimate

This makes individual estimates less useful and makes the forecast harder to explain.

Choosing a Percentage That Is Too Optimistic

Teams often think they know more than they do. Be careful about claiming the current backlog represents 90% or more of the final need unless there is a strong reason.

Making the Unknown Allowance a Target

The unknown-work allowance is a forecast input, not a budget to spend. If less unknown work emerges, that is good news.

Forgetting to Update the Forecast

Unknown work should not stay unknown forever. As the team learns, update the backlog and the forecast.

Treating the Estimate as Proof

An unknown-work estimate is still an estimate. It should make uncertainty visible, not create false confidence.

Before You Estimate Unknown Work

Before adding unknown work to a forecast, ask:

• What known work has already been identified and estimated?
• How complete does the team believe the current backlog is?
• What similar work has the team done before?
• What parts of the product, domain, or technology are still uncertain?
• What feedback has already been received from users or stakeholders?
• What work is likely to emerge only after development begins?
• Is the team trying to forecast delivery, or should the next step be learning?

If the team cannot answer these questions with any confidence, the forecast may still be useful. But it should be presented as a rough planning aid, not as a reliable milestone forecast.

Common Questions About Estimating Unknown Work

Is Estimating Unknown Work Just Padding?

No. Padding is usually hidden. Estimating unknown work should be explicit. The team should separate known work from likely unknown work so the forecast is more transparent.

How Can We Estimate Something We Do Not Know?

You cannot estimate unknown work directly item by item. Estimate it indirectly by asking what percentage of the problem and solution the team thinks it currently sees.

What If the Team Says It Sees Only 50%?

That means the plan is highly uncertain. The team may need to learn more before making a strong milestone commitment.

What If the Team Says It Sees 90%?

That may be possible, but it should be rare. Be careful. Teams and stakeholders often overestimate how much they know at the start.

Should Unknown Work Be Added as Product Backlog Items?

Not as fake detailed items. But it can be useful to represent unknown work as an explicit allowance in the forecast. As real work is discovered, add real product backlog items and update the forecast.

Does the Unknown Allowance Shrink Over Time?

It should. As the team learns more, unknown work becomes known work, scope is clarified, and the forecast should become more grounded.

Who Should Estimate the Unknown Work?

The team should be involved because developers, testers, analysts, designers, and others often see different risks. The Product Owner should participate because product uncertainty and stakeholder understanding matter too.