user story mapping - mini iad 2014 (armani, rodriguez)
DESCRIPTION
Riteniamo, che non vi sia dubbio sul fatto le User Story (introdotte da eXtreme Programming) e il Product Backlog (definito in Scrum) rappresentino due portentosi strumenti per la gestione agile dei requisiti e delle specifiche sia funzionali che non funzionali. Ma … hanno alcuni limiti. Ad esempio, nonostante le notevoli caratteristiche del Product Backlog, la sua unidimensionalità non consente di creare un modello dei requisiti adatto a scalare e che consenta di gestire le dipendenze che possono essere presenti tra i vari elementi che lo costituiscono. In questo workshop presenteremo e utilizzeremo un altro potente strumento che spesso utilizziamo durante gli User Story Workshop sia in fase d’Inception, sia all’inizio di ogni nuova release di un prodotto. Si chiama “User Story Mapping”. Ci divertiremo con voi ad utilizzarlo in una simulazione che partendo dalla Vision di un prodotto ci consentirà di mappare i bisogni di un numero selezionato di utenti su un insieme di funzionalità organizzate in una mappa. Inoltre vedremo come sia possibile utilizzare questo strumento per gestire le diverse release di un prodotto a partire dal così detto “Walking Skeleton” fino alle successive MMF (Mininum Markatable Feature) Sapete cos’è il modello di Kano, FURPS+, o come il nome della capitale della Russia possa essere utilizzato per assegnare priorità alle diverse storie? Se vi abbiamo incuriosito, o se pensate che avere un nuovo strumento mentale da aggiungere alla vostra cassetta degli attrezzi potrebbe esservi utile, partecipate. Sarete certamente i benvenuti.TRANSCRIPT
Armani -‐ Rodriguez May 17 2014
Why
• It allows you to see the big picture in your backlog.
• It gives you a be8er tool for making decisions about grooming and priori<zing your backlog.
• It promotes silent brainstorming and a collabora<ve approach to genera<ng your user stories.
Why
• It encourages an itera<ve development approach where your early deliveries validate your architecture and solu<on.
• It is a great visual alterna<ve to tradi<onal project plans.
• It is a useful model for discussing and managing scope.
• Allows you to visualize dimensional planning and real op<ons for your project/product.
Silent Brainstorming
Silent Brainstorming
Silent Brainstorming
• Decide on the type of ques<on • Step 1: generate ideas individually. One idea per post-‐it • Step 2: read and put ideas on the table • Step 3: group the ideas (clustering) • Step 4: Name each group • Step 5: prepare for vo<ng • Step 6: each person votes for their top 3 • Step 7: facilitator tallies the votes • Step 8: act on the item(s) with the highest vote!
Dimensional Planning
Dimensional Planning
• In Scrum the Product Backlog is an ordered list of features. Unfortunately the linearity of the ordered list is not consistent with the way us humans think about problems.
• Problems even in the business space are mul<-‐dimensional. So, we probably also should think of solving our problems in mul<ple dimensions. This is where Dimensional Planning comes in handy when spliXng Product Backlog Items in your Product Backlog during the Refinement or Grooming mee<ngs.
Dimensional Planning
• In Scrum the Product Backlog is an ordered list of features. Unfortunately the linearity of the ordered list is not consistent with the way us humans think about problems.
• Problems even in the business space are mul<-‐dimensional. So, we probably also should think of solving our problems in mul<ple dimensions.
• This is where Dimensional Planning comes in handy when spliXng Product Backlog Items in your Product Backlog during the Refinement or Grooming mee<ngs.
Dimensional Planning
Dimensional Planning
Dimensional Planning
From dirt road to flying cars • Dirt road • Cobblestone road • Asphalted road • Highway • Flying cars
Dimensional Planning
Real Op<ons
• How and when (not) to make decisions • Defer commitments
Problem
Customer Supplier
Implement
Generate op<ons
Test and choose op<ons
Don’t try to decide too fast!
Real Op<ons
• Have a value • Have a cost (= the price of the op<on) • Have a price (“strike price”) when we exercise the op<on
• Have an expira<on date/condi<on ~ “Call Op<on”
An op<on is not an obliga<on
Grooming
Living Charter = Chartering
How to create a User Story Map
Group
Task
Group
Task Task Task
Group
Task Task
Backbone
Walking Skeleton
Some defini<on
• The post-‐its you create in Step 2 are the User Tasks (blue post-‐its in the diagram).
• The groups and group names in steps 3 and 4 are the User Ac3vi3es (orange post-‐its). Jeff calls these top two rows the backbone and walking skeleton of your applica<on.
• The user stories (yellow post-‐its) are organized under each User Task in order of highest to lowest priority for that User Task.
• The chronological order of how users will typically use the applica<on goes lej to right (Time).
How to priori<ze a User Story Map
Story …
Story 1
Story 2
Story 3
Sprint N-‐1
Sprint N
Sprint N+1
Story 3
Story Slicing
Story 1
Story 2
Story 3
Story 4
Story 5
Story 6
Story 7
Story 8
Story 9
Sprint N-‐1
Sprint N
Sprint N+1
Wri<ng story tests
Automa<ng story tests
Implemen<ng the user story
Risk & Assump<ons
• Where are the risky stories? • Where are our biggest assump<ons?
Applying Cynefin
• A way to understand complexity is that ac<ng in the space causes the space to change, and cause and effect can only be understood in retrospect.
Applying Cynefin
"When you start wri<ng tests, or having discussions, and the requirements begin changing underneath you because of what you discover as a result, that’s complex. You can look back at what you end up with and understand that it’s much be8er, but you can’t come up with it to start with, nor can you define what “be8er” will look like and try to reach it. It emerges as you work." "... This is the land of high-‐feedback, risk and innova<on: generally stuff you’ve never done before, anything that the business are unsure about, new technologies, etc."
Re-‐priori3ze o;en
How to do it? 1. Divide into groups of 3-‐5 people 2. Start by gathering “things people do” – the tasks. Write them
down individually and then read them aloud to your group – Likely they start with a verb. – These are high level user stories called “Tasks” (walking skeleton) – This forms your story map skeleton
3. Group them silently (simply because it is faster) 4. Name the groups and lay them out in order of <me (lej to
right) – These are called “User Ac3vi3es” (backbone)
How to do it? 5. Add more detailed user stories below the main tasks 6. Priori<ze top to bo8om 7. Break into releases 8. Assign values
Itera<ve 1 2 3 4 5
Credit: Jeff Pa8on
Incremental
thanks
Fabio Armani www.open-‐ware.org
f.armani@open-‐ware.org, @fabioarmani
Andrea Torino Rodriguez [email protected], @agilerod