Part III. The Sprint with AI
Planning when effort no longer rules
Roadmap, story map and release plan with AI
A flawless roadmap
To plan the quarter, Héctor tried something new. He gave the AI the context of GymApp, the reviews, the company's goals and the list of ideas, and asked it for a roadmap. In twenty minutes he had one: three themes, twelve features, monthly dates and a rationale for each. It was better written than any roadmap he had ever made.
In the meeting nobody raised any objections, and that was exactly what worried him. Afterwards, in the corridor, Germán told him he had read the rationale for the sports watch integration and had no idea where it came from. Neither did Héctor.
When everything looks like a quick win
Almost every prioritisation method we use (RICE, WSJF, the value and effort matrix) puts effort in the denominator: value divided by effort. With AI, the effort of building collapses, and suddenly everything looks like a quick win. If nothing costs anything, nothing gets discarded, and the roadmap turns into a list of things that can be done.
Effort hasn't disappeared completely. Integrating with legacy systems, reviewing security or touching production data still cost. But effort is no longer what separates what gets done from what doesn't.
Besides, even if building is cheap, it creates a cognitive cost for both teams and users. Teams have more product to understand and maintain, and users get products that are more complex, more complicated and harder to use.
Four questions for prioritising
When effort stops setting the order, you need other questions. Jeff Gothelf proposes ordering the roadmap by two of them: what you learn and how easy it is to undo. I add two more that a company can't leave out:
- What value does it have for the user? What changes in what they do, and for how many.
- What do we learn by building it? Whether it resolves an important question or only confirms what we already believe.
- How much does it cost to undo? A change you can switch off with a toggle is not the same as one that changes the data model or makes a promise to customers. Jeff Bezos explained this in his 2015 letter to shareholders: there are two-way doors, which you can walk through quickly, and one-way doors, which need thought.
- What legal or data risk does it bring? With AI, this question belongs in prioritisation, not at the end.
What teaches a lot and is easy to undo gets built now. What teaches a lot and is hard to undo gets prototyped first. What teaches little and is easy to undo gets done small and without a meeting. What teaches little and is hard to undo stays out.
There is one thing AI doesn't change: the cost of delay (in Spanish), that is, what you lose for every week something valuable takes to reach users. A campaign to attract members is worth a lot in January, when people sign up for the gym, and much less in April, however fast you build it. So, all else being equal, what loses value over time goes first.
Don Reinertsen explains this in The Principles of Product Development Flow (Celeritas, 2009).
An outcome roadmap
A useful roadmap is not a list of features with dates. It is a list of milestones or outcomes (in Spanish): what change in behaviour we are looking for, in whom and in what order. "New members book a class in their first week" is an outcome. "Sports watch integration in March" is a feature, and it only makes sense if it serves an outcome. Product Roadmaps Relaunched (C.
Todd Lombardo et al., O'Reilly, 2017) explains how to build a roadmap like that.
With AI this matters more, because generating features is free. A feature roadmap fills itself.
Story map and release plan
The story map, popularised by Jeff Patton with his book User Story Mapping (O'Reilly, 2014), is still the best way to see a whole product: the user journey at the top and the stories underneath. AI can generate a first map from the evidence in an hour. The team session stops being about writing cards and turns to what matters: deciding where to cut the first release.
A team's release plan is built with forecasts (in Spanish), not with promised dates. With real flow data (how many items the team finishes per week and with what variation) you can say "between week 6 and week 9, with 85% probability". This is the probabilistic forecasting Daniel Vacanti explains in When Will It Be Done? (2020).
AI helps with that calculation; the conversation about what to do if it comes out at week 9 belongs to the team. Planning across several teams has its own chapter, chapter 15.
Questioning the generated roadmap
A roadmap written by an AI is questioned like any other, with two questions:
- What evidence is behind each item? If the answer is "the document says so", there is no evidence.
- What would have to be true for it to work? This is the question A. G. Lafley and Roger Martin propose in Playing to Win (Harvard Business Review Press, 2013) to test a strategy, and it brings to light the assumptions the AI has taken from what is usually done in general, not from your company.
Héctor went through the roadmap with those questions. Of the twelve features, four had evidence. The sports watch one came from an article about trends. The quarter's roadmap ended up with two outcomes and six items, and two of them were experiments.
In short
When effort stops setting the order, prioritise by value, learning, reversibility and risk. Plan outcomes, not features, and use forecasts instead of promised dates. A generated roadmap is questioned like any other.
Try it this week
Take the order for the next Sprint and run it through the four questions. Count how many quick wins fall away. That number tells you how much of your plan was ordered by ease rather than by value.
If you are going to redo the story map, the user story template (in Spanish) includes the guide and the Excel file for the backlog.