“But we’re agile. We don’t plan.”

If you’ve ever worked with an agile team, chances are you’ve heard this excuse. However, even agile teams need a disciplined approach to planning.

Teams who invest time in proper planning tend to have a better understanding of long-term goals for the product, and more realistic strategies for achieving those goals.

How Does Traditional Planning Work?

But to help your team get the most out of agile planning, you first must understand how agile planning compares to more traditional planning with which you might already be familiar.

Traditional planning methods typically follow fixed cycles, with those cycles often occurring very far apart.

For example, a team planning on an annual cycle might define their entire strategy for the upcoming year in a single session in January. During this session, they might not only define their goals for the year, but also a detailed plan for achieving those goals. And they’d likely assign just as much specificity to their plans for December as their plans for January. By the end of the session, everyone agrees the resulting plan will chart their course forward for the next year.

But despite everyone’s best intentions, sooner or later, reality will strike. Unforeseen developments such as customer demands, competitor movements, or developments in the overall market will render pieces of the plan unattainable, or even irrelevant.

However, rather than attempt to reconcile the plan with the new reality, the team presses forward in hopes of catching up to their earlier aspirations. Ultimately this results in a team forever struggling to meet the expectations of an unachievable plan and an organization forever disappointed in their inability to do so. In many cases, this is the reality of traditional planning.

What is Agile Planning?

Let’s compare traditional planning to agile planning. In agile approaches, a team might plan with different levels of detail depending on the timeframe for which they are planning.

For example, they might plan their goals for the year at a high-level, their strategy to achieve those goals over the next few months in a bit more detail, and the steps necessary to implement that strategy over the next few weeks in the most detail. In addition, as they move through the year, the team is likely to progressively elaborate their plans based on what they learn throughout the year.

This approach gives the team clarity on their responsibilities in the short-term while at the same time helping them understand how these responsibilities contribute to long-term objectives.

But how do you strike the right balance between short and long term planning? Many agile product teams use an approach called the Planning Onion.

Agile Planning, Meet the Planning Onion

The Planning Onion helps teams choose the right level of planning for each timeframe for which they are planning. Most often, it’s represented like this.sketch of all the layers in the agile planning onionTo get to know the Planning Onion let’s walk through each layer, starting from the top.

Defining Your Vision

At the top of the Planning Onion, we have the visioning layer. In this layer, the goal is to define the overarching problems your product is solving as well as for whom it is solving those problems. Considering these questions at the outset will help you understand the true value your product brings to users as well as how your product might differentiate itself from other products attempting to solve the same problems.

A great way to do this is collaboratively completing a product vision canvas with the leaders of your organization. There are many great canvases available, but my personal favorite is the Product Vision Board by Roman Pichler, as this canvas can help your team focus on the questions they need to answer to be successful.

Charting Your Course

At the next level, we have the roadmap level. At this level, you and your team will create a high-level plan of how the objectives defined in your product vision might be achieved over the long-term. Often the contents of the roadmap are grouped into releases to better communicate to your broader organization when the features identified in each release might be available.

The specific contents of each team’s roadmap will vary, but generally speaking, your roadmap should define the features your team will deliver to achieve the stated objectives. These features should be described at a high level, rather than as individual stories and tasks. In addition, your roadmap should visually display dependencies between features so your team can determine the most effective approach for tackling those features.

Stacking Your Releases

Moving one level lower is the release planning level of the Planning Onion. At this level, your goal is to elucidate the specific features that will comprise each release defined in your roadmap. If individual stories and tasks are too specific for the roadmap level, then they’ll find themselves right at home in the release plan level. With a well-defined release plan, your team will be better equipped to describe a realistic timeline for the delivery of each release. A thoughtful release plan will help set more realistic expectations across your broader organization.

Looking a Few Weeks Ahead

Near the bottom of the onion is the iteration level. In this level, your team selects the individual stories that will comprise the next iteration and create a plan for how to deliver each story.

If your team is following a Scrum approach, then you might recognize this stage as your Sprint Planning session. However, even agile teams who aren’t following a Scrum approach tend to do some form of iteration-level planning by selecting and planning their upcoming work in small batches.

Planning Your Day

At the bottom of the Planning Onion is the daily level. At this level of planning your team assesses their status at the beginning of the current day and collaborates on a plan for moving forward over the next day.

Many teams accomplish this through a daily standup in which they discuss progress made the previous day, progress they expect to make on the current day, as well as anything that might threaten that progress. While this morning ritual begins with a discussion of what was accomplished the previous day, the most successful teams recognize that the daily standup is a planning meeting, not a status meeting. Therefore, it should focused on creating a plan to move forward, at the daily level.

Finding Your Stride

