introduc)on*to* user*story*mapping* - meetupfiles.meetup.com/1508927/intro_to_storymapping... ·...
TRANSCRIPT
Introduc)on to User Story Mapping
DFW Scrum -‐ Sabre Jan 19, 2016
Jay Personius
(USM)
Unless specifically cited for por)ons within, this presenta)on is copyrighted under Crea)ve Commons AMribu)on-‐NonCommercial CC BY-‐NC hMps://crea)vecommons.org/licenses/by-‐nc/4.0/legalcode
Ever had this happen to your team?
Image: Copyright Crea)ve Commons AMribu)on CC BY -‐ Courtesy: Luke BarreM, Jeff PaMon hMps://crea)vecommons.org/licenses/by/4.0/legalcode
1/19/16 2
The BoMom Line Up Front (BLUF) Purposed Outcome of User Story Mapping is…
• To achieve a shared understanding between all par)es impacted by a product or process – to achieve a common sense of the “big picture” – in everyone’s mind at the same )me
• So as to assist working in together – for a common outcome and purpose
1/19/16 3
How to Lack Shared Understanding
• Rely on documents alone – Rarely read to begin with – Understood even less so
• Use Strict Requirements – Only tell the “what” -‐ don’t contain “value” – Focus on “output” and not “outcome”
• Pump out “proper” User Stories .. – Without the “big picture” – Without conversa)ons
• Failure to make the “INVESTment”
I-‐ndependent
N-‐ego)able
V-‐aluable
E-‐s)mable
S-‐mall
T-‐estable
“Shared documents aren’t shared understanding” Jeff PaMon
1/19/16 4
User Story Mapping
• Is an engaging visible way to re-‐capture the big-‐picture (shared understanding) of what we are trying to accomplish
• But first, we should begin with revisi)ng the purpose of a story…
1/19/16 5
• “Stories get their name from how they’re to be used and NOT how they’re to be wriMen” (PaMon) – Stories “tell a story” ! – They are not mere tasks – Stories are the discussions we’ve had about solving problems for others in order to agree on what to build
– Stories aren’t the requirements
• Telling stories through collabora)on builds understanding
User Story Mapping
1/19/16 6
Story elements are a “snapshot” that brings back some memory of the idea to be understood
1/19/16 7
Series of personal vaca)on pictures went here J
User Story Mapping Users
• The who • “People” as a user: – A real live customer – The role of a user
• Ex. A tester • “System” as a user: – Something external
• An opera)ng system, framework, library, or “the cloud” • A tool or process that contributes to a User’s ac)vity
• Really: anyone or anything affected by, or affec)ng, desired outcomes
1/19/16 8
User Story Mapping
User
Icon Personna
1
1/19/16 9
Icon
Users
Exercise: Product Idea
• Mobile shopping list applica)on which allows instant updates from someone while the shopper is shopping – I have to handle new texts while shopping anyway
• Shopping lists are sorted by the shopper’s preferred path through the store – I hate going back and forth when a list is so unordered
• Different lists can be maintained for different stores – I hate not having my list with me when I happen to be by a store
• Maintain lists for repe))ve purchases (ex. groceries) – Because we’re )red of re-‐wri)ng lists we’ve used before
1/19/16 10
Exercise: Iden)fying Users
• Teams – by tables – Discuss (brainstorm) various possible users/roles/systems
• Create a post-‐it for each user and place it on table • Don’t worry about any flow order at this point
If you have other ideas besides iden)fying users, quietly put the idea on a post-‐it & hold for later
Time box: 3 min
Note: the selected means of doing this ac)vity is just for the sake of presenta)on 1/19/16 11
Sharing
• What users did your team come up with?
(If another group comes up with a user your team didn’t catch, silently add it to your table while you listen)
1/19/16 12
User Story Mapping Ac)vi)es
• The “What” that takes place to produce outcomes • Think user steps & process steps – not features • Anything that forwards the user towards desired outcomes
1/19/16 13
User Story Mapping
User Ac)vity/Sub-‐ac)vity
2
1/19/16 14
Ac)vity
Sub-‐Ac)vi)es
User Story Mapping
User Ac)vity/Sub-‐ac)vity
2
1/19/16 15
Ac)vity
Sub-‐Ac)vi)es
Narra)ve Flow (backbone)
Exercise: Lis)ng Ac)vi)es
• Goal – List all ac)vi)es the users will do in some reasonable order
• Use “fast brain” not “slow brain” • Each member – in turn … just a few seconds each
– Share 1 phrase (~5 words or less) that describes one step the user/role would take • Place it where you think it goes and under the applicable user • Move or duplicate a “User” if you need to in order to reflect the order • Add copies of a user as needed when flow comes back to that user • Once it hits the table, the post-‐it belongs to the team, not you
– Next person takes a turn • These are not user stories – they are a user ac)vi)es
Leave here to go home: -‐ Walk out to parking Transport -‐ Drive … -‐ Park -‐ Unload car Evening at home -‐ Dinner -‐ Clean up -‐ Watch movie -‐ Play with kids Get ready for bed -‐ Get kids ready -‐ Tuck in others -‐ Get dressed for bed -‐ Shower … -‐ Hygiene … SeMle in -‐ Set alarm -‐ Climb into bed Lights out
Get to work: Get out of bed -‐ Turn off alarm -‐ Roll out Get ready -‐ Shower … -‐ Hygiene … -‐ Breakfast -‐ Wake others -‐ Get kids ready -‐ Get dressed Transport -‐ Load car -‐ Drive … -‐ Park -‐ Walk in -‐ arrive
Time box: 5 min
Note: the selected means of doing this ac)vity is just for the sake of presenta)on 1/19/16 16
Sharing
• Any challenges you encountered? – How did you resolve them?
1/19/16 17
User Story Mapping Stories/Tasks
• Implementa)on stuff – ToDos… • The “Feature” or “tasks” needed for the ac)vity • Open “tasks” as opposed to “real stories” – We’ll cover why this is allowed later…
• Macro task es)ma)ons will likely be used here at this point to prepare for MVP work later
1/19/16 18
User Story Mapping
User Ac)vity/Sub-‐ac)vity Feature/Task
3
1/19/16 19
Tasks
User Story Mapping
User Ac)vity/Sub-‐ac)vity Feature/Task Extra note/info
UI idea
Captured comment
3
1/19/16 20
Exercise: User Tasks
• Part 1 – Independent and quiet – Simultaneously, each person looks at the user and ac)vi)es and places “user task” post-‐its below an ac)vity
– New ac)vi)es can also be added – add task with ac)vity – For now:
• Don’t’ be too thorough, just get a few tasks under each ac)vity • Skip es)ma)ng
– For a real USM event: • “Think it, write it, say it, place it” in front of the team
• Part 2 – Discussion – Take turns discussing your addi)on to your map – Add more tasks as you see need while others are talking and then share when its your turn again
Time box: 3 min
Time box: 5 min
1/19/16 21 Note: the selected means of doing this ac)vity is just for the sake of presenta)on
Sharing
• Any challenges? • Any insights?
1/19/16 22
Addi)onal things to do for placing tasks…
• Iden)fy pain and rewards points – tag it, speak it • Add in more solu)on sketches, pictures, diagrams, experiments to try, architecture thoughts, …
1/19/16 23
User Story Mapping Outcomes
• Not “Outputs” such as: – X features completed – Such and such capability now works – Ex. “We can now do billing from the web site…”
• Think “how has life changed for user?” • Outcomes such as: – The user saves )me using our app over using paper
• Ex. Think: how is the user “happier”, “safer”, “more likely to buy our product”…
1/19/16 24
User Story Mapping
User Ac)vity/Sub-‐ac)vity Feature/Task Extra note/info Outcome
4
1/19/16 25
Desired outcomes
Exercise: List Outcomes
• Team Discussion – List various outcomes of what the tasks will do for the user – Hint: Look back at why the user(s) even cared
• What difference the taks make in their lives? (see Product Idea)
Time box: 5 min
1/19/16 26 Note: the selected means of doing this ac)vity is just for the sake of presenta)on
Sharing
• What outcomes did you decide upon?
1/19/16 27
User Story Mapping Minimum Viable Products (MVPs)
An MVP “Is the product with the highest return on investment versus risk. It is the sweet spot between products without the required features that fail immediately when shipped and the products with too many features that cut return and increase risk.” • It should be “releasable” as in a sense of “complete” – But may not ever be “released” to the customer
• Each progressive MVP should build upon the last with minimum waste – ex. maximum reuse of code
• For USMs, we really use Minimum Viable Outcomes 1/19/16 28
hMps://en.wikipedia.org/wiki/Minimum_viable_product
User Story Mapping
User Ac)vity/Sub-‐ac)vity Feature/Task Extra note/info Outcome
5
1/19/16 29
Priori)zed outcomes
become MVPs
User Story Mapping
User Ac)vity/Sub-‐ac)vity Feature/Task Extra note/info Outcome
5
1/19/16 30
Priori)zed outcomes
become MVPs
Exercise: Move Tasks into MVPs
• Team: – 1st: priori)ze (even break down) the MVPs (or MVOs) – Rewrite them if necessary to make them incremental in building upon one another
• Aper priori)zing them, & deciding 1st MVO – Move tasks around to correspond to their respec)ve outcome
– Move to next MVO …
Time box: 5 min
1/19/16 31
Time box: 3 min
Sharing
• What changed, if anything, with your outcomes? • Any challenges? • Any insights?
1/19/16 32
Congratula)ons!
• You have a (somewhat) func)onal User Story Map!
1/19/16 33
Exercise: Someone Tell the Story!
• Pick one member of the team to recite the story! • Story teller – try to be as detailed as possible star)ng from the beginning – Don’t worry about getng it done in the )me box
• Everyone else mentally take note of how well the story teller captured it for as far as they end up getng through it.
1/19/16 34
Time box: 3 min
Sharing
• So how well did your story teller do? • Were you surprised?
• Story teller – how was it for you?
1/19/16 35
Crea)ng “real” User Stories
User Ac)vity/Sub-‐ac)vity Feature/Task Extra note/info Outcome
Currently “in-‐work” (Tasks can be moved to a sprint backlog)
Note: MVP may or may not fall on Sprint boundaries
6
1/19/16 36
Crea)ng “real” User Stories
User Ac)vity/Sub-‐ac)vity Feature/Task Extra note/info Outcome
I as a <>
Want a <>
So I can <>
I as a <user> Want a <capability> So I can <achieve an outcome>
6
1/19/16 37
Moving from a USM to your Agile Method
• The USM should be a good backlog at this point
• SCRUM – Create your Sprint Backlog from the current outcome lane
• Kanban – Pull tasks from the next outcome lane into Kanban board
• Others …
1/19/16 38
How are USMs like/not like a Sprint Plan
• USMs: – Get us to shared understanding – implementa)on is aper – Are not )ed to any par)cular agile methodology – USM MVOs may or may not fall on sprint boundaries – Only lightly get into es)ma)on – just to accomplish MVOs
• USMs are a great kickoff to any project • Follow-‐up USM events help preserve the shared understanding
1/19/16 39
Varia)ons on the USM Theme
• Use USMs for any flow of thought – Process flows – System admin – To understand anything that has a flow of ac)vity
• Remember: Just 2 simple axes – Ac)vity flow (horizontal) – ordered as the narra)ve – Outcomes (ver)cal) – ordered as incremental MVOs
1/19/16 40
How I’ve used USMs
• Gov Program Office (PO), Contractor “pre-‐RFP” session – Helped the PO decide what that wanted to put out on an RFP – To understand possibili)es first, then narrow down op)ons – Learned dependencies, learned “value” of op)ons
• Gov Program Office, Gov dev team, User session – Helps communicate the expanse of what is being done/needs to be done
– Gov to Gov is typically LOE – so we get to chose outcomes based on ROI much easier
• Impromptu teamwork organizing events – Organize a confusing set of tasks – Create a new work flow between teams (process crea)on)
1/19/16 41
My Favorite On-‐line Story Mapping Tools
• Stories on Board – hMp://storiesonboard.com – Free during beta
• Cardboardit – hMps://cardboardit.com – 1 free user
• Mingle – hMps://www.thoughtworks.com/mingle – 5 free users
1/19/16 42
1/19/16 43
The codex on
User Story Mapping
Creator: Jeff PaMon
[email protected] @jeffpaMon
hMp://www.amazon.com/User-‐Story-‐Mapping-‐Discover-‐Product-‐ebook/dp/B00NF07FHS/ref=sr_1_1?s=digital-‐text&ie=UTF8&qid=1452374741&sr=1-‐1&keywords=story+mapping 1/19/16 44
Jay Personius
• American Systems – Agile Coach, Trainer – Sr. Sopware and Systems Engineer
• CSP, CSPO, CSM • Current agile focus:
– Enterprise transforma)on coaching
1/19/16 45
LinkedIn: dev-‐[email protected]
What I Do
• Agent of change – currently in Defense Dept. – Ill. Typ. results of implemen)ng Agile in isola)on
• Team level: live in a cave – management controlling – no wide benefit • Mgmt level: forced upon teams – causes division
– Working with all levels of an organiza)on • Contracts, PO, PFO, Contractors doing agile • Coaching, mentoring, facilita)on, teaching & evangelizing • 4 year effort so far • Wri)ng “agile friendly” SOWs & IMPs, new means of communica)ng metrics, interpre)ng metrics and progress, …
• Basic “trouble maker”, rebel, challenging the status quo • Open: A agile visionary for those “stuck in the mud & asking for help”
– Working on Scrum Alliance: “CTC” and ICAgile: ICE-‐AC
1/19/16 46
Thank you!