iit academy: 203 story mapping

HI Per Lean PracticeSTORY MAPPING 203

IIT AcademyIndustrie IT

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

http://www.stevenhkma.com

http://industrieit.com

http://www.stevenhkma.com

http://industrieit.com


Contents1. 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


Recap User Stories1. Recap User Stories

• Define • Usage




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


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.

ACCEPTANCECRITERIA

FLOWS – SCREEN,DATA, LOGIC, ET AL.

ARCHITECTURE –DATA, INFRA, ET AL.

WIREFRAMES

USER STORY

UX

ARCH

DEV OPS

RELEASE

are “boundary objects”

HI Per Lean PracticeSTORY 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”"FFWikipedia"

“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"

"


When do we do story mapping?


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


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


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

STO

RY #

1ST

ORY

N+1

STO

RY N

+X…


Recap User Stories1. Recap User Stories





Incremental Releases1. Recap User Stories





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


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 MappingSpikes


Story MappingMVP


MVP

Steel Thread

The set of stories required to drive out technical risks is often not the

same as the MVP

Story Mapping


Incremental Releases1. Recap User Stories



3. Building iterative software • Iterative/Incremental construction strategy • Planning for upcoming development


Iterative Software1. Recap User Stories





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


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


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


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


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


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


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 ACOMPLETE

FEATURE BCOMPLETE

A

B

C

D

E

FEATURE CCOMPLETE

PREDICTED RELEASE OF ALL FEATURES

SCHEDULE

SCOPE

QUALITY

BALANCING: SCOPE VS SCHEDULE

Manage DeliveryAdd | Remove | Re-prioritise


Iterative Software1. Recap User Stories





Thank you!


Acceptance Criteria


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:


Documentation

code

Development

Sprint Planning

Smoke Testing

Test Validation

Acceptance Testing

Acceptance Criteria/Test Approach

Product Management

PortfolioManagement

UsageExecutive 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


Development Smoke Testing(against AC)

Test Validation(against AC)

Acceptance Testing(against AC)

PortfolioManagement

UsageExecutive 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 StoriesUser Stories

Acceptance Criteria

code

Sprint Planning(detailed US + some AC)

Acceptance Criteria

ProductManagement

(high level US)


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

Leadership & Management