Elephant Carpaccio

Elephant Carpaccio is an exercise by Alistair Cockburn designed to teach how to finely slice a requirement into vertical pieces. Participants work on a small sales price calculator: it takes a quantity, a unit price, and a state, then applies a tax based on the state and a discount based on the amount. In pairs or trios, they first break down the application into 15 to 20 deliverable and user-visible slices. They then develop for 40 minutes, in 5 iterations of 8 minutes, with a demonstration at the end of each. The exercise highlights the value delivered early, rapid feedback, and the difference between technical slicing and vertical slicing.

Walkthrough

1. 1

   Set the framework and objective

   10 min

   The facilitator presents the exercise: "Your challenge is not to finish a perfect application, but to deliver visible and usable pieces very early." They announce the topic: a calculator that takes a quantity, a unit price, and a state, then applies a tax based on the state and a discount based on the amount. They specify the total duration, 90 to 120 minutes, and the core of the exercise: 40 minutes of development in 5 iterations of 8 minutes. Participants form teams of 2 to 3 people, ideally with one workstation per team.

   Tip — Emphasise the word "visible" from the start: a slice that does nothing for the end user will be questioned during the debrief.

2. 2

   Clarify the expected product

   10 min

   The facilitator describes the target behaviour without delving into a technical solution: "The user enters a quantity, a unit price, and a state; the system calculates a selling price considering a state-related tax and a discount related to the amount." They check that everyone understands the inputs, outputs, and the concept of business rules. If a tax and discount rules document is used, it is distributed now, and teams are asked to refer to it. Participants can only ask questions for understanding the need, not for design.

   Tip — Do not answer questions with architecture; always bring it back to usage: "What would the user see? What result could they verify?"

3. 3

   Slice into 15 to 20 vertical pieces

   20 min

   Each team slices the application into 15 to 20 pieces, each deliverable and visible to the user. The facilitator gives the instruction: "A slice must produce a demonstrable behaviour, even if tiny; avoid slices like database, screen, calculation engine, or tests alone." Teams write their slices in a possible order of delivery, from the simplest to the richest. The facilitator circulates and challenges any slices that are too large or too technical by asking: "What can you show in less than 8 minutes?"

   Tip — When a team proposes a slice that is too broad, ask them to cut it down until they achieve a version that is almost embarrassingly simple, but demonstrable.

4. 4

   Select the first slices

   10 min

   Teams review their list and choose the first slice to develop. The facilitator reminds them of the constraint: "In 8 minutes, you will need to demonstrate, even if it is incomplete. Choose a slice that can actually be shown." Participants can reorder their 15 to 20 slices to maximise rapid learning. The goal is to start with a visible delivery, then gradually add taxes, discounts, special cases, or user comfort according to the chosen slicing.

   Tip — Have each team verbally rephrase the first slice; if it contains "prepare", "install", or "design", it is probably not yet vertical.

5. 5

   Develop in 5 iterations of 8 minutes

   40 min

   The facilitator starts the timer for 5 iterations of 8 minutes. In each iteration, the team chooses one or more very small slices, develops, and then stops abruptly at the end of the allotted time. The rule is strict: at the end of each 8-minute period, there is a demonstration of what works, even if it is minimal. The facilitator regularly announces the remaining time and encourages teams to reduce their ambition rather than postpone the demonstration.

   Tip — Clearly announce "half-time", then "2 minutes", then "30 seconds"; this forces cutting decisions and avoids development tunnels.

6. 6

   Demonstrate at the end of each iteration

   15 à 25 min inclus dans le rythme des itérations

   At the end of each 8-minute iteration, each team briefly shows what is usable. The facilitator asks: "What slice did you deliver? What can the user do now that they couldn't do before?" The demonstration should focus on the behaviour of the calculator, not on the code or architecture. Other participants observe the finesse of the slices, the order of delivery, and the moments when a team received useful feedback.

   Tip — Firmly limit technical explanations: if the team cannot show a behaviour, note it as a debrief topic rather than allowing lengthy justifications.

7. 7

   Debrief the learnings

   20 à 25 min

   The facilitator gathers the teams and compares their trajectories: first slices delivered, moments of blockage, feedback received, visible value. They refocus on the three key themes: what constitutes a good slice, how to deliver value early, and how rapid feedback influences choices. Participants identify slices that are too large, too technical, or too late. The facilitator concludes by asking how to transpose this slicing to their real products or projects.

   Tip — Ask for specific examples of slices written by the teams; the debrief becomes much more powerful when we work on their actual formulations.

Variants

• Accelerated variant: keep the same principle but reduce the framing and slicing time for participants already familiar with agility. The 5 iterations of 8 minutes and the demonstration at the end of each iteration must be strictly maintained.
• Variant without real development: teams do not code, but produce mock-ups, examples of results, or manually executable scenarios. The constraint remains the same: 15 to 20 slices, each deliverable and visible to the user.
• Remote variant: create breakout rooms of 2 to 3 people, a shared board for the 15 to 20 slices, and a visible timer. At the end of each 8-minute iteration, all teams return to the main room for a brief demonstration via screen sharing.
• Product-focused variant: ask teams to explicitly name the user value of each slice before developing. This variant strengthens the link between vertical slicing and prioritisation decisions.