IIT Academy: Agile. Do you know your minimum viable product? Your steel thread? Is your product owner unsure of what to build or what order to build it in? Have trouble articulating technical debt, architectural dependencies and facing large amounts of delivery risk? The new backlog is a 2D map of user stories – learn to master them here. Designed for Product Owners, Entrepreneurs, Delivery Leads, Business Analysts, UX and other designers.
From Goals to Actions: Uncovering the Key Components of Improvement Roadmaps
IIT Academy: 203 Story Mapping
1. HI Per Lean Practice
STORY MAPPING 203
IIT Academy
Industrie IT
Story Mapping 203
2. HI Per Lean Practice
STORY MAPPING 203
Feel free to re-use any of these slides - you are welcome!
Please make sure you attribute them to:
Steven Ma at Industrie IT.
Please include the links at www.stevenhkma.com and industrieit.com
Attributions
3. HI Per Lean Practice
STORY MAPPING 203
Contents
1. Recap User Stories
• Define
• Characteristics of good stories
• Usage
2. Planning valuable incremental releases
• Identifying value
• Identifying valuable releases
3. (Stretch) Building iterative software
• Iterative/Incremental construction strategy
• Planning for upcoming development
4. HI Per Lean Practice
STORY MAPPING 203
Recap User Stories
1. Recap User Stories
• Define
• Usage
2. Planning valuable incremental releases
• Identifying value
• Identifying valuable releases
3. (Stretch) Building iterative software
• Iterative/Incremental construction strategy
• Planning for upcoming development
5. HI Per Lean Practice
STORY MAPPING 203
User Stories: Define
Stories
are
a:
• User’s
need
• Product
descrip3on
• Planning
item
• Token
for
a
conversa3on
• Mechanism
for
deferring
conversa3on
*"Kent Beck coined the
term user stories in Extreme
Programming Explained 1st
Edition, 1999
6. HI Per Lean Practice
STORY MAPPING 203
WORKSHOPS
User Stories: Define
• basic unit of functionality
• gain detail over time
• adds value to the product
• vertical slice through the product
• summarised as:
• “As a <type of user> I want <some goal>
so that <some reason>”
• has acceptance criteria
• can be used to capture non-functional requirements
• can be a spike
• may include wireframes, solution details etc.
ACCEPTANCE
CRITERIA
FLOWS – SCREEN,
DATA, LOGIC, ET AL.
ARCHITECTURE –
DATA, INFRA, ET AL.
WIREFRAMES
USER STORY
UX
ARCH
DEV OPS
RELEASE
are “boundary objects”
8. HI Per Lean Practice
STORY MAPPING 203
When do we do story mapping?
9. HI Per Lean Practice
STORY MAPPING 203
PRODUCT
OWNER
ENVIRONMENTAL
MARKET FORCES
PRODUCT
BACKLOG
DELIVERY
LEAD
SPRINT
BACKLOG
PLANNING
POKER
STORY
BOARDS
BURN-DOWN
CHART
PLANNING
PART 1
PLANNING
PART 2
DAILY
STAND-UP
RETROSPECTIVE
DEFINITION OF
DONE
SHOWCASE
THE SPRINT
GROOMING
PRE-DELIVERY
STAKEHOLDERS
SCRUM
TEAM
10. HI Per Lean Practice
STORY MAPPING 203
WHY WHAT DELIVERY
• Customer needs
understood
• Strategic alignment
• Initial scope defined
• Architecture assessment
• Risk and security
assessment
• Business value
assessment
• Indicative size estimate
• Identify stakeholders
• Feature scope defined
• Feature backlog
prioritised and MVP
• Feature t-shirt sized
• High-level solution design
• High level user interface/
design
• Release plan (Feature
level)
• High-level people
assignments and
resourcing
• Business Case
• Solution architecture
• Ready-for-work features
• Delivery plan
11. HI Per Lean Practice
STORY MAPPING 203
User Stories: Usage
Product Backlog
• prioritised list of all possible user stories for the product
• managed/groomed by the Product Owner
• created during insight/inception
• higher priority user stories more detailed than lower priority
• Scrum team determines sizing/estimates of user stories
• user stories can be grouped into features
Story mapping
• Minimum Viable Product a.k.a. the MVP
• Steel Thread can be identified to reduce risk
HIGH DETAIL
• SPECIFIC
• BROKEN DOWN INTO
STORIES
• READY FOR SPRINT
MEDIUM DETAIL
• FEATURE-LEVEL
• ACTIVELY GROOMED
• RELEASE PLANNING
LOW DETAIL
• IDEAS
• FUTURE WORK
• SOME PORTFOLIO/
PIPE LINE
MANAGEMENT
STORY#1STORYN+1STORYN+X…
12. HI Per Lean Practice
STORY MAPPING 203
Recap User Stories
1. Recap User Stories
• Define
• Usage
2. Planning valuable incremental releases
• Identifying value
• Identifying valuable releases
3. (Stretch) Building iterative software
• Iterative/Incremental construction strategy
• Planning for upcoming development
13. HI Per Lean Practice
STORY MAPPING 203
Incremental Releases
1. Recap User Stories
• Define
• Usage
2. Planning valuable incremental releases
• Identifying value
• Identifying valuable releases
3. (Stretch) Building iterative software
• Iterative/Incremental construction strategy
• Planning for upcoming development
14. HI Per Lean Practice
STORY MAPPING 203
Example Product:
Mind Ink
1. Describing the product’s major features
2. Articulating the product’s depth
3. Deciding on value
4. Articulating on increments of valuable product
18. HI Per Lean Practice
STORY MAPPING 203
Spikes < Steel Threads < MVP
Spike: the smallest throwaway implementation that
demonstrates plausible technical success
Steel thread: The set of stories required to drive out
technical risks in integration
MVP: The set of stories required to test a minimal
proposition in the market
19. HI Per Lean Practice
STORY MAPPING 203
Story Mapping
Spikes
20. HI Per Lean Practice
STORY MAPPING 203
Story Mapping
MVP
21. HI Per Lean Practice
STORY MAPPING 203
MVP
Steel Thread
The set of stories required to drive
out technical risks is often not the
same as the MVP
Story Mapping
24. HI Per Lean Practice
STORY MAPPING 203
Incremental Releases
1. Recap User Stories
• Define
• Usage
2. Planning valuable incremental releases
• Identifying value
• Identifying valuable releases
3. Building iterative software
• Iterative/Incremental construction strategy
• Planning for upcoming development
25. HI Per Lean Practice
STORY MAPPING 203
Iterative Software
1. Recap User Stories
• Define
• Usage
2. Planning valuable incremental releases
• Identifying value
• Identifying valuable releases
3. (Stretch) Building iterative software
• Iterative/Incremental construction strategy
• Planning for upcoming development
26. HI Per Lean Practice
STORY MAPPING 203
Sprint “Zero”
What
• Preparing the conditions for sprints
• Team
• Training
• Dev Ops
• CI & CD
• Infrastructure
• Spikes
Why
• Creates efficiency in delivery
• Creates conditions to adhere to
technical excellence
• Affords the continuous removal
of tech debt
27. HI Per Lean Practice
STORY MAPPING 203
Definition of Done
• complete articulation of what it
means for a user story to be done
• determines quality
• owned by the Scrum team
• can change - likely to differ
between Scrum teams
• creates alignment between
scaled/dependent teams
typical elements include:
• meets all acceptance criteria
• aligns to UX, architectural, DevOps
guidelines etc.
• any up/downstream Scrum team
interface contracts met
• design and code have been peer-
reviewed
• all automated tests pass
• documentation complete
28. HI Per Lean Practice
STORY MAPPING 203
PRODUCT
OWNER
ENVIRONMENTAL
MARKET FORCES
PRODUCT
BACKLOG
DELIVERY
LEAD
SPRINT
BACKLOG
PLANNING
POKER
STORY
BOARDS
BURN-DOWN
CHART
PLANNING
PART 1
PLANNING
PART 2
DAILY
STAND-UP
RETROSPECTIVE
DEFINITION OF
DONE
SHOWCASE
THE SPRINT
GROOMING
PRE-DELIVERY
STAKEHOLDERS
SCRUM
TEAM
29. HI Per Lean Practice
STORY MAPPING 203
The Sprint
• relatively short time period (e.g. 1 to 4
weeks) in which a new working version of
the product is created by delivering user
stories
• sprint length remains constant throughout an
initiative
• factors that determine sprint length:
• change horizon
• technical cycle time
30. HI Per Lean Practice
STORY MAPPING 203
Sprint Planning Meeting
• for planning the user stories to be delivered
in a sprint
• planning is a collaborative effort by the
entire Scrum team
• sprint planning meeting is in two parts:
• what will be done
• how it will be done
31. HI Per Lean Practice
STORY MAPPING 203
Sprint Planning Meeting - Part 1
WHAT
• Product Owner presents the Product Backlog to the Scrum team
• starting from the top, the Scrum team selects the user stories it
thinks it can deliver in the next sprint
• these user stories form the sprint backlog, validated by velocity
• user stories committed to should not be easily changed
32. HI Per Lean Practice
STORY MAPPING 203
Sprint Planning Meeting - Part 2
HOW
• Scrum team does any initial solution design work needed
• Scrum team does an initial plan for delivering the sprint backlog
• user stories are estimated in more detail
• if there appears to be too much or too little work then the sprint
backlog can be renegotiated with the Product Owner
• other people can be invited to attend in order to provide domain
or technical advice
33. RELEASE BURN-DOWN
1.0RELEASE 1.1 1.2 1.3
PRODUCT
BACKLOG
1.4
FEATURE A
COMPLETE
FEATURE B
COMPLETE
A
B
C
D
E
FEATURE C
COMPLETE
PREDICTED RELEASE OF ALL FEATURES
35. HI Per Lean Practice
STORY MAPPING 203
Iterative Software
1. Recap User Stories
• Define
• Usage
2. Planning valuable incremental releases
• Identifying value
• Identifying valuable releases
3. (Stretch) Building iterative software
• Iterative/Incremental construction strategy
• Planning for upcoming development
36. HI Per Lean Practice
STORY MAPPING 203
Thank you!
37. HI Per Lean Practice
STORY MAPPING 203
Acceptance Criteria
38. HI Per Lean Practice
STORY MAPPING 203
Why User Stories + Acceptance Criteria?
Documentation debt,
source of defects,
wasted development effort
What was
intended
What was
coded
What was
tested
Wasted
Testing
Effort
Over-documentation,
missed requirements,
source of scope creep
Because the usual documentation processes produce this:
39. HI Per Lean Practice
STORY MAPPING 203
Documentation
code
Development
Sprint Planning
Smoke Testing
Test Validation
Acceptance Testing
Acceptance Criteria/
Test Approach
Product
Management
Portfolio
Management
Usage
Executive Stakeholders + End Users
Product Owners + Product Stakeholders
Developers
Functional Testing
Product Owners
Scrum Team
Business Cases (Backlog Epics)
Backlog + Wiki Structure
Sprint Backlog +
Wiki User Stories
User Story:
Testing Sections
User Story:
Technical Sections
User Story:
Delivery Decision Log
User Story > JIRA link:
Known Bugs/Issues
Update Sprint User Stories >
System Documentation
System Documentation: User Guides
Requests for changes, new scope, etc.
Documentation
TRADITIONAL DOCUMENTATION LIFECYCLE
code
40. HI Per Lean Practice
STORY MAPPING 203
Development
Smoke Testing
(against AC)
Test Validation
(against AC)
Acceptance Testing
(against AC)
Portfolio
Management
Usage
Executive Stakeholders + End Users
Product Owners + Product Stakeholders
Developers
Functional Testing
(against AC)
Product Owners
Scrum Team
Business Cases (Backlog Epics)
Backlog + Wiki Structure
Sprint Backlog +
Wiki User Stories
User Story:
Testing Sections
User Story:
Technical Sections
User Story:
Delivery Decision Log
User Story > JIRA link:
Known Bugs/Issues
Update Sprint User Stories >
System Documentation
System Documentation: User Guides
Requests for changes, new scope, etc.
code
IDEAL DOCUMENTATION LIFECYCLE
User Stories
User Stories
Acceptance Criteria
code
Sprint Planning
(detailed US + some AC)
Acceptance Criteria
Product
Management
(high level US)
41. HI Per Lean Practice
STORY MAPPING 203
Intention = Code = Test
Microsoft
“Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.”
Google
“Pre-established standards or requirements a product or project must meet.”
Federate the
source of truth
Federate the
source of truth
ACCEPTANCE CRITERIA