Dinosaur Carpaccio - How to implement valuable micro-requirements

ROME 11-12 april 2014ROME 11-12 april 2014

Dyno Carpaccio – come implementare micro requisiti di valore

Fabio Armani �� Stefano Leli

[email protected] - [email protected]@fabioarmani @sleli

ROME 11-12 april 2014

ROME 11-12 april 2014 Fabio Armani, Stefano Leli

• Un punto chiave dello sviluppo software è dato dal rilascio continuo di valore al cliente finale e in questo scenario uno degli strumenti più attuali per descrivere i requisiti sono le user story.

• Molti team, ancora oggi, faticano a realizzare storie piccole e quando ci provano finiscono spesso con l'ottenere ‘layer’ quando ci provano finiscono spesso con l'ottenere ‘layer’ dell’architettura orizzontale e non micro soluzioni verticali che attraversino tutti gli strati (dalla UI alla persistenza).

• Tale situazione fa si che l'assunto iniziale decada e il valore portato al cliente nella migliore delle ipotesi non sarà continuo (nelle peggiori, nullo).


• The Dyno Carpaccio exercise is a great way for software people to practice & learn how to break stories into really thin vertical slices. It also leads to interesting discussions about quality and tech practices.

• The original exercise (Elephant Carpaccio) was invented by Alistair

What is this?

• The original exercise (Elephant Carpaccio) was invented by Alistair Cockburn. We’ve facilitated it a bunch of times and we encourage people to run it everywhere.

• This is a detailed (shu-level) facilitation guide based on how Alistair runs it plus some minor adaptations from Henrik Kniberg and us.

• The exercise takes 90-120 minutes, and scales well. We normally do it with 10-20 people but have also done it with groups up to 40.


• 2 hours is best, 1.5 hour works but feels a bit rushed.

• 15’ discussion about user stories

• 20’ breaking down backlog

• 45’ implementing

Timing

• 45’ implementing

• 10’ debrief

• It’s possible to skip the implementing part & just practice creating the backlog. But it takes away much of the fun, and you also miss out on interesting quality discussion at the end.



The purpose of this workshop is to learn to split stories really small…


• Vertical, testable, user-valuable.

• Cuts across multiple architectural layers.

Story

GUI

Client

Back End

Slicing StoriesSlicing Stories


• Making thinner stories (but still vertical)

Story SlicingB

IG

SM

ALL

monthsweekshours daysminutes


• How big are your stories? tasks? commits?

• Target:

• Story = a few days

• Task = a few hours

Discussion


• Commit = several times per hour

• Why split stories?


• How big are your stories? tasks? commits?

• Target:

• Story = a few days


Discussion


• Commit = several times per hour

• Why split stories? Discuss in pairs


• Learn faster

• Deliver more often

• Happier stakeholders

• More in-sync with other people & teams

Why split stories

• More in-sync with other people & teams

• Better prioritizations

• Better product earlier


• More business options

• Less risk (less time “underwater”)

• Sense of velocity

• Easier planning

Why split stories

• Easier planning


Big stories

Small stories

Waterfall

Big stories


• Decision of “how small” should not be limited by “we can’t split this story”.

• In this workshop we will practice by exaggerating.

• We will make stories so tiny that anything you do today seems big

How Small

• We will make stories so tiny that anything you do today seems big in comparison.


• Build a simple application in 45 minutes, divided into 3 iterations x 15 minutes.

• Most people would build this app in 2-3 slices, we will do it in 15-20.

• Dyno Carpaccio = very thin slices, each one still dyno-shaped.

What we will do

• Dyno Carpaccio = very thin slices, each one still dyno-shaped. Together they form the whole dynosaur.





Requisito #1Come utente vorrei vedere dov'è l'auto più vicina rispetto alla mia posizione attuale in modo da poter individuarla velocemente e poterne fruire comodamente.

Requisito #2Come utente vorrei poter prenotare l'auto desiderata in modo da poterla ritrovare una volta giunto nel luogo dove si trova parcheggiata.

The product

Requisito #3Come utente vorrei poter conoscere lo stato dell'auto (livelli di benzina, stato generale, etc) in modo da potermi fare un'idea del veicolo prima di prenderlo.

Requisito #4Come amministratore delegato vorrei consentire una tariffazione basata sull'effettivo utilizzo dell'autovettura in modo da distinguere il mio servizio dagli autonoleggi tradizionali.

Requisito #5Come addetto alla manutenzione vorrei poter conoscere (automaticamente) tutte le auto che hanno problemi in modo da poter organizzare le ispezioni e le riparazioni.

Requisito #6Come utente vorrei poter effettuare Login e Logout dell’app.



• Split into groups of 5 or 6. Each group should have at least one designer with the POP Prototype app installed.

• Pop Prototype

• 10 minutes: write your backlog

Create the Backlog

• 10 minutes: write your backlog

• Write 10-20 demo-able user stories (“slices”) that will take you from nothing to all requirements implemented.

• Each should be implementable (including user interface) in 2-6 minutes.

• All demos show new interfaces, and are noticeably different from last slice.


• What is your next slice?

• Key point: minimum key stroke per slice!

• 5 minutes: make make your slices smaller. Try for at least 15 slices.

Create the Backlog



• This workshop is primarily about story slicing, but adding UX practices aspects gives it extra spice.

How will you work?



• 45 minutes, 3 iterations, 15 minutes per iteration.

• At the end of each iteration, We will call out “demo time!”. That means stop coding, and demonstrate your app to another team.

• Time doesn’t stop between iterations! So don’t spend too much time

Build It

• Time doesn’t stop between iterations! So don’t spend too much time on demo.

• Shout “slice” whenever you finish a slice.

• Go!



• How far did you get? (mark each team’s approximate position on the value curve)

• How many slices did you have?

• Acceptance test:

Review

• Acceptance test:

• Show the app in POP Prototype.



• Non-programmers: What was it like?

• Programmers: What was it like?

• How is your app quality, how proud are you of your app? (each programmer hold up 1-5 fingers).

Debrief


• Any other questions or reflections?

• Round-robin: What did you learn? What will you do?

• Name one take-away insight from today, and one thing you will do differently in the future.

Debrief

differently in the future.

@sleli@sleli

[email protected]@gmail.com

@@fabioarmanifabioarmani

[email protected]@open--ware.orgware.org

Technology

Dinosaur Carpaccio - How to implement valuable micro-requirements