Navigate to

What is Agile Planning? A Guide!

  • 13 mins read
  • Updated on January 31, 2024
Agile Planning 1

Overview on Agile Planning

Agile Planning. It sounds like a paradox, doesn’t it? Planning involves setting boundaries, creating checklists, determining delivery dates, and following a step-by-step process doesn’t it?

But Agile, isn’t that all about people doing their own thing? Many people think of traditional planning as the musical equivalent of a disciplined classical orchestra and Agile Planning as the free-form chaos of jazz.

Nothing could be further from the truth.

This article will explain why Agile thinking and planning are not exclusive and can work together powerfully for your business.

Brief Overview

Agile Planning is a way to plan product development in an Agile environment all the way from the business’ goals and objectives down to the day-to-day execution in development teams.

Product development, especially software development, is dynamic. User and customer requirements change. Because of changes in their environment and because using a product as it evolves triggers ideas in a way that no specification document ever could.

Accepting frequent changes then and planning accordingly, is key.

Like Agile Software Development, Agile Planning is iterative, making it inherently adaptable to change. This allows you to focus your attention on user and customer needs at all levels in your business.

It also means that the plan itself isn’t that important. The real value of Agile Planning lies in the thinking needed to create the plan and how it connects work at all levels to the business’ customer oriented goals and objectives.

Planning Is Everything. Plans Are Nothing.

History of Agile Planning

Software development had a bad reputation in the 80s and 90s of the last century. Projects overran their timelines and their budgets.

It turned out that developing any software is a complex endeavor in an often complex and changing environment. Something you simply can’t control with the planning methods borrowed from construction projects.

The waterfall approach just doesn’t cut it when it comes to responding to changes in your customers’ environment and needs.

Agile software development evolved because of that. However, many businesses still used the traditional work breakdown planning method for predicting their costs and establishing budgets.

Agile Software Development does away with work breakdown, at least until the very last moment. Some agile proponents even advocated refusing to come up with estimates for the time and resources. After all, what use is it to plan in this way when you know that things change and any plan is likely to be inaccurate the minute it’s created.

However, the need to control costs and establish budgets didn’t go away even when the benefits of agile in delivering software that works and meets the customers’ needs, were obvious.

Something had to change and Agile Planning was the answer giving managers and executives a way to estimate costs and establish budgets without requiring the development department to go back to attempts to predict the future.

How does it work?

The key idea for Agile Planning is to tie everything that’s done in development back to the business’ strategies and objectives.

This means that planning starts at the top — the director and senior management level — and gets progressively more detailed on the way down to the level of the teams that execute the work.

Nimble Agile is a game-changer in the realm of project management, specifically tailored to enhance Agile planning processes. With its intuitive and user-friendly interface, Nimble Agile empowers teams to streamline project planning by breaking down complex tasks into manageable iterations.

Agile Planing

Agile Planning Onion

A beautiful metaphor for this planning process is the Agile Planning Onion. It’s as a visual reminder of the spectrum Agile Planning has to cover across an entire business.

Agile Onion
As you can see, the onion has six layers. These correspond to the typical hierarchical structure of most businesses.
  • The strategic level looks at where the business wants to be heading in the future, its long-term goals and objectives.
  • The portfolio level is important in businesses that offer multiple product suites. It looks at how these product suites provide customers with a comprehensive solution that helps the business achieve its goals and objectives.
  • The product level develops a roadmap for a single product (suite), detailing where it needs to go to fulfill its part in the portfolio.
  • The release level details what work needs to be done on a product and in what order and comes up with delivery dates based on historic performance and iteration lengths.
  • The iteration level focuses on the work to be done in the next iteration. This is the domain of the teams executing the development of the product.
  • The daily level is where teams meet to discuss the day-to-day planning of their work and progress toward achieving what they planned at the iteration level.

Customers at the Center

In Agile Planning the focus is continually on delivering value to the customer.

The question at all times is: do they value it? Little else matters.

The work a team does is less important than the value of their work represents to customers.

Agile Planning Team 1

To ensure work represents value to customers, you want to deliver it regularly so you can receive immediate and direct customer feedback. This then allows you to adapt as you build and improve the product you’re creating for them.

Yes, this means that everything you planned can change as customer needs change. That’s why Agile Planning, like agile development, is iterative.

And that’s okay because it’s customer value that you’re after, not executing a plan to develop something the customer no longer needs.

Putting the customer at the center of Agile Planning is directly inspired by the first two principles of the Agile Manifesto:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Last Responsible Moment

Agile Planning favors making decisions at the last responsible moment. At least for decisions that are irreversible — that have no way back, or the way back would be expensive.

The thing is that not making a decision has a cost, but making a decision too early — with insufficient knowledge and data — also carries a significant cost.

  • The cost of not making a decision lies in the cost of keeping the inefficiencies or other drawbacks of the current situation. And these costs may well rise over time.
  • The cost of making a decision too early increases the risk of making the wrong decision and incurs opportunity cost: the gains you could have had, had you made a different decision.
Agile Planning Decision 1

You want to hold off refining (detailing) new features until the last responsible moment, because what needs to be done for a feature changes as other features are implemented. In other words: add details (make decisions) too soon and you’ll have wasted the effort when circumstances change and you need to defer that feature, or maybe even scrap it altogether.

So only fully refine (parts of) the features you’ll definitely implement over the next two or three iterations. And only add just enough detail to features that have to wait longer to inform your planning and prioritization decisions.

Frequent Deliveries

You will see from the Agile Manifesto that there is an emphasis on delivering working software frequently.

Likewise, it is a key component of Agile Planning.

Frequent feature deliveries come with several benefits. The more frequent the deliveries of working software, the greater and more detailed the customer feedback. This has a knock-on effect for planning the next iteration and it prevents wandering too far from the client’s desired outcome.

This is one of the contrasts with traditional ‘waterfall’ development and upfront work breakdown planning methods.

Budgets and Delivery Dates

Agile Planning encourages a probabilistic approach to estimate project timelines and delivery dates.
Characteristics of a probabilistic approach are:
  • Avoiding single-date estimates where possible.
  • Using date ‘ranges’ instead.
  • It will reflect the variables in a project
  • It would base predictive calculations using historical data.
  • Both costs and project duration cannot be precisely defined at outset.
Characteristics of a deterministic approach are:
  • Rigid fixed end dates.
  • Each activity has a planned value.
  • The total duration for the project is fixed – it is deterministic.
  • Risks are defined as set in stone.
  • Project costs and duration are set in stone at the outset.
The probabilistic approach in Agile Planning has several benefits for your project:
  • The project baselines for cost, scope and timelines, reflect the variables, changes and uncertainties inherent in every project.
  • Using historical data for calculations (Monte Carlo simulations) will produce more realistic end date ranges.
  • Budgets and delivery dates are more realistic. It is better to be ‘nearly right than totally wrong’.
  • You will be better able to mitigate risks such as; project overrun, the costs and exposure, where individual tasks might contribute to an overrun.

In summary, Agile timelines would be flexible in terms of scope and time (to adapt to changing requirements) but fixed in terms of resources (teams and therefore cost).

And this is exactly what makes it possible to estimate costs and determine budgets without requiring development to come up with estimates!

Productivity Efficiency Increases

In this respect, Agile Planning gives the best of both worlds. But remember:

  • Focus on the work and not the worker.
  • In an Agile approach, who does the work is of secondary importance.
  • The work itself is of primary importance.
  • There is no pressing need to assign roles, plan for teams not individuals.
  • The workflow itself should be smooth and continuous.
  • The business decides the features it wants built and puts them in order of priority for the business.
  • The development team(s) decide(s) how to build them.
  • Together they prioritize the features taking technical constraints and efficiencies into account.

Inbuilt Quality Assurance

Whilst not strictly part of the planning process itself, it’s worth bearing in mind that in the waterfall approach, acceptance testing by users and operators are a separate stage after building and technical testing the product by the developers themselves.

In Agile, the idea is to test early and often. Users and operators review and test every feature as soon as it becomes available instead of waiting until the entire product is ready.

After all, the aim is to deliver working software.

When you deliver a feature in an agile setting, it’s tested and accepted. Not in isolation, but in the context of the product as it’s grown until then.

There’s no need for a separate stage or for a separate team to ensure that everything fits and works together. All that is part of the standard process and already completed.

This makes planning a lot easier and delivery dates more predictable because there won’t be huge nasty surprises at the end forcing you to do a lot of rework. The surprises are always limited to what you have done in an iteration and — with customer collaboration and feedback in every iteration — the risk of creating something the customer didn’t intend is small too.

Continuous Delivery Makes Planning Even Easier

A big hurdle to predictable planning are the lengths developers have to go to keep finished features out of the released product because the business’ calendar dances to a different tune. For example, when a set of new features is to be released during a trade show.

The trouble is that keeping those features ‘in stock’ presents risks because the work on the product doesn’t stop, and incorporating them at a later date means having to redo work, especially a lot of testing.

Global Delivery Management1

The way to avoid all that is to adopt continuous delivery with feature toggles controlling what features are available to whom. This allows you to disconnect the moment of release to customers from the moment a feature is integrated into the released code base.

Use of Data-Driven Decisions

A key component of Agile Planning is its inherent flexibility to adapt to changes in a working environment.

The challenge of delivering projects in the pandemic is a great example of this. During the pandemic, some people became ill and being located in the same building became impossible. This affected everyone involved in developing and delivering new and changed features.

Rather than second-guessing fixed deterministic timelines, Agile uses actual data and metrics to make realistic and informed decisions.

There are several tools for doing this.

One tool often used are Kanban boards and metrics focused on the flow of work through the process and using those to estimate delivery dates for work at hand and in the pipeline.

Kanban For Lean Agile Teams

A more mathematical approach is to use Monte Carlo simulations to predict costs and probable delivery dates. They have long been used in Lean Project Management and are a useful tool to estimate throughput for projects.

The Monte Carlo simulation uses historical data on capacity and performance to calculate the percentage chance of hitting a project target, such as cost or delivery date. This then allows you to assess the risk associated with the work.

Similarities and Differences

The main differences between traditional planning and Agile Planning:

  • Traditional planning is deterministic (or tries to be) — Agile Planning is probabilistic accepting the world changes.
  • Traditional planning is seen as a ‘safe’ option — Agile Planning is seen as a ‘risky’ option. This is incorrect.
  • Traditional planning commits early at the point of least knowledge — Agile Planning commits at the last responsible moment at the point of informed knowledge which also increases exponentially with continuous customer feedback.
  • Traditional planning is rigid, the plan itself is everything — Agile Planning is flexible, the plan itself is relatively unimportant, planning is everything.
  • Traditional planning reports fixed delivery dates, implying predictability and certainty — Agile Planning uses predictive date ranges using historical data, accepting the fluidity of a complex activity in a complex adaptive environment.
  • Traditional planning often calls for separate or specific plans for business strategy-portfolio management to daily planning — Agile Planning encompasses harmonizing planning from strategy to ‘shop floor’.
  • Traditional planning focuses on tasks — Agile Planning focuses on value.

The risk with the waterfall approach of making predictions early, when the least is known about what’s ahead, is that the predictions are wildly inaccurate. The reason is that a change in customer needs means that work that’s already been done in earlier stages needs to be redone too.

The Agile Planning approach is inherently iterative and adaptable. Risk is mitigated with customer feedback throughout the project and with each working feature delivered.

It is worth pointing out that the sheer scale of some projects like those undertaken by NASA will follow a more traditional approach to planning or a hybrid of waterfall and Agile called Spiral planning.

Nasa Spiral Planning

Having looked at the similarities and differences between Agile and waterfall, let’s look into the key roles and responsibilities in Agile Planning.

Key Roles and Responsibilities

Crucial roles in Agile Planning are:
  • Senior management responsible for strategic and portfolio planning.
  • Project managers, product managers, research managers, and product team leaders responsible for product planning.
  • Project managers, delivery managers responsible for release planning and bridging the gap between the above personnel and the technical teams to decide what features they will release.
  • Developers, testers, designers, responsible for iteration planning and daily planning.

These roles and responsibilities reflect the Agile Planning onion discussed earlier.

And again, it’s important to stress that it’s everyone’s role and responsibility to adopt the Agile Mindset and buy into the Agile Planning concept.

Key Meetings, Cycles, and Delivery Cadences

Agile Planning doesn’t really prescribe any meetings or specific cycles and cadences, but there are typical cadences for each layer in the Planning Onion:

  • Teams discuss day-to-day work on a daily basis. Think of the daily stand up in Scrum or the day start in Lean.
  • Iteration plans obviously follow the iteration length. For example the Sprint Planning in Scrum, informed by the outcomes of the Sprint Review and Retrospective on the past Sprint.
  • Release plans usually follow a quarterly cadence. Think of the quarterly Product Increment Planning in SAFe.
  • Product roadmaps and portfolio plans typically have a 12-month timebox.
  • Companies generally have both 12-month and 5-year strategic plans.

Common Pitfalls

For Agile Planning to work, agile thinking, as laid down in the Agile Manifesto, needs to be at the front of everyone’s mind throughout your business, across all its departments, and all your people.

Agility Quote

Without agile thinking, the Agile Mindset, paramount in the planning through all six layers of the Planning Onion, using it to your benefit becomes that much harder.

Common pitfalls business face are:

  • Agile Planning relates to pursuing business objectives and how these trickle down to the ‘shop floor’ to keep everyone aligned. Problems occur when one department is out of sync with another.
  • Frequently, Agile Planning is adopted successfully at the inner three layers of the onion but not at the upper three layers. This kicks everything out of kilter.
  • Not accepting that the plan itself will inevitably change as it is itself, iterative and it will reflect changing customer requirements.
  • A common weakness is planning from a fixed predetermined date. This encourages future forecasting from a position where you have the least knowledge.
  • Forgetting that the goal is to mitigate and reduce risk, not increase it by making decisions or predictions at a time when you have insufficient knowledge to do so.

Getting Started

The best thing you can do to get off to an excellent start in your Agile Planning campaign, is to seek training and advice.

Not just for a few, but for everyone involved with planning at any layer of the Agile Planning Onion. After all, spreading the knowledge helps spread the mindset and gets everyone on the same page.

That said, don’t jump in the deep end with everybody at the same time.

Start with the inner layers of the Agile Planning Onion. These are the people that are probably already well-versed in planning their iterations in Agile ways.

Move outward one layer at a time. If you have multiple product groups, you can consider this for a single product group first and use the experience with that to bring other product groups on board.

Nimble Agile transforms project planning by simplifying tasks and fostering collaboration. With an intuitive interface, it supports the Agile methodology by enabling dynamic task prioritization, real-time progress tracking, and easy timeline adjustments. Nimble Agile ensures adaptability and efficiency, making it a vital tool for streamlined and successful Agile planning. Signup for a free trial here.

Further Reading

About Author:

Picture Of Marjan Venema
Marjan Venema
With 30+ years in all corners of software development, Marjan's specialty is writing engaging copy that takes the terror out of tech: making complicated and complex topics easy to understand and consume.

Signup for updates!

Speed up your Agile planning and execution!

Signup for a FREE Trial of Nimble Agile

Free Trial
Request Demo

Agile 101

Pair Programming

Pair programming is a programming method in which two people work together on a single program. The first person is the “Driver”, who writes the code, the other person is the “Navigator” who reviews each line of code as it is typed, checking for errors. They exchange their roles on a regular basis.

Read More »

Refactoring In Agile

Code refactoring in Agile is a well-known technique to keep a codebase healthy and amenable to change. Learn what it is and a sound process to follow.

Read More »