Jory MacKay on May 18, 2021 Long-Term Agile Planning: 7 Steps to Create an Agile Product Roadmap That Works (With Free Checklist!)
🎁 Bonus Material: Free long-term Agile planning checklist!
Agile product development has a chicken and egg problem. Building a product based on user feedback requires, well, feedback. But you need a product to get feedback in the first place. While many teams start by building an MVP (minimum viable product) to get feedback, there’s another option.
Agile planning is a process for reconciling your long-term product vision with the inevitable near-term iterations that will influence its development. Think of it as setting guardrails on your project–they’re not going to send you down a specific path, but they’ll stop you from falling off a cliff if you get off course.
Jump to a section
With the right Agile planning process in place, you can use your team’s wisdom and insight to think big without losing the iterative and feedback-driven qualities that make Agile so magical.
This post isn’t about sprint planning or task management (we’ve written about both those here and here). Instead, we’re going to show you some specific Agile planning strategies you can use to bring your long- and short-term planning together.
By the end of this post, you should be able to connect every daily task in your sprint to your company’s long-term vision (and your users’ needs!)
What is long-term Agile Planning (and why is it so hard to get right?)
Planning is an essential part of every project manager’s job. The “product roadmap” you and your team develop is what guides your day-to-day tasks, helps you plan sprints, and keeps your product vision front and center. However, not all roadmaps are the same.
The detail and depth of your product roadmap will be vastly different depending on the software development process your team follows.
If you follow a traditional (aka waterfall) product development path, you’ll set out with a clearly defined end goal and a process to take you from idea to deployment. This means before you build anything, you’ll already have a detailed plan where each step flows nicely into the next one. At least in theory.
As most teams now realize, you can only plan so much in advance.
Waiting until you’re “finished” to show your product to users can end in disaster (just look at the case of Apple’s Lisa computer).
That’s where Agile excels. In Agile, teams build smaller features and updates in sprints, release them to users, and then use actual user data and feedback to decide what to build next.
Again, this sounds great in theory. But in practice, Agile has its own pitfalls.
One of the biggest issues with Agile is that when you depend on user feedback to drive product decisions, you’re always dealing with the short-term.
Iterative development is great when it works. But getting stuck in short-term thinking can be just as disastrous as waiting too long to get feedback from users. You might be meeting the immediate needs of your customers, but you could be ignoring long-term trends or even sacrificing innovation in the name of following the “safer” path.
Getting stuck in short-term thinking can be just as disastrous as waiting too long for feedback from users.
Plus, as anyone who’s built products for a living agrees with on some level, customers don’t always know what they want!
As Jeff Gothelf, author of Lean UX, asks:
“How then do we build product roadmaps in a world of continuous improvement, learning and agility?”
Agile planning is about more than just quarterly planning meetings. It’s about building processes and best practices that combine the short and long-term needs of your users. It’s about giving users what they want now and showing them an even better path in the future.
Planning a long-term Agile roadmap: Themes, outcomes, and best guesses
Long-term Agile planning sounds like an oxymoron. How can you be both agile and feedback-driven and have a long-term plan?
The success of every project depends on some level of long-term strategic thinking. You have to consider resources, competing demands, and even changes to your market or industry before you run out with guns blazing.
In fact, the need to balance reactive and active thinking is baked right into the original Agile Manifesto. The earliest Agile practitioners recognized that companies are “chaordic”–they have characteristics of both chaos and order.
There is an order to your product backlog, processes, and daily standups. But unleash that organized product into the world and you have no idea what you’ll get in return.
This push-and-pull of control can tear teams apart. But not you.
What we’re going to do here is talk about frameworks that create guardrails of chaos for your team. Instead of getting bogged down in planning out every future detail and avoiding chaos, you’ll have a controlled path with equal parts order and uncertainty.
Fill this out for yourself with our free long-term Agile planning checklist!
1. Start by focusing on outcomes, not outputs
Forget about your current backlog, ongoing sprints, and looming deadlines for a second, and let’s ask a simple question: "What are the high-level goals your company is working towards?"
Long-term planning depends on a long-term vision.
And while Agile teams are self-organizing, they still need a core product vision to organize around.
In an ideal world, your product (and business) vision should be the North Star for every product you build, feature you come up with, and task you complete. Unfortunately, few product visions (and even fewer “business visions”) offer that level of guidance.
Instead, you’re more likely to hear senior management throw out company goals that are either vague and meaningless (i.e. “Change the world!”) or detailed to the point of feeling detached from reality (i.e. “Increase revenue by 15%!”)
For long-term Agile planning to work, we need to translate those goals into something more concrete. That means ignoring the platitudes (sorry world-changers) and focusing on what’s left.
The numbers you hear from stakeholders are called impact metrics–numbers or goals that measure some aspect of your business’ health (revenue, users, market share).
Impact metrics are important to track, but “increase revenue” isn’t exactly a vision you can use to guide sprints, OKRs, or even day-to-day tasks. So let’s flip the script a bit here and think about what those metrics really mean.
In almost every case, business metrics are the result of changes in user behaviors.
The first step in long-term Agile planning is to shift from thinking about outputs (what you’re going to build) to outcomes (the desired behavior change you want to see in your users). An outcome could be adopting a new feature, being more active with your product, upgrading an account, or some other behavior change.
Unfortunately, behavior changes are chaotic. We can’t control what users do when they finally get to use your product. Plus, you don’t always know which behavior change will impact that metric you’re going after.
Does a new feature bring in new users? Or was it changing your marketing page? Or making onboarding easier? Or even releasing an API?
We still don’t know exactly what to do and what features or tasks to prioritize, but that’s OK. We’re just setting up some guardrails.
Measure progress based on outcomes, not output.
2. Map out the user behaviors that will impact your business metrics
For long-term Agile planning to work, you need to know which user behaviors (aka outcomes) are most likely to help you hit your strategic goals and then release builds you think will push people in that direction.
This is where planning often falls apart.
Development teams care about products, features, and user behaviors. While stakeholders often care about revenue, the number of users, and other metrics they can bring to executives or investors. In order to get buy-in on your plan, you need to start talking the same language.
Here’s an exercise that Jeff Gothelf uses to map impact metrics with the behaviors you want to zero in on changing.
- Bring together your product leads and key stakeholders or executives.
- Ask the most senior executive in the room to write down the current number one strategic goal at the top of a whiteboard.
- Next, get the other executives or stakeholders to list out the measures of success for that strategy (i.e. the impact metrics they’re tracking).
- Beneath each metric, ask everyone to start writing down user behaviors that they think will drive that change. Work individually and then add them to the board.
- Now, do another row below that one listing out the user behaviors that can drive those initial outcomes.
At this point, you should have what looks like a messy org chart showing just how many different ways you think you’ll be able to influence the metrics your team is working towards.
Idea/concept by Jeff Gothelf (@jboogie)
This is good for two reasons.
First, it helps stakeholders understand just how many paths are available to try (and how complicated Agile planning can be). And second, it gives you a ton of ideas to work with, all connected to the higher-level goals of your product vision.
We’re going to use this messy chart to start stripping back the layers of a large, company-wide goal and unearth the behavior changes you think will help impact it.
3. Group first-level outcomes into “themes”
The org chart you created is too chaotic to be useful in its current state. So your first step is going to be to look for strategic themes among your first-level outcomes (i.e. the user behaviors that you think will directly impact your measures of success).
Here’s an example. Let’s say you run a SaaS business and one of your impact metrics is to reduce customer churn by 10%.
In the exercise above, you might end up with all sorts of first-level outcomes such as:
- Increased time spent on the dashboard
- Completed onboarding
- Customized profile
- Took a discount at renewal
- Invited teammates
- Took product tour
Look for a common theme that runs through some of these. For example, you could group them under the themes “Increase user engagement” and “Rebuild user onboarding flow” like this:
| Common Theme: Increase user engagement | Common Theme: Rebuild user onboarding flow |
|---|---|
| | |
Both of these themes are still too big to work off of (we’ll get into that next). But they both offer strong, long-term visions that your product team and stakeholders can both get behind.
Long-term Agile planning is not an oxymoron.
4. Set your quarterly OKRs (or, “initiatives”) based on the customer behaviors you think you’ll see
So far, we’ve been building out a long-term Agile planning roadmap with some high-level goals, outcomes, and themes. But now it’s time to translate those into what you and your team will be working on for the next few quarters.
Most product teams (and project managers) know all about the quarterly planning meeting. This is usually the only time you have to think big and plan out features for the next few months. But with the work we’ve already done, you can start to look beyond just the next quarter and work towards a larger vision.
Shifting from high-level plans to actual week-to-week work is tricky, however. But you have a great tool at your disposal: OKRs.
Objectives and Key Results (OKRs) are a planning tool used to connect your daily, weekly, or quarterly tasks to your overall company strategy. As we wrote in our In-Depth Guide to OKRs:
“OKRs translate your company strategy into a digestible way that allows every team member to know they’re working on the right thing.”
This sounds a lot like what we’ve already been doing, but there’s a key difference when using Quarterly OKRs for long-term Agile planning. Instead of using an impact metric or outcome as your key result, you want to focus on user behavior.
For example, you might have a quarterly OKR that looks something like this:
“We will boost user engagement as measured by increased time spent on the dashboard.”
Your objective (boost user engagement) can be brought about by all sorts of user behaviors (measured as key results). But instead of thinking you know which user behavior will work, refer back to the big list you already came up with.
Great OKRs already do this, but it’s too easy for teams to get caught up in pushing the needle rather than influencing user behaviors. When you use behavior-based Quarterly OKRs, you bridge the gap between short-term work and long-term Agile planning.
Planio is a great tool to help organize and track your quarterly OKRs and plan their associated sprints.
Planio is a powerful issue tracker and project management tool that helps you plan and run your projects smoothly. When you’re doing high-level planning like this, you can create categories in Planio for specific issues (aka tasks) so everyone knows what theme your work is attached to.
As you get more specific and move from quarterly OKRs to weekly sprints, Planio will help you connect every task to its desired outcome.
5. Treat “epics” as hypotheses (aka your best guess)
At this point, you should have a long-term Agile roadmap that looks something like this:
Idea/concept by Jeff Gothelf (@jboogie)
Your long-term Agile roadmap includes:
- Company vision (aka, the “impact metrics”)
- Outcomes/user behaviors
- Theme(s) your team is working towards
- Quarterly initiatives and OKRs based on outcomes
Next, it’s time to choose the features you’ll build that will help you hit your goal (see how we’re getting more and more specific?)
You probably have a ton of great feature ideas already in your current product backlog that just need to be groomed to fit your current desired outcomes. But you might also need to work together as a team to map out user stories and prioritize features.
The features and tasks you come up with for each quarterly initiative are called “epics”–larger bodies of work, sprints, or features that can be broken down into smaller tasks (called “stories”). These represent real work, but they’re still just your best guesses at what will help you hit your quarterly OKRs.
This is where chaos and order meet. You can make strong, educated guesses on what to build in the next quarter based on your team’s expertise. But the further out you look, the less certain you can be about what to build.
This is completely natural.
The feedback you get on what you built in Q1 and Q2 will influence Q3 and beyond and give you confidence in your product vision.
Right now, you have a framework for Agile planning that’s grounded in a business case yet flexible enough to adapt and change based on what you learn when your users actually get their hands on it.
6. Review and update your Agile roadmap every few months
At this point, we could keep going down the chain and cover planning sprints, writing and mapping individual user stories, and properly managing tasks, but we won’t. (You can read all about those using the links if you want to learn more!)
Instead, this is where you hand off the uncertainty of long-term Agile planning to the more ordered project management skills you’ve developed over the years. Your long-term Agile roadmap provides a skeleton and guidance, but it’s also a living document that will change and adapt based on feedback.
Think of it as the meeting ground for the top-down initiatives set out by stakeholders and executives and the bottom-up feedback and learnings that your team discovers.
As such, it’s important that this doesn’t just sit and gather dust.
A good rule of thumb is to review your long-term plan at least once a quarter to reaffirm your OKRs and adjust them based on new learnings, market changes, or other issues that are influencing the direction of the company.
7. Measure progress based on outcomes, not output
Lastly, we’re going to go full circle. The long-term Agile planning process started with shifting your thinking from impact metrics to outcomes. And that mindset should flow into how you measure progress.
It’s not enough to do this sort of Agile planning and then fall back into counting features that were shipped on time (although that’s a hugely important part of it).
Instead, long-term Agile planning should be measured based on the outcomes and behavior changes that actually happened.
Look back at your initial list you came up with and ask which guesses worked out? Which ones didn’t? How did users react in a way that was unexpected?
Don’t fight the chaos of building digital products. Let it be a part of your planning process.
Think big and build small with long-term Agile planning
Agile development is one of those concepts that can be simple to explain and incredibly hard to execute. And a lot of that comes down to the fact that human beings hate uncertainty. When you’re putting your time, money, and other resources into creating something you think people will love, you want to feel sure of yourself.
But there are only two things that are certainties in this world: Death and taxes.
The long-term Agile planning process and framework we just outlined should give you the next best option. By focusing on outcomes, using themes and quarterly OKRs, and leaving space to be reactive to feedback, you’ll bring a little bit of order to an otherwise chaotic world.
