Elephant Carpaccio facilitation guide

The Elephant 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 exercise was invented by Alistair Cockburn. We’ve co-facilitated it a bunch of times and encourage people to run it everywhere.

Here’s a pretty detailed (shu-level) guide showing how to run the exercise.


  • 1
    August 3, 2013 - 7:52 am | Permalink

    Tack! Underbar!

  • 2
    September 10, 2013 - 10:37 pm | Permalink

    This is excellent; can’t wait to try it. Not just to explain vertical slicing, but also to explain the benefits of TDD to certain people. Might also run it (without the actual coding) at the London Agile Discussion Group. Will report back…

    • 3
      Olle Hallin
      January 5, 2014 - 12:04 am | Permalink

      Just a remark: Elephant Carpaccio is completely orthogonal to TDD. I attended Alistair’s Advanced Agile course last year, and when we did the EC excercise we soon abandoned TDD. It slowed us down too much :)

      • 4
        Henrik Kniberg
        January 5, 2014 - 2:30 pm | Permalink

        Yeah, as part of the debrief it’s useful to discuss the payoff time for TDD. Like with all investements, it’s a long term gain at the price of a short term loss. In a 40 minute programming exercise even TDD-experts can’t regain the investment. Most people I meet say the payoff time for TDD is in the range of weeks, which matches my experience too. For TDD newbies it’s probably months, because you have to factor in the time it takes to learn the actual mindset & techniques & tools.

  • 5
    September 18, 2013 - 8:02 pm | Permalink

    Ran the story part at LADG yesterday. Although we got quite a lot of value out of it, you’d definitely get a lot more doing the whole exercise. Plan on running it again soon but in its entirety.

  • 6
    September 19, 2013 - 4:02 pm | Permalink

    […] then split into small groups to run through an exercise on Elephant Carpaccio. You ideally need 2 hours to run this and you need developers for this. We decided to do it without […]

  • 7
    Steve Barrett
    October 1, 2013 - 2:09 am | Permalink

    Great exercise to help solve a common problem for new teams.

    Interestingly Alistair did it all without use cases :-)

  • 8
    October 11, 2013 - 5:52 pm | Permalink

    […] So it’s really important to break big features into smaller sub-features that can be completed in a few days. If you need practice doing that I can highly recommend the elephant carpaccio exercise. […]

  • 9
    November 4, 2013 - 9:08 pm | Permalink

    […] So I was very excited when I found ‘Elephant Carpaccio’ by Alistair Cockburn (although I found Henrik Kniberg’s instructions better). I raised this recently at a LADG session. Although we didn’t have time to run the dev […]

  • 10
    Wouter Hoving
    December 11, 2013 - 5:18 pm | Permalink

    Great workshop! Thank you for sharing.

    Since a couple of months we run the slicing workshop within our organisation. The effect it has on participants is enormous. It is a fun way for people to learn the notion of making your slices small and it creates an understand on each other’s hidden “slicing assumptions”. Vertical slicing is becoming a concept in our organisation.

    David Bogaerts & Wouter Hoving
    Lean & Agile coaches, ING Bank, the Netherlands

  • 11
    May 5, 2014 - 8:07 pm | Permalink

    The guide to the link is broken at this time.

  • 12
    September 30, 2014 - 3:46 pm | Permalink

    […] Henrik Kniberg has written an excellent guide on how to facilitate this exercise. Here’s my slides based on that presentation to make it a little bit easier to remember and run it in a classroom. […]

  • 13
    Stefan Nijenhuis
    November 7, 2014 - 12:44 pm | Permalink

    We did the Elephant Carpaccio exercise last week with a couple of .Net developers who are experienced in agile processes, doing coding dojo’s and practicing TDD. The point was to practice with slicing. We did this, but learned some things I had not expected.

    1. How do you slice your user stories?
    * ultra-thin slices felt uncomfortable, but in a continuous delivery way of working they might be very valuable
    * we need a PO present; developers cannot decide the ordering of the backlog. it’s a business decision
    * user story mapping is a very nice technique for finding minimal viable products. It even works for this exercise.
    * It’s important, but hard to think in functional slices. We’re used to refactoring and slicing thin in technical units.
    * In the facilitation guide, fancy UI is delayed, but a bit of UI might help to discuss with the PO about slices.
    * some slices in the facilitation guide were still from a developer perspective. The elephant is “Getting a correct order total”. A thin slice could be (“order below 1000 dollar, no discount, for sales in TX only).

    2. How about quality?
    * all teams started out without unit tests. All of them felt uncomfortable after a few iterations.
    * question rose; at what point in time have you missed the chance of automating your tests? our answer: add some important ones right away from the start. Otherwise you’re too late
    * who is to decide about quality? It’s dangerous to make it a functional wish. Or a specific backlog item. Or make it negotiable. The team should guard quality. Period.
    * One of the teams started out using a source repository. every functional slice was checked in.
    * At what time do you refactor? initially the teams went for functional slices. But at what time is using nice naming conventions for your controls a requirement?

    3. your first increment?
    * We found out that an important part of the first increment was not only the walking skeleton of the application, but also the first agreements on the way of working and the setup of the development environment. In real life this would be a Definition of Done, a source repository, a continuous integration process and a few high level automated tests. Without it, we would take some pain in the upcoming increments.

    Next time, I will
    * use this exercise in the context of continous delivery. Sales can only be made when the order total is displayed on the screen.
    * start off with a story map en define some functional valuable increments (e.g. “orders below 1000$ for sales in TX”)
    * be the PO myself

  • 14
    February 5, 2015 - 11:37 pm | Permalink

    […]  TDD avec real-options sur l’exercice Elephant Carpaccio […]

  • Leave a Reply

    Your email address will not be published. Required fields are marked *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>