Predictable outcomes do not come from rigorous upfront analysis and precise estimates. Planning and estimating in complex domains require progressive planning, or you end up with a plan full of holes - like swiss cheese.

In a previous article I elaborated on the difference between precision and accuracy, and why accuracy always take precedence over precision. Acknowledging this and acting accordingly - to continuously improve precision while not losing sight of accuracy - is what I call progressive planning.

Click to expand

Planning progressively means you have to embrace new ways of thinking about planning and estimating, but don’t let that put you off. The potential benefits are huge.

In this guide you will learn:

• How aiming for too high precision too soon causes swiss cheese estimates.
• How to improve precision over time.
• What to do and what not to do when planning progressively.
• What a progressive plan looks like in different phases of a project.
• How to handle fixed scope-fixed price scenarios.
• Let’s first look at what swiss cheese estimates lead to.

Why Swiss Cheese Estimates Matter

Trying to get too precise data from the organization, no matter how important it seems or who asks for it (“the customers demand it”), inevitably leads to swiss cheese plans. It’s just a question of time (no pun intended) before distrust, missed deadlines and poor quality follows. It takes backbone from the organization, and discipline from stakeholders, to not tumble down that rabbit hole.

What Causes Swiss Cheese Estimates?

Upfront planning is needed. You should definitely plan upfront. Problems begin the minute you think sufficiently thorough upfront planning is enough, that it gives you high precision-high accuracy estimates - and that the reason you didn’t get it right last time surely was you weren’t rigorous enough, or that your teams lack some analysis or estimation skills.

In detailed upfront planning you try to break down and identify all pieces of work. The circles below illustrate identified scope with attached estimates (possibly story points). The team has tried to identify all the “stuff” they need to do.

This kind of detailed drilldown inevitably leads to missed scope (the yellow area below). This is a trait of software development’s inherent complex nature, and you will not analyze or plan your way out of it.

So how do you avoid swiss cheese? You are better off settling for coarse grained high-level estimates early on (big circle to the right). In other words: precision and size of items need to go hand-in-hand with the uncertainty at any given point in time.

Then how do you improve precision and provide better forecasts? Progressive planning to the rescue! (Insert favorite caped super hero.)

Progressive Planning

Progressive planning means consciously refining estimates and improve forecasts during the course of a project.

There are three rules to progressive planning:

1. Don’t lose sight of accuracy
2. Always consider the full scope
3. Use empirical data to refine forecasts

These rules have implications on planning - both what to do and what not to do.

Don’t Lose Sight of Accuracy

Not losing sight of accuracy means you have to relax requirements on precision during initial phases. Also take care to communicate the level of precision.

Do 👍🏼	Don’t 🤚🏼
Use high-level estimates early on.	Give estimates in units that give a false sense of precision (e.g. hours).
Use ranges to communicate uncertainty.	Give single-point estimates.
Use Fist of Five voting to understand confidence.	Give estimates without communicating confidence.
Estimate at the appropriate granularity.	Try to drilldown and estimate everything in detail upfront.

Always Consider the Full Scope

To be able to keep the entire scope in mind, you have to think about granularity of items. Aiming for too much details too early means you deliberately or unwillingly ignore parts of the scope.

Focusing on part of the scope and leaving the rest in a mixed pile of “future work” gives you a big bucket of low precision-low accuracy estimated work. Trying to include the entire scope at a detailed level from the beginning leads to missed scope, and mental breakdown as you try to track too many items simultaneously.

Do 👍🏼	Don’t 🤚🏼
Split items so that each resulting item represents some value or functionality.	Create catch-all items in the backlog (for example “remaining work” or “future work”).
Divide entire scope into areas/themes.	Skip estimating or capturing part of the scope.
Continuously slice items into smaller pieces of real work.	Divide work into “part 1”, “part 2”, etc.

Use Empirical Data to Refine Forecasts

Refining forecasts based on empirical data increases precision over time, so getting empirical data needs to be a priority. This means start working - preferably with the teams that will do the actual implementation - as soon as possible.

If the teams have a track record with similar work, you should be in an advantageous position to make good predictions early. It becomes increasingly more difficult as the type of work and/or team composition changes.

When you change team setup - for example adding or removing people - you change context and invalidate any empirical data you might have. This is one reason stable teams is a topic in software development. It does not mean never change team composition, but do it deliberately and consider impact on forecasting and team effectiveness.

