Skip to content

Latest commit

 

History

History
260 lines (195 loc) · 6.18 KB

elephant-carpaccio.md

File metadata and controls

260 lines (195 loc) · 6.18 KB
title author date css highlightTheme
Elephant carpaccio kata
Zeger Hendrikse
2023-12-19
css/custom.css
github-dark

 

 

Elephant Carpaccio kata

 

 

 

Credits: Alistair Cockburn, Hendrik Kniberg, Michael Wallace

 


Goals

  • Splitting user stories vertically
  • Value of splitting user stories
  • Software delivery value curve
  • Hands-on practice and retrospective

 

 

 


About ...

  • Elephant Carpaccio kata
    • Alistair Cockburn, minor mods by Henrik Kniberg
    • Practice and learn thin slicing
      • size ~ 1-week to 1-day requests
      • from the perspective of the business
    • Experienced teams: all user stories <= 1 day
    • Metaphor: huge elephant ==> tiny sliced stories

Good user stories

  • INVEST
    • “I” ndependent (of all others)
    • “N” egotiable (not a specific contract for features)
    • “V” aluable (or vertical)
    • “E” stimable (to a good approximation)
    • “S” mall (so as to fit within an iteration)
    • “T” estable (in principle, even if there isn’t a test for it yet)

How big are your stories

Size of user stories

  • Target
    • Story = a few days
    • Task = a few hours
    • Commit = several times per hour

Why split stories

  • Discuss in teams (5 minutes)

  • Example outcomes:
    • Learn faster
    • Deliver more often
    • Happier stakeholders
    • Better synchronization with other people and teams (testing)
    • Better prioritization
    • Better product earlier
    • More business options
    • Less risk (less time “under water”)
    • Sense of velocity
    • Easier planning
    • Less risk of carryover

Software delivery value curve

Size of user stories


User story splitting

  • Split by
    • capabilities offered
    • user roles / user personas
    • target device
    • CRUD boundaries
    • Happy path/other paths
  • Zero/One/Many approach
  • Scope: walking skeleton

The kata

  • Assignment
    • Create +/- 15 user stories for a simple application
    • Extremely thin slices, but each is elephant-shaped

Elephant


The Product

  • Build a retail calculator app
    • Inputs:
      • How many of an item
      • Price per item
      • two-letter state code (for sales tax)
    • Output:
      • Total price of order
        • Discount based on order value
        • Sales tax based on discounted value

  • Create 10 - 20 slices to reach the target
    • A slice should
      • have a UI (input and output)
      • be visibly different from the last slice
    • Sales tax before discounts
      • Compliance: tax is a legal requirement
      • When compliant: we can deploy
    • Validation & GUI → last!

Priorities


  • Create the backlog
    • Work in teams of 2 or 3 (or by table)
      • 10 minutes to create backlog on cards
      • 10-20 demo-able user stories (“slices”) to 5 states and 5 discounts.
    • A slice should be:
      • Implementable (including UI).
      • Noticeably different from last slice.
      • More valuable to customer than last slice
      • Not be a mockup/UI/data structure/test case.

Discounts

Taxes

State Tax rate
UT 6.85%
NV 8.00%
TX 6.25%
AL 4.00%
CA 8.25%
Order value Discount rate
$1,000 3%
$5,000 5%
$7,000 7%
$10,000 10%
$50,000 15%

  • Debrief
    • What was it like?
    • How many slices did you have? Examples?
    • Testing
      • No tests/unit tests/TDD?
      • Manual/automated (acceptance) tests?
    • Code quality?
    • Round-robin:
      • Any other questions or reflections?
      • What did you learn?
      • Take-aways from today?