9 Tips for Better Planning and Estimation in the Enterprise

Consider two bike journeys: your daily commute to work versus a cycling adventure through Patagonia. For your commute, you can estimate arrival time within minutes based on experience. But planning a multi-week expedition through unpredictable terrain, weather, and conditions requires a completely different approach. You need flexibility, contingency plans, and the ability to adapt as conditions change.

Enterprise planning works the same way. Simple or complicated tasks are like the daily commute, predictable and easy to estimate. Complex initiatives are like the Patagonia adventure, requiring adaptive planning strategies that accept uncertainty rather than fight it. In AME3, planning happens at every level: within each Match at the tactical level, and across Tournaments at the strategic level. The tips in this chapter apply to both.

Planning in the Simple and Complicated Space

Simple and complicated tasks are predictable, repeatable, and easily estimated. Once you understand them, they become a no-brainer.

Most enterprises handle simple and complicated work reasonably well. The real challenge lies elsewhere: as markets evolve faster and uncertainty grows, the complex space continuously expands. This is where traditional estimation, prediction, and planning methods break down.

Planning in the Complex Space

The Patagonia adventure represents this complex space. Every day brings new terrain, unexpected weather, and unforeseen challenges. This is where simple, time-based planning fails and adaptive approaches become essential.

The challenges of planning in uncertain environments are not new. The Agile community has developed specific practices for planning and estimating in complex product development: iterative planning, relative estimation, and velocity-based forecasting. These techniques embrace uncertainty rather than pretend it does not exist.

“No plan survives first contact with the enemy.”

But long before the Agile Manifesto, military strategists understood the fundamental problem. Helmuth von Moltke, a Prussian field marshal, captured this reality in 1871 when he stated: “No plan of operations extends with any certainty beyond the first encounter with the main enemy forces.”

In business, your “enemy” might be competitors in the market, emerging technologies like AI, or simply the inherent complexity of product development. The Agile Manifesto addresses this directly: responding to change over following a plan.

This does not mean plans have no value. It means we must prioritize adaptability over rigid adherence to predetermined paths.

The more complex the task, the greater the deviation from the plan and the lower the accuracy of estimates. This is not a failure of planning but a characteristic of complex work.

So how do we estimate and plan effectively in this complex space where most enterprises operate today? Here are nine practical tips that challenge conventional wisdom about estimation and planning.

Tip 1: Estimations Are Overestimated

Humans are optimists. Well, that is why we are human. But this creates a cognitive bias in estimation.

Moreover, the relationship between time spent estimating and estimation accuracy is not linear. It follows a saturation curve. After a certain point, spending more time on estimation does not improve accuracy. In fact, it can decrease accuracy as people influence each other.

In short, when someone asks “how accurate is your estimation?” most people answer with a too optimistic number. The Overconfidence Bias makes us systematically overestimate the accuracy of our own judgments. In reality, it is much worse.

The practical conclusion: invest less time in estimation.

The probability that you are over-investing in estimation and not gaining better accuracy is high. When choosing between detailed estimation techniques or simpler approaches, err on the side of simplicity.

Tip 2: We Seek Security: Planning and Estimating Is Often an Excuse Not to Start

Humans naturally avoid risk. This makes evolutionary sense: why take unnecessary risks? In complex environments where uncertainty is high, this tendency becomes stronger.

Today’s risk in business is typically a difficult conversation with your manager, not physical danger. Yet we still avoid starting.

Several perspectives help overcome this paralysis:

Planning and estimation must be paid for. The time spent on detailed plans and estimates consumes budget. Often, direct implementation would provide more certainty faster.

Only implementation provides absolute certainty. Each implementation validates or invalidates a hypothesis.

Experiments can reduce risk before full commitment. When the cost and risk of direct implementation feel too high, a targeted experiment can provide just enough evidence to decide whether to proceed. The key question is always: is the experiment cheaper than the risk it eliminates?

The following example shows how a SaaS product team might structure an experiment before committing to a full Conversation Oriented feature build.

