How far should a team plan ahead in an agile setting? We can take some guidance from the Agile Manifesto itself, in that it values:

Responding to change over following a plan (That is, while there is value in the items on the right, we value the items on the left more.)

Additionally, there's also the principle where we:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

No-brainer then, right? Don't do it. Yet, I've worked on (and with) many teams which have a strong desire to fully spec out many sprints ahead. Before we jump into why this is misconceived, here's a point-of-view experience of a water slide from a (recently closed; 🕯️) water park near where I live.

This slide is called the Calamity Canyon. It's a series of cascading flumes and pools, targeted as a gentle family experience. As a ten-year-old it was great fun playing WWF Royal Rumble in these pools, avoiding the genuine safety concerns scorn of the lifeguards. I'll let you figure out the rules.

Do your sprints feel like that? A series of cascading waterfalls? Mine sure have in the past.

Roadmaps and Product Goals

It's common wisdom that teams should have "a sprint or two" ahead planned out according to a definition of ready. Any further than that, the team has done too much planning.

The team's refinement efforts should be focused on the items at the top of the backlog, so the work is understood to a point where it can be taken into Sprint Planning. This can involve some form of effort/complexity estimation, breaking the items into smaller, deliverable chunks, and having conversations with interested parties. Actually fitting this work into sprints in advance is wasteful. Firstly, teams judging sprint capacity through story point velocity won't know this upfront. It will be subject to change. Secondly, doing this ahead of Sprint Planning deprives the Developers from utilising this timebox effectively, to establish how they will deliver the work. There's also the notion that if, priorities do change (and they do), all this effort was for naught.

Recently, the 2020 Scrum Guide introduced the concept of the Product Goal, which sits above a Sprint Goal as a guiding, top-level objective the team works towards. This focuses sprint goals as concrete steps to achieving the product goal, giving a nod to strategic product decisions made by the Product Owner, in conversation with stakeholders and customers.

That's a long-winded way to say that it is perfectly possible for teams working with agility to have roadmaps. The key is for those roadmaps to express a direction of travel through high-level objectives. If they become too specific - of the form "X will be delivered on Y" for example - then the roadmap becomes a Gantt Chart in disguise. A desire to plan several sprints ahead comes from attempting to present or express a concrete roadmap in a more "agile-friendly" format. But I'm calling a spade a spade here. Crucially, an agile roadmap is one that recognises the changing, complex environment and embraces the uncertainty. A Product Owner will have a concrete understanding of the goal for the next sprint, ambitions for future sprints, but be willing to adapt if necessary.

Planning - Incrementally, Iteratively - Why Not Both?

Agile development is not against planning as a concept. Seriously, it's not. Agile teams plan all the time. The key distinction is that our planning is "just in time" rather than ahead of time. Planning this way maximises the effectiveness of plans, minimising the chances of obsoletion through the passage of time. When a plan is formulated and later must change, that's wasted effort.

Planning on a just in time basis conforms to decision-making at the point of most information. As outlined by Mary and Tom Poppendieck in Lean Software Development: An Agile Toolkit, this is the last responsible moment:

[...] delay commitment until the last responsible moment, that is, the moment at which failing to make a decision eliminates an important alternative. If commitments are delayed beyond the last responsible moment, then decisions are made by default, which is generally not a good approach to making decisions.

So, Scrum teams have several planning ceremonies. Sprint Planning is planning how to deliver a working Increment of product that achieves a Sprint Goal. The Sprint Review is planning the next move, based on the produced Increment. The Retrospective plans changes to the process, based on experience rather than an presumptive application of theory. The Daily Standup is a daily planning event, where the Developers plan their day around meeting the Goal.

But there's the elephant in the room. It's those mini-waterfalls that I enjoyed at visits to the water park. It's that it's really easy to take a roadmap and deliver it incrementally through the Scrum framework. To do so "isn't Scrum", but common enough to warrant discussion.

Incremental-only product development is when there's a fixed idea for a product, which is built in stages. Sprints correspond to milestones. The expectation is clear, the scope is pretty much fixed. Value is realised and risk is reduced early through incremental delivery. Priorities will probably not massively shift based on user feedback. Not a huge amount of learning is generated. In this instance, the idea of planning "six sprints ahead" is appealing, because the product is known and the stakeholders are effectively projecting a delivery date. More correcly, they're attempting to.

It's also possible to do iterative-only development. This is an extreme form of discovery called rapid prototyping. It's where an idea is formulated and rapidly tested. The prototype is thrown away when unsuitable. It may not produce value itself, but discover where value can be realised. In startups, this process establishes the basis of an MVP and is incredibly useful when a team has identified a need but doesn't yet have an answer for meeting that need.

Options, Not Requirements

More desirable is to combine the gradual, incremental-based approach to delivery with the discovery-based approach of iteration. Have a roadmap, but understand that these are, at best, guesses for what should be built. The prioritised Product Backlog is a series of options that the Product Owner suspects will deliver value. These are like the financial instrument that gives the holder the right, but not the obligation, to be exercised. Product Owners prioritize to "maximise the value" of the Scrum Team. As such, the Product Backlog gives the team an order of options to exercise next, based on their theorized value.

An Increment of product, produced at the end of a Sprint, is a stepping stone to achieving a Product Goal. It makes a material impact on your roadmap. But it's also an opportunity to iterate on the product's direction by re-examining the options available and establishing whether a pivot is required. This requires delivering working increments to users, gaining value and generating learning.

Planning too far ahead of time exercises these options in advance. It incurs cost (in time and effort) to explore the problem space - doing refinement, estimation, etc - without returning value. Further cost is incurred in the event of having to re-work the plan. Keeping options available until the point of most information is a waste-reducing, cost-reducing, risk-reducing exercise. Working with agility is to be able to pivot on a dime, for the cost of a dime.