Re-estimating work as you refine forecasts would be tedious and a waste of time. Relative estimates enable forecast updates without re-estimating. You only re-calculate the velocity which is derived based on estimations - not estimated directly.

Compare legs on a road trip. You can estimate the parts relative to each other without knowing at what velocity you will travel - you might not even have decided the vehicle yet - but as you start to travel you can calculate velocity and forecast how long the entire journey will take. The relative size between legs do not change.

Empirical data and relative estimates implies working incrementally and iteratively, and to deliver working software continuously. It is these increments that let you calculate velocity.

Do 👍🏼	Don’t 🤚🏼
Start working as soon as possible.	Spend too much time on upfront planning with diminishing returns.
Communicate changes as forecasts evolve.	Pretend the initial plan still stands.
Keep teams stable, and leverage existing teams if possible.	Re-organize and reform teams haphazardly.
Estimate relatively - derive calendar time.	Estimate directly in calendar time.

An Example

So what does progressive planning look like during different phases of a project?

The Beginning

In the beginning you sacrifice precision for accuracy in. In order to consider full scope you break down work into big areas (perhaps “themes” or “epics”) and estimate these relative to each other.

If you build an issue tracking system areas could be:

• Ticket management
• Dashboards
• Reports
• Import and export data
• Searching and filtering
• Project administration

In the picture below each circle represents an area together with its initial high level estimate (possibly “epic points”).

Click to expand

Identify one or two areas where it makes sense to start. For instance based on risk, feasibility or business priority. The selected areas are broken down into smaller pieces, each representing a piece of actual work.

Ticket management could be divided into:

• View tickets
• Create ticket
• Update ticket

Click to expand

At some point work is refined to the point where it can be worked on by teams. Illustrated below by the darker green circles. View tickets could for example be broken down further:

• List tickets
• Display one ticket
• Print ticket

Click to expand

Midgame

As work progresses things get done, illustrated below by gray circles. As areas are being finished, new areas are broken down into smaller parts and prepared for work to start.

Click to expand

This continues throughout the project’s lifetime. All the done pieces generate empirical data that is used to update velocity and refine forecasts.

Endgame

In the end most scope is likely finished. Because things have been worked on iteratively and incrementally it is easy to make a business decision to finish the project and skip things no longer required. New scope might have been discovered along the way as well. In the picture below the two blue circles represent work that did not get done. Notice that it was never broken down into details or work initiated.

Click to expand

Fixed Scope-Fixed Price

Customers often prefer fixed scope-fixed price contracts. It gives the illusion of safety (“I know exactly what I will get by when”) while in truth they are usually worse for the customer and leads to:

• Poor quality
• High costs
• Mismatch between customer goal and actual delivery

One challenge with fixed scope-fixed price projects is that you are usually asked to give a very precise estimate upfront. Suppliers deal with this in two ways:

• Buffers are added to estimates
• A Change Control Board (CCB) is set up to manage and negotiate changes

Those necessary evils does not prevent you from planning progressively.

It still makes sense to work incrementally and iteratively. Not having everything in progress facilitates business decisions. When the customer asks for changes (albeit through bureaucratic change request processes) it helps not having everything in flux, and knowing what is done - and what work hasn’t been started yet (and can be easily swapped out).

The diminishing return of rigorous upfront planning means you want to keep it lightweight and instead focus on commencing work.

To get a better upfront forecast, use various techniques and combine the data. For example:

• Estimate big areas relatively using for example “epic points”.
• Do spikes and tracer bullets to verify feasibility.
• Look at number of e.g. UI screens or APIs - estimate the cost of one and multiply.
• Leverage any empirical data you have.
• Do a Fist of Five vote with teams to learn how confident they are in the plan.

Also make sure to separate estimation from business decisions. As business owner, maybe you want to take a calculated risk, but don’t bully the organization into creating fairytale plans and lower estimates. It’s ok to ask questions like “What if we remove this?” etc. but don’t question the estimates!

Final Thoughts

Progressive planning and starting work early has upsides versus rigorous upfront analysis:

• You get a head start on implementation.
• You get empirical data faster which enables more reliable forecasts sooner.
• Teams get involved early and gain momentum faster.

Nonetheless it seems surprisingly challenging to do this in practice. Pressure from stakeholders, a fixed mindset on how to plan, and organizational limitations get in the way. No one is helped by unrealistic plans though: not development teams, not business owners, and definitely not customers.

How do you plan? What obstacles do you face preventing you from progressive planning?