Note that this experiment still carries cost. If the team is confident enough in user demand, shipping a minimal version directly might provide more certainty faster, at lower total cost than eight weeks of instrumented beta.

Scrum and AME3 are fundamentally empirical control processes. Arena Backlog entries are hypotheses. Advancing in a Match or Sprint generates data and validates them.

Tip 3: Use Different Estimation Methods for Each Level

Do not try to create a single estimation hierarchy from enterprise goals down to individual tasks. This classical project structure plan thinking works in simple environments but fails in complex ones where changes happen too fast.

Instead, use lightweight estimation methods at each organizational level that provide sufficient accuracy with minimal effort:

Enterprise level - Strategic goals and initiatives

• Use relative comparison to past goals, initiatives, or projects
• Consider dimensions like strategic relevance, business benefit, organizational impact, complexity, and CapEx
• Spider diagrams can visualize multi-dimensional comparisons and make relative planning and decision making easier.

Spider diagram comparing a new project against a reference project across five dimensions: Relevance, Benefit, Impact, Complexity, and CAPEX. Pseudo-Fibonacci scale 1–20.

Product/Backlog level - Features and stories

• Relative estimation (Story Points with planning poker or bucket estimation)
• Velocity-based planning
• No estimation (counting items, see Tip 7)

Task level - Daily activities

• Time-based estimates using natural time boxes (days)
• Pull-based planning

Each level has its own reference frame and planning horizon. Do not try to roll up task estimates into story points, and do not try to estimate enterprise initiatives by detailing them in backlog or project plans.

Tip 4: Choose the Right Reference for Estimation

Relative estimation works because humans find it easier to compare things than to measure them absolutely.

Time is actually a poor reference for many situations:

• How long will a colleague take?
• How long will I take tomorrow when I am more experienced?
• It is like the ur-meter in Paris changing its length all the time. For a precise measurement, you need an even more precise reference.

Better references include:

Other work items - Planning Poker and bucket estimation compare stories to each other, not to abstract time measures.

Metaphors - Using animals (elephant, cat, mouse) creates mental images. The brain processes relative sizes more naturally than abstract numbers.

Completed work - What we have already delivered provides the most reliable reference frame.

The key is that your reference stays stable even as your team’s capability evolves. A story estimated as 5 remains larger than a story estimated as 1, regardless of how fast the team delivers either.

Tip 5: Never Use Estimates for Performance Measurements

What you measure is what you get.

If you measure team performance using velocity based on Story Points, teams will increase their Story Points. Not by working faster, but by estimating higher.

Real example: An organization measured Scrum Masters by their teams’ commitment achievement (planned Story Points vs. delivered Story Points). Result? Teams became slower on paper. They planned less per sprint to ensure they always met commitments.

Another anti-pattern: Using velocity as a performance KPI encourages teams to inflate estimates or deliver more features of poor quality that nobody needs.

Estimates should only be used for planning future work, never for performance evaluation, rewards, or punishments.

This is also why time-based estimates are problematic. Humans are paid by time. When you ask for time estimates, you are asking people to estimate something directly tied to their compensation. This creates perverse incentives.

Use estimates for their intended purpose: understanding where you will be in the future. Do not use them to judge whether teams are “good” or “bad.”

Tip 6: Velocity Is the Better Planning Foundation in Complex Environments

Estimation accuracy converges over time. The range of optimistic and pessimistic estimates narrows as the team gains real data from completed Matches.

Relative estimation with abstract numbers (like Story Points) keeps estimates stable longer than time-based estimates. This allows teams to benefit from increasing accuracy, without constantly reworking their estimates.

Here is why: After three sprints, your team gains experience and becomes more accurate. With time-based estimates, you would need to rework your entire plan each sprint:

• Sprint 1: Estimated 100 days
• Sprint 2: Actually need 130 days (update all estimates)
• Sprint 3: Actually need only 60 days (update all estimates again)

With relative estimates and velocity:

