The document discusses the limitations of traditional waterfall roadmaps and emphasizes the need for agile roadmaps that focus on customer needs and business outcomes. It suggests that roadmaps should communicate a vision and be used as alignment tools for stakeholders, while backlogs serve as tactical plans for execution. Additionally, it highlights the importance of integrating product discovery and user story mapping to ensure that development efforts align with strategic goals.

1. Agile (Goal Oriented)
Roadmaps
Slawa Giterman
June 2018

2. Traditional (Waterfall) Roadmaps
• Roadmaps is a strategic (high level) planning tool.
Traditionally for a period of several quarters or a year+
2

3. Backlogs
• Backlog is a tactical (low level) planning tool often
used in conjunction with Scrum / Kanban
3

4. Problems with “Waterfall” Roadmaps
• Waterfall roadmaps represent the initial assumptions =>
Roadmaps quickly become obsolete and are often
abandoned at some point
• Waterfall roadmap ignore new learning (both about the
customers/users and technology)
• Some stakeholders heavily rely on them while others
distrust them => expectations discrepancies
4

5. Roadmaps and Backlogs
• Some projects use both tools:
Vision => Strategy (roadmaps) => Tactic (Backlog)
• Waterfall Strategy <-> ”Agile” development problem:
• => As a result many agile projects use backlogs only
5

6. Problems with Backlogs-Only
• Backlogs often look like an endless shopping list
(representing what?) but the the big picture (why?) is lost:
• the expected outcome for customers and users
• expected business impact for the company
• Many of the features have much less outcome/impact on
the product than initially expected and some are rarely
used at all
• The team concentrates on the velocity and starts to ignore
the real customer needs and pain points as well as the
business goals of the product (“feature factory”)
6

7. Why do we still need Roadmaps?
• To communicate visions/big picture (why?) to the product
team, stakeholders and customers/users
• Act as decision filter / alignment tool for all parties
involved => enables aligned but autonomous product
team(s) and stakeholders (marketing, sales, IT, etc.)
• To be able to achieve outcome (customer’s and user’s
needs and pain points) and impact (the company business
results) and not only output (delivered features)
– see a good introduction by Jeff Patton (vimeo)
7

8. Resources
• Recent books (2016 – 2017)
• Applicable context: middle to large products with middle
to high level of uncertainty
8

9. Roadmap Inputs
• Roadmap should be based on:
• The product / project vision (having the vision is a must)
• And Business Objectives, e.g. OKR (if applicable)
• Or Business Model, e.g. Lean Canvas (if applicable)
• And real world customers and user’s needs and pain
points => “Get out of the building”:
• Customer Development
• Design Thinking
9

10. • Classical Product Vision Format:
For [customer],
Who [target customer’s need or opportunity],
The [product] Is a: [product category]
That: [product benefit / reason to buy]
Unlike: [competitors] Our product: [differentiation]
• Elevator Pitch
• Imagine the future: write the vision as if the product has
already been released although the it has not been started yet
(s. next slide)
• Press Release (e.g. actively used by Amazon teams)
• Customer’s Review (helps to empathize with the user)
Different Vision Formats
10

11. Imagine the Future: Press Release / Customer’s Review
11

12. Business Model (Lean Canvas) / Business Objectives (OKR)
12

13. Get Out Of the Building: Personas
13

14. Agile Roadmap Format (see an Example on the Next Slide)
• Roadmap is not a release plan – it is a sequence of
stakeholder (incl. customers’/users’) priorities
• Roadmap is an actionable plan which moves the product
closer to the vision
• Use timeframes (e.g. Current, Near Term, Future) instead
of particular dates
• Roadmap should be problem based, i.e. include
outcomes (customer’s needs and pain points) or impacts
(business goals) instead of outputs (features)
• Particular solutions (features, use stories) belong to the
Backlog (see further)
14

15. Agile Roadmap Example
15

16. Agile Roadmap Advantages
• When features /user stories are derived from goals:
• It helps to minimize delivering features which do not
relate to the current release goals (e.g. while discussing
the release scope with the stakeholders)
• It helps the team to set its focus on a set of highly
related user stories which minimizes context switching
• It gives the team freedom to choose the optimal
solution (UX, technology, etc.)
• Teams have higher feeling of ownership if they can
select the best solutions themselves instead of building
solutions predefined by stakeholders
16

17. Example of an Acceptance Criteria
• Just delivering the features (i.e. velocity) is not enough:
goals / acceptance criteria should be met
• Real World Example: “Increase amazon.com conversion rate”:
• Acceptance criteria: Increase the customer conversion rate
by 3%
• Amazon experimented with multiple solutions
• Solution which worked much better then any other:
”free” shipping + quick delivery
Amazon’s Prime members conversion rate is 74% (Millward Brown
Digital, 2015). When Prime members shop with other online
retailers, such as Wal-Mart Stores Inc., Target Inc. and Home Depot
Inc., they convert on average 6% of the time, the study suggests.
17

18. Backlog
• Each sprint of the release should have its own clearly
defined goals derived from the release goals.
• Measuring velocity, i.e. how much output (features) were
delivered does not show if the outcome / impact were
achieved, so is basically useless
• The aim should be to reach the sprint’s goals and
acceptance criteria
• Backlog should include detailed user stories for the
current / next sprint only. User stories for later sprints and
releases should remain coarse-grained since before their
implementation starts, the team will learn a lot of
additional information
18

19. Detailed Backlog using User Story Mapping
19

20. User Stories Mapping
• User story mapping is a 2 dimensional backlog format:
X axis represent components / high level user activities and
Y axis represent multiple successive sprints
• User story mapping helps to present a clear big picture in
comparison with 1 dimensional formats (e.g. Jira backlog)
• This is why it gives a holistic view of the product, i.e. it helps
to spot the missing pieces of the puzzle and simplifies
prioritization between user stories
• It can be used as an alternative or as addition to Kanban
boards to represent the backlog (e.g. using tools like
https://realtimeboard.com/, etc.)
20

21. Product Discovery
21
• Product Discovery (i.e. determining “what to delivery?”)
should run in parallel with the Product Delivery during the
whole course of the project
• Use experiments (UX prototypes, technical spikes, etc.) to
determine which features help to reach the release / sprint
goals in the optimal way. Test / validate the prototypes with
the end users is applicable.
• After the release (incl. continuous delivery) actively
measure if the goals were achieved. Use both qualitative
(e.g. end user interviews) and quantitative (e.g. collecting
metrics) analysis