Elephant Carpaccio: An Agile recipe that will give you an indigestion
Considerations about user story writing and delivery in an agile context.
During the last few years the “Elephant Carpaccio” expression was made famous. Many times also referred to as the activity of “Slicing the Elephant”. This is the agile concept of Divide and Conquer. In particular when using the Scrum framework, teams have to do sprint planning. At the end of every sprint the committed stories should be ready for release. This means that all stories have to be possible to perform, at maximum, during the length of the sprint. But most times, when a requirement reaches the team, it is too big for one single sprint. This is when the slices appear. The idea is that an elephant (the story) can be divided (sliced) into pieces (as thin as carpaccio) so that, sprint after sprint, it can be slowly built until the entire elephant is assembled.
As much interesting and appealing this metaphor might be, it can lead to the wrong results. The first thing is that, if you take an elephant and cut it in pieces it will most likely die. If in a certain sprint only a piece of the elephant is produced, it’s just dead meat. Unable to act like an elephant, or anything else. Looking at the stories, every committed story should add value to the product at the end of the sprint. If that “piece” will not do anything good for the end user it’s better not to do it.
There’s another reason why this metaphor doesn’t work. Of course you can always say: “we don’t deliver value to the product every sprint but we will when the elephant is completed. It’s only a small adaptation of Scrum”.
One of the values of the Agile Manifesto is: Responding to change over following a plan. There are also two principles that I would like to bring to the topic:
- Simplicity — the art of maximizing the amount of work not done — is essential.
- Welcome changing requirements, even late in development.
What happens if, as it is common, half way through building the elephant the requirements change and the elephant is not needed anymore?
Anyone would say that to continue building the elephant, slice by slice, is not acceptable. It’s not required anymore so it should not be prioritized in the following sprints. Not responding to this requirement change is definitely not agile. What to do with the half elephant that was built in the meantime? It doesn’t do anything. Half an elephant is still a dead elephant. All that effort will just go to waste. There is, potentially, a huge amount of work that was done that was not needed. Again, not really following the agile principles.
How to handle the elephant then?
Probably it’s not as visually interesting and doesn’t provide such an appealing metaphor but, instead of slicing elephants, I prefer to think on raising elephants.
Let’s say — as an extreme example — you have the goal of providing education to young students about large mammals. And you decide to do that by allowing the students to interact with a real elephant. Do you think it’s a good idea to start gathering pieces of elephants and put them together like a Frankenstein? Maybe you can start with a baby elephant. It requires less food and space than an adult one. You’ll have to train it to behave near the students and maybe a baby elephant cannot be as educational as an adult one but, on the other hand, the initial investment is smaller. You can start showing it to the students almost from day one, already achieving your goal. As it grows, it will be better trained, it will acquire different characteristics that you can use. It will become bigger and better. And if, during the time the elephant is growing, you realize you don’t need a live animal to teach students, maybe pictures and schematics are enough, you can simply release it back to its natural habitat. No effort was wasted. With half an elephant you couldn’t discover that, as no one would be able visit it and give you feedback. And if you did come to that conclusion, half an elephant will not be very happy in nature.
How does that match with the story writing?
Well, writing stories is hard. Let’s take an example of an online selling website:
As a user, I want to be able to store my personal information, so that every time I buy something I don’t have to enter everything again and my purchase experience becomes more simple
It seems pretty simple and straight forward, doesn’t it? A typical split of this story, when done using the Carpaccio Method, would be:
- Sprint 1: Deploy database and design data model (user personal data + delivery details + payment information)
- Sprint 2: Build business logic to handle user data
- Sprint 3: Build user interface to allow user to store and manage its data
In this case it will take, at least, 3 sprints, until the user actually sees something working. It will take at least 3 sprints until the team is able to get user feedback on the functionality to know if they are building the right thing. If the requirement changes after sprints 1 or 2 is completed, work goes to waste without adding any value.
If we start with a small elephant and make it grow we could have something like:
- Sprint 1: Allow user to store and manage it’s personal data (database + business logic + user interface)
- Sprint 2: Allow user to store and manage it’s delivery details (database + business logic + user interface)
- Sprint 3: Allow user to store and manage it’s payment data (database + business logic + user interface)
In this example the user can use the functionality and give feedback from sprint 1. The team can immediately start learning from it. It will take the same time to deliver the full elephant but, if for some reason the team understands this is actually not needed, the entire effort does not go to waste. Value is delivered to the user from the first moment.
Writing stories is not an easy thing and this is only simple example. What is important to keep in mind is that, whenever a story is written, it should cover the feature from end-to-end. It should actually work and add value to the product. It should not be a technical split and it should not use effort that later might be sent to waste.
And what about you? How do you write your stories? Do you like the carpaccio? Or do you prefer other approaches?
