This was originally a Stride ⚡️Lightning Talk⚡️ hosted by the Learning Initiative and presented by Rob O’Brien.
So, what is the planning onion?
The planning onion is a great way for product managers and teams to structure and frame different levels of planning. These levels each require different cadences of reviewing and updating, and each has different people that it should be serving.
The three main components of a planning onion are the “Who,” the “What,” and the “When / How.” You’ll notice that these layers build on of each other and make the shape of—you guessed it—an onion.
You’ll find that teams will struggle with the layers in the middle and the top, but most teams are good at the bottom-most layer. Most teams have stories and sprints, but if you ask for the thinking above the story or the sprint, often it isn’t there.
The reason for this is that we have to use different tools and techniques to handle different levels of planning. For example, if I said, “What is your roadmap?” you shouldn’t list out five hundred stories. That’s the wrong tool to use for long-term planning.
Often people get confused about how to do these activities. This is a helpful structure to refer when you say, “Whatever we’re doing and whatever level of planning we’re doing should be made up of the item below.” The details in here—vision, roadmap, release, sprint, stories—are not necessarily required for your planning onion. It’s more about the different layers of planning needing to play off of each other. You should be able to go up and down the onion. You should be able to tie your story to a sprint, to a release, to a roadmap, and, finally, to a vision.
You should be pushing your product manager to say, “Great, what’s the goal above this sprint? Is it well defined? Do we have an artifact that has that?” Again, it doesn’t have to be a release or a roadmap. Some people put layers between these, for example adding an MVP layer between release and roadmap—meaning that your MVP is made up of releases but is just one part of your roadmap—but either way, the concept of the planning onion still stands.
Next let’s look at the left side, the “Who” on the planning onion.
These different levels of planning should have different purposes and people whom they are providing information for. You’ll notice that this side is labeled Executive Involvement. The higher up on the onion, the more executives are involved; the lower you go on the onion, the less executives are involved.
You will find that this isn’t always true, and that can be a problem. If your executive, for example a CEO, wants to look at your stories and get involved, that is probably a sign that something is going wrong. It could be a sign that you don’t have the right information to give them, or that they are too deep in the weeds and should be thinking more strategically.
On the flip side, as a product person, you need to come to the table with these artifacts to have the right conversations. If you’re meeting with a VP-level stakeholder, you’ll probably be bringing your release plan and roadmap, but you probably don’t want to talk sprint to sprint or story to story. If you’re having a quick update with the CEO, they are going to want to know the vision and the purpose of your team, not the details below.
You may have noticed that I haven’t mentioned the team's involvement. A lot of the time, people will ask, “Is the team the inverse? Is the team more involved in stories and less involved in vision?”
The answer is no. The reason the team is not on here is that the team needs to be involved at every level and have input at every level. Just because you’re a developer doesn’t mean you shouldn’t be aware of what the vision is. Anyone on the team should have the ability to offer their input for the vision.
When & How
Finally, we’re on to the “When” and the “How.”
Different levels of planning and different tools that you’re using to plan those should be reviewed at different cadences. We’re quite good at this at the lower levels; most people are.
When do we review our stories? Every day, we have a stand up; it’s built in. We have a cadence to review our sprints. If you’re doing a weekly sprint, you have a sprint review and sprint planning at the end of the week. If you’re doing a two-week sprint, every two weeks you review that sprint and the plan the next.
It’s the level above that on the planning onion that most organizations struggle with. Should you do a monthly review of the vision? Should you do a monthly review of your roadmap? It’s up to you, but you need to have a broader cadence to review a broader layer of your planning onion.
If your release is made up of your sprint goals and it's showing the next two to three months, maybe you set a review cadence to once a month. In that review, you’re not reviewing stories. You’re reviewing a list of sprint goals. You’re reviewing one level higher on the planning onion.
Every quarter you may want to review the roadmap. What you’re reviewing is not the sprint goals but rather the goals of the releases. The vision may need to be reviewed every year or so.
Again, the exact number and duration are less important and can vary from organization to organization. What matters is the idea that they need to be building on each other. We shouldn’t be reviewing our vision every day, and we shouldn’t be reviewing our stories only once a year.
There needs to be a different cadence and frequency depending on the layer that you’re working in. That’s where the planning onion can help you keep your organization focused.
If it sounds like the planning onion could help your team, we’d be very interested in having a conversation with you!
Interested in reading more blog posts like this?
Subscribe for engineering and product blogs to be delivered to your inbox every two weeks.