• Sprint 1: 50 Story Points to release in Arena Backlog, velocity 10 per sprint = 5 sprints
• Sprint 2: 8 Story Points completed. Still 42 Story Points to release, velocity now 8 per sprint = 5.25 sprints
• Sprint 3: 12 Story Points completed. Still 30 Story Points to release, velocity now 12 on average = 2.5 sprints

The estimates do not change. Only the velocity changes. Your five-point item is still five times larger than your one-point item. This makes planning dramatically more stable.

Tip 7: Scrum Has a Built-In Estimation (But Few Know It)

Many people do not realize Scrum has a built-in estimation technique. It is not Planning Poker.

The built-in estimation is pull-based planning.

Think of the childhood game of guessing how many peas fit in a jar. Sprint planning works the same way. The sprint is your jar. Backlog items are your peas. You estimate by pulling items into the sprint until it is full.

This pull-based approach uses a known, fixed timeframe as the reference. A sprint is typically a month or two weeks. We know from experience what we can accomplish in such timeframes.

The modern term for this is “No Estimates,” but it is actually still estimation, just implicit rather than explicit.

For this to work, you need fixed iterations like Sprints or Matches. Without them, pull-based estimation does not function.

Calculate velocity by counting completed items. If Arena Backlog items are sized to fit within a sprint through refinement, they naturally become similar in size. Count them: 10 cards completed in a sprint means your velocity is 10 cards per sprint.

This is simpler for new teams to learn than complex estimation techniques like Planning Poker, and in practice, accuracy is comparable.

Tip 8: Never Plan Absolute Buffers

One of the most common mistakes in planning is using absolute buffers instead of relative ones. The difference is critical.

A one-sprint buffer in a ten-sprint plan is only 10% contingency. A proper 33% buffer requires proportionally more runway.

Consider a burn-down chart where your team has an average velocity of 10. In 10 sprints it can complete 100 items. If you add a buffer of one sprint to a three-sprint timeline, that is roughly 33%, already optimistic for most projects.

But here is the problem: if you are planning 10 sprints ahead and still use just one sprint as a buffer, you are down to 10% contingency. For 20 sprints, it becomes 5%.

Buffers must scale proportionally with timeline length.

For a 33% buffer, you need:

• 4 sprints of buffer for 10 sprints of work (count only full sprints, so 3.3 becomes 4 sprints)
• 7 sprints of buffer for 20 sprints of work

Remember: that is only 33% contingency, which is actually optimistic for most enterprise projects.

Tip 9: The Value of Planning Lies Not in the Plan Itself, But in the Exchange

“Plans are worthless, but planning is everything.” Dwight D. Eisenhower

The longer version adds context: “In preparing for battle I have always found that plans are useless, but planning is indispensable.”

The planning process generates insights. The plan itself is just a snapshot.

Planning forces engagement with the future and its uncertainties. The conversation among participants surfaces critical misunderstandings and creates shared understanding that no written plan can capture.

If your estimation technique creates good communication containers where teams and leaders discover misalignments and build shared understanding, it is valuable regardless of the accuracy of the estimates produced.

But always ask: could we have this exchange without the estimation technique? If the technique only provides value through communication, perhaps there is a lighter way to achieve the same conversation.

Key Takeaways

1. Invest less time in estimation - Diminishing returns set in quickly
2. Implementation provides certainty - Do not let planning become procrastination
3. Each level needs its own method - Do not roll up task estimates to enterprise plans
4. Choose stable references - Time changes; relative size does not
5. Never measure performance with estimates - What you measure is what you get
6. Velocity beats time estimates - Keeps plans stable as teams learn
7. Pull-based planning is estimation - Scrum has this built in
8. Use relative buffers, not absolute ones - Scale contingency with timeline length
9. Value the process over the plan - Planning creates shared understanding

Planning and estimation in complex environments requires accepting uncertainty, using lightweight techniques, and focusing on learning over precision. The goal is not perfect accuracy but sufficient confidence to make good decisions.