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.
20 responses on “Elephant Carpaccio facilitation guide”
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…
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 🙂
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.
Agreed Olle: you can’t run TDD in this session as it’s too short. But you can still talk about it in the debrief as Henrik says.
I’m assuming that you didn’t meant that you threw out TDD in the real world after the workshop with Alistair?!
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.
Great exercise to help solve a common problem for new teams.
Interestingly Alistair did it all without use cases 🙂
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
The guide to the link is broken at this time.
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
Would love to hear more about the story map angle!
We did the Elephant Carpaccio excercise – you can read about my experiences in my blog post: https://medium.com/@oliverzech/elephant-carpaccio-exercise-an-experience-report-207f0cc79c34