Scrum Learning Game: Elephant Carpaccio

1. NANO INCREMENTAL DEVELOPMENT AKA ELEPHANT CARPACCIO
2. WHAT HAVE WE GOTTEN OURSELVES INTO? • Elephant Carpaccio is an exercise invented by Alistair Cockburn to help people practice breaking user stories and their related tasks into really thin vertical slices.
3. WHAT’S A STORY ANYWAY? • As a <type of user, "Actor">, I want <some action> so that <some goal/achievement>. • As Alex, I want to be able to filter my dash dashboard by list so that I can isolate data to a specific list. • As a Developer I can select from configuration options, press a button and have a VM in less than 10 minutes.
4. “INVEST” • Independent, demo-able, potentially release-able • Negotiable • Valuable (Customer, knowledge) • Estimatable • Sized Right • Testable (Has i/o) User GUI Client Back End
5. HOW BIG CAN STORIES BE? Months Weeks Days Hours Minutes
6. WHAT WE WILL DO TODAY • Build a simple application • 5 iterations of 10 minutes each • Instead of 3-5 slices, we’re aiming for 15-20
7. WHY SMALLER STORIES? • Learn faster w less risk • Better product earlier • More business options • Less time “underwater” • Deliver value more often • Happier stakeholders • Happier users CumulativeValueDelivered Time Small stories Medium stories Big stories
8. THE PRODUCT: DISCOUNT CALCULATOR Three Inputs: • Quantity • Unit price • 2-letter state code One Output: • Total price (discounted price plus sales tax)
9. SPRINT 0: CREATE THE BACKLOG • Demo-able • Implementable within sprint time box • Noticeably different from other “slices” • Adds value
10. HOW WILL YOU BUILD? • What is your first slice? • Can you slice things even thinner? • Risk reduction • Value = customer value + knowledge value • Walking skeleton….
11. SPRINT 1… • Write code • Tests (TDD, red/green, NFT?) • Pair? • Shout “slice” whenever you finish one • Go! • Demo / Acceptance test…
12. SPRINT 2… • Shout “slice” whenever you finish one • Demo / Acceptance test…
16. COMMON SPLITTING TECHNIQUES • Defer complexity • Zero, then one, then many (e.g, states codes) • Hard coding values • Defer validation • Simple interface (GUI last)
17. RETROSPECTIVE • How far did you get? • How was your code quality? • How many and what kind of slices? • What did you learn?
18. BUT WE CAN’T SHIP THAT STORY… • Independent: demo-able, potentially release-able • A Minimal Viable Product or Minimal Viable Feature consists of one or more stories that have been put together to provide enough value to warrant it being put into production. • The Product Owner decides when enough value has accrued to meet the “let’s ship it” threshold
19. www.andycleff.com “Type a quote here.”

Editor's Notes

(Text on slide) After he named the exercise, he later realized that he got the language is backwards; we are not starting with an elephant and deconstructing it into slices. Having a pile of elephant slices does not produce an elephant.

We are actually going in the other direction: starting from nothing and constructing the elephant. First an armature, then a walking skeleton, then a semblance of a moving elephant, and so on.

So maybe Elephant lamination… not slicing - but Elephant Carpaccio is so much more catchy a name…
So what’s a story?

A Story typically follow a familiar format:
As a <type of user, "Actor">, I want <some action> so that <some goal/achievement>.
There’s quite a lot tucked into the simplicity of user/action/goal, and this mnemonic “Invest” helps breaks things out:

Independent: story should be self-contained, w no dependency on another user story. It is demo-able for feedback and potentially releasable
Negotiable: User stories, up until they are part of a sprint, can always be changed, refined, split and rewritten.
Valuable: A user story must deliver value to the end user. (Where the actor is an external customer they can do something; for an internal user the value in a story might be knowledge). Value should be noticeably different from any other story.
Estimatable: Clear DoD: so the team will be able to estimate the effort to complete it
Sized right: typically this means that it can be completed within a single iteration with some level of certainty;
Testable: Usually some sort of input/output and it has clear acceptance criteria.

Also, typically spans multiple architectural layers: UI, client, and a backend. Nobody has figured out how to work that into the mnemonic though…
How big can stories be? The “sized right” criteria is a little fuzzy. “Fits into an iteration” - which could be anywhere from a week to a month. Really big stories are typically called epics - which might then span more than one iteration.

Anyway we keep our stories down in size to prob days. Today, we’re gonna play a bit and see what happens when we go to minutes… while we still keep them vertical
Plan on use any programming language you want. Interface could be console, command line, mobile, web, gui, whatever.
Why? Conceptually there are a lot of benefits to thin slicing

Allows for quicker feedback cycles
Makes it easier to verify things since there’s just a small increment of functionality
Provides much more flexibility - for example dropping a story without the burden of the sunk cost
Helps prevent assumptions which can lead to bloated stories
Over time the area under the value curve - the cumulative value delivered is greater - which leads to much higher customer satisfaction

And we’ll see what comes out of today’s experiment
We will build a retail discount calculator: a runnable application with a UI taking 3 inputs and producing 1 output.

(Write discount levels and sales tax on a whiteboard)
Start w the first 3 Discount Levels (change mid project to 5)
• 1,000 3%
• 3,000 5%
• 5,000 7%
• 10,000 10% <- add mid project
• 50,000 15% <- add mid project
5 states sales tax (any other produces error message)
• UT 4.7%
• CA 7.5%
• NV 6.85%
• PA 6%
• NJ 7%

Set let’s break up into teams…. grabs some post its, and then we’ll talk about sprint 0…
Plan on use any programming language you want. Interface could be console, command line, web, gui, whatever.
Decide how will you write & test your code? Make a decision & stick with it.
TDD. By-the-book TDD. Red Green Refactor.
Red-green. Same as above, but refactoring is optional.
Some tests. For some but not for all slices, and not necessarily test-first.
NFT (no f*ing tests).
Close laps tops. Grab post-its and pens. Create your backlogs
Anybody need another sprint 0????
Oh, legal just called. They said we can’t ship this thing unless we compute sales tax…
Sales just called, they have a couple of whales on the hook, and we need two more discount levels

* 10,000 10%
* 50,000 15%
How did you sprint?
First - just a simple hello-world / echo-input-to-output
Order value. 2 inputs (quantity and price), hard coded state? or enter sales tax, and 1 output.
How did you handle sales tax? Sales tax directly? Simpler code, no data structure to map state to tax rate?
State look ups, discount look ups
GUI, etc…
Name some take-away insights from today,
Anything you might do differently in the future.
Why would you want to build a story that isn't shippable? The answer is that some aspects of a feature might not be production worthy if you look at them in isolation.

An feature can consists of 1 or more stories, and an MVP of one or more features.

The Product Owner then decides when there’s enough accrued value in individual stories to ship something.
You can find me at http://www.andycleff.com

Scrum Learning Game: Elephant Carpaccio

You are reading a preview.

Check these out next

Scrum Learning Game: Elephant Carpaccio

More Related Content

Slideshows for you (20)

Similar to Scrum Learning Game: Elephant Carpaccio (20)

Recently uploaded (20)

Scrum Learning Game: Elephant Carpaccio

Editor's Notes