Elephant Carpaccio V2

Matteo Regazzi
Jul 24, 2014 · 9 min read

- leverage the power of microslices -

DISCLAIMER: NO ELEPHANTS WERE HARMED DURING THE WORKSHOP. THE PRODUCT OWNER GOT SICK AND SOMEBODY SHOT THE SCRUM MASTER BUT THAT’S ABOUT IT.

The original recipe

Since it was created by Alistair Cockburn and described by Henrik Kniberg in his guide, I facilitated several sessions of Elephant Carpaccio, in its original version. For those not familiar, this is an exercise in which a software development team, stable or temporary, can do to better understand the benefits that can be obtained in dividing the user stories into very thin but still vertical slices. Hence the name of culinary origin since carpaccio is meant for a preparation that includes slices (usually meat slices​)​ so thin as to be translucent. When I think of a team I do mean a cross-functional one with developers, testers, product owners, ui and ux specialists and whoever else you need in your project.

Are you fighting against the system ?
  • stories don’t meet the INVEST characteristics (*)
  • stories are splitted in back end and front end ones
  • before we can use a functionality, we must develop several stories related each other
  • we split each functionality in stories, one for each component we should develop or modify
  • not all stories are vertical and testable and represent user value
  • it happens sometimes that due to priority changes it needs a lot of time (several sprints) to see a functionality
  • story estimates are very diverse (no matter if you use story points, ideal days or any other units of measurements
  • we feel that the complexity of the system is increasing
  • we feel that in the past stories of similar complexity (compared to those currently in the backlog) would have required less effort

Let’s add some ingredients

Before you continue

If you have followed me this far may be you are a coach that usually facilitate Elephant Carpaccio sessions, so you can pursue and evaluate whether variations that I suggest can do for you. It ‘also possible that you’re never come in touch with this exercise, but you’re interested in its application: in this case jump to the bottom of the article, look for the references to the original version and start from there.

Hey, this is an agile system, isn’t it ?

Are we missing a spice ?

A couple of months ago I was at home, reading some stuff on the web. It was about 10 minutes to midnight. The day was spent quietly, Stefano and me had facilitated a session of Elephant Carpaccio with a relatively new team. Then I received an email from Pasquale, one of the developers who had participated in the workshop. The subject seemed ominous: “8 minutes”. Fortunately, the content of the email was not about the end of the world. That was the time had taken him to develop from scratch, using Python, the same application that he had failed to complete during the workshop. The coding phase in the exercise lasts 40 minutes, and Pasquale had used PHP which is a language that he usually use.


Variation 1: Stop at sprint 4 because the budget is over

For each sprint concluded I record on a white board or on a flip chart the value delivered by each team. I defined 4 tests, each test satisfied is point. At the end of the fourth sprint I stop everyone and i say that the client’s budget is over. No more code. The team that worked incrementally should have delivered more value, while those who worked with larger slices might have a nasty surprise. It’s a realistic situation. Unfortunately the solution dos not leave a pleasant memory. Use it just to get a disruptive effect and annoying. If you adopt this variation, bring it to the end without remorse. Do not start the last sprint, the effects would be rendered meaningless.


Variation 2: Team uses earnings to buy advanced tools

For this version, I was inspired by the Kanban Pizza Game from Agile42. Each team start coding using the worst tool they have, for example notepad or even the console appender (the MS-DOS “copy con” command). When a team delivers value they receive chips (fiches) and they can use them to buy tools, such an editor, then an IDE. In this case we are playing with constraints but we are using them just to point out the cash flow.


Variation 3: Risk / Risiko

In the original exercise we must develop functions for five states (Utah, Nevada etc.). Paint on a whiteboard a simple map of United States. Now imagine the team is developing and offering a service: delivering value for a state means the team starts to earn one or two chips for each state. We can also have the customer earning from each state but the result is almost the same. And … what about a Monopoly variation ?


Variation 4: Customer losses will increase if no deliveries

The customer starts to receive requests since sprint one. Each uncompleted sell will be presented as a customer loss. Requests arrive from every state. Losses for a state won’t stop until all requirements for that state are satisfied. You can also develop a simple application that send requests: each uncompleted sell will be tracked. This is more difficult because you must be connected to the same network and, moreover, you are asking to develop a web app (or whatever able to accept network requests).


Variation 5: Ask a fatal change

Between the fourth and the fifth sprint ask for a change, such as: “I am the customer and I am asking you to change the software in order to manage the case a customer from Utah sends a request to the shop in Nevada”. In this case we are likely playing with design: an incremental design favored by a higher number of slices should lead to a easier change, while a non incremental design should lead to a panic situation. Use this variation if you want to join the practice of TDD.


Tips

  • Have a two phases planning: during phase one split the project into stories while during phase two the stories should be splitted into incremental slices. Usually testers have a remarkable ability to suggest the slices.
  • A team started developing the app using a spreadsheet: well, probably this was good idea but … hey… I was the customer and I haven’t budget for Excel.
  • During the exercise a team must be really focused on value and on keeping everything simple: if a team is working on bell and whistles (such as GUI, input validation or configuration data entry) let them go on until sprint 3 or even 4.
  • May be you are impersonating the customer: don’t reveal every single detail, you are the famous “on site customer”, the team can ask you when they are in doubt.

  • Negotiable: incrementally includes details which are unnecessary to planning but required later to implementation.
  • Valuable: must be real value for the customer / user (see next paragraph).
  • Estimable: easy to be approximately estimated to allow its scheduling.
  • Small: in order to be predictable and allow a continuous and fast delivery of value to the customer / user.
  • Testable: if not easily testable, then a story is not clear, first of all to those who required the development (if the request is not made by the customer then go back to “V”).


    Matteo Regazzi

    Written by

    http://t.co/52XVWaE5sq