While the Planning Onion clearly describes multiple levels of planning, its true power comes from its iterative nature. Each layer of the Planning Onion is not intended to be executed once, but multiple times throughout a product’s lifetime. However, the frequency of each layer’s execution will vary depending on where that layer falls in the onion.

Generally speaking, you’ll plan at the lower levels most often but progressively slow your planning as you move towards the higher levels. For example, while your daily planning is likely to occur, well…daily, you may only need to revisit your product vision every few months or even annually.

Picture of how agile planning works with the planning onion

In addition, the participants of your planning sessions change as you move through the layers of the onion. Specifically, the participants in planning at the topmost layer are likely comprise mainly of the executive-level decision makers in your organization.

As you move towards the lower levels of the onion, participants are likely to shift to individual contributors of your team. The nature of this layer of planning favors collaboration with those closest to the work that is to be done as they are often best suited to decide how to do that work.

Making Agile Planning Work With Your Team

If you’re ready to put the Planning Onion to work for you, you must first understand where your organization is in its current approach to agile planning. A great way to find out is to ask how many layers of the Planning Onion your organization has already implemented.

Most agile organizations do some level of daily planning. Many also have some form of iteration planning in place. If your team is missing either of these layers, then close that gap first. This is because without the ability to plan reliably in the short term, your team can never hope to plan for the long term.

In addition, most teams already have a stated vision for their product. But, it’s not uncommon for that vision to no longer reflect the broader goals of the organization or the team’s capabilities to deliver those goals. If you haven’t revisited your product’s vision in the past few months to ensure that it accurately reflects your organization’s goals, then now is an excellent time to do so.

Once you’ve confirmed that your organization has solid daily and iteration level planning routines in place, and that your product vision accurately reflects your organization’s goals, you can address where most teams fall short: roadmapping and release planning.

For many agile teams, the roadmap and release planning levels of the Planning Onion are the most common omissions. If this sounds familiar, start by defining a roadmap based on the desired outcomes in your product vision. Once you have a roadmap in place that accurately represents your desired features, as well as the dependencies between them, then you can use that roadmap as a starting point for developing a more detailed release plan. The combination of these two planning tools will give your team the clarity they need to understand what success looks like for your product as well as the guidance they need to plan how to achieve it best.

A structured approach to planning is essential to a team’s success, even for agile teams. However, you must first understand the different levels of planning at your disposal. You must then discern which level is the right choice at the right time. These skills are what separate those teams who simply deliver a product from those who truly enable the success of their customers.

Post Comments

4 Comments

  • Eric Gage
    December 6, 2018 at 1:21 pm

    This is yet another example of top-down planning in the disguise of being “agile”. There is no mention here of continuous integration / continuous deployment and building a customer feedback loop with analytics to enable quick feature iteration in response to actual customer feedback and usage patterns.

  • Jeremy Jarrell
    December 6, 2018 at 4:34 pm

    Hi Eric,

    Thank you very much for reading the article and especially thank you for taking the time to leave a comment.

    You’re correct that the article doesn’t explicitly mention technical practices like continuous integration or continuous deployment. I also couldn’t agree more that building a customer feedback loop into your process that fosters ongoing product discovery is critical to your product’s ultimate success.

    However, each layer of the Planning Onion is intended to be repeated in a cycle, with the frequency of each cycle increasing as you move towards the bottom of the onion. Within each cycle, teams following this approach will incorporate feedback that’s relevant to that layer in order to ensure the next cycle builds on what was learned in the previous cycles. For example, each visioning cycle will include feedback learned from the product’s fit in the overall market, such as broader market acceptance or how the product compares to competing products that have been released since the previous cycle.

    By the same token, each release planning cycle will take into account information learned from the previous release planning cycle such as how the product’s customer base responded to certain features in the previous release. This information might drive decisions such as whether new features should be expanded upon, alternative features should be investigated, or even whether existing features should be considered for removal in an upcoming release.

    By using multiple layers recurring in different cycles, teams who use the Planning Onion often find that they are better positioned to not only integrate customer feedback into their different planning cycles but to also identify which type of feedback is appropriate to which layer of planning so each piece of feedback can be used in the most effective way.

    Thank you again for taking the time to read the article, Eric. I sincerely appreciate you for taking the time to share your thoughts.

    Best,
    Jeremy

  • Paul Burke
    December 7, 2018 at 3:44 am

    Jeremy. I love this. It addresses a huge conceptual gap for enterprises. I agree though that one more picture showing a series of onions layers placed over time with release moments could better explain the continuous improvement gap. I’ll send you a sketch.

  • Jeremy Jarrell
    December 7, 2018 at 5:45 pm

    Thanks, Paul! I’m glad you liked the article and I appreciate the feedback about the additional illustration. I’ll be looking forward to that sketch 😉

Leave a Comment

Your email address will not be published.