IIT Academy: 203 Story Mapping

HI Per Lean Practice
STORY MAPPING 203
IIT Academy
Industrie IT
Story Mapping 203

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

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

STORY MAPPING 203
Recap User Stories
• Define
• Usage

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

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”

STORY MAPPING 203 9"©"Jeff"Pa)on,"all"rights"reserved,"www.AgileProductDesign.com"
User"Stories"are"boundary"objects"
A"boundary"object"is"a"concept"in"sociology"to"describe"
informaDon"used"in"different"ways"by"different"communiDes."
They"are"plasDc,"interpreted"differently"across"communiDes"but"
with"enough"immutable"content"to"maintain"integrity "FF
Wikipedia"
They"are"weakly"structured"in"common"use,"and"become"
strongly"structured"in"individualFsite"use."They"may"be"abstract"
or"concrete."They"have"different"meanings"in"different"social"
worlds"but"their"structure"is"common"enough"to"more"than"one"
world"to"make"them"recognizable"means"of"translaDon."The"
creaDon"and"management"of"boundary"objects"is"key"in"
developing"and"maintaining"coherence"across"intersecDng"social"
worlds. "FF"Leigh"&"Griesemer"
"

STORY MAPPING 203
When do we do story mapping?

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

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

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…

STORY MAPPING 203
Incremental Releases
• Define
• Usage

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

STORY MAPPING 203

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

STORY MAPPING 203
Story Mapping
Spikes

STORY MAPPING 203
Story Mapping
MVP

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

STORY MAPPING 203
Incremental Releases
• Define
• Usage
3. Building iterative software

STORY MAPPING 203
Iterative Software
• Define
• Usage

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

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

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

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

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

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

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

SCHEDULE
SCOPE
QUALITY
BALANCING: SCOPE VS SCHEDULE
Manage Delivery
Add | Remove | Re-prioritise

STORY MAPPING 203
Thank you!

STORY MAPPING 203
Acceptance Criteria

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:

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

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)

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

IIT Academy: 203 Story Mapping

Recommended

Recommended

More Related Content

More from Steven HK Ma ｜馬國豪

More from Steven HK Ma ｜馬國豪 (10)

Recently uploaded

Recently uploaded (20)