Elephant Carpaccio exercise — an experience report

Elephant Carpaccio is a great exercise to practice how to break user stories into really thin slices. You can read everything about it in the Elephant Carpaccio exercise facilitation guide by Henrik Kniberg & Alistair Cockburn.

I facilitated this exercise and can recommend it to every development team working with user stories — but be prepared that it won’t work out as given in the facilitation guide. It would have helped me to read some other experiences first but I couldn’t find any on the internet. That’s the reason why I decided to write a post about my experience. I hope I can help anybody with it and would be happy to hear something about other experiences.

The setting

I am Scrum Master in a Development Team working on a web application. We develop this application as a service for one of our customers, who provides two Product Owners for this. As they are located in a different city collaboration is limited to telephone conferences, instant messaging tools and project management tools. But we try to visit each other as often as possible to spend some days together with workshops and face to face conversation.

Last time the two Product Owners visited we included them in a mob programming session and we did the Elephant Carpaccio exercise. I chose this exercise because my main goal for their visit was to increase their understanding of coding, as they don’t have a chance to experience this in their usual working day. Another reason for choosing this exercise was that we tend to split user stories only because of technical reasons or because they are simply too big to implement during one sprint. So I wanted to show that there are many other reasons to split stories and that smaller stories can lead to increased product value.

While preparing the workshop following the detailed facilitation guide I was very confident that I will be able to direct the exercise in the right direction and that I am prepared for all upcoming questions and raised doubts. But once again I had to learn that you have to expect the unexpected when facilitating workshops, especially with multi-disciplinary individuals.

I told the development team that we will make a coding exercise and that everybody should have an empty project prepared on their work stations. As I didn’t want to hurry through the exercise and also have enough time for discussions I planned 2.5 hours. Beside the two product owners the whole development team participated (8 developers) — so we decided to split into four teams.

The exercise

I tried to follow the facilitation guide exactly, so we started with the discussion why split stories and followed with the explanation what the exercise is about, what are the goals are and why we practice by exaggerating. After explaining the product and answered some questions the backlog refinement started.

Walking through the teams I saw what I expected — slices were much too big or not vertical. First slice usually was something like calculate order value or input only. I tried to give them some hints to the right direction but after 10 minutes I stopped everybody for another discussion. Together we thought about how to get smaller slices but nobody raised “Hello World”, so I had to come up with this idea by myself. That started a very intense discussion if “Hello World” is a valid slice, as it doesn’t add customer value and it is also not vertical. I tried to direct the discussion to the risk-reduction but teams referred to the handout, which says “all demos show real input & output”. Looking at my watch and didn’t know how to get the discussion any further I just asked if everybody is ready to code and one team seemed to have an issue with their environment. So I asked how they can be sure if their project setup is working, which leaded us again to “Hello World” :)

We agreed that slices which don’t add customer value but reduce the highest technical risks of a product a very important in the beginning. With that knowledge everybody tried to make their slices smaller once again and after five more minutes of slicing they were between 13 to 18 slices. After that we could finally start, but more than 1.5 hours were over already.

Now I was very interested in how the teams would work. As the team has spent a lot of time in coding dojos I expected a lot of keyboard switching and at least one team trying to do some unit testing. But apparently the time pressure in this exercise was too high so everybody just started without any discussion about practices. So testing was no topic and keyboard stayed always in the hands of one developer. Following our discussion everybody started with “Hello World” and we heard the first “Slice!” shouted out pretty soon.

During demo the time pressure was noticeable once again, especially as the timer didn’t stop during the iterations. Some of the team members stayed on their machine and tried to work further while others were very keen on checking for different solutions. Unfortunately that led to a lot of chaos during demo time and not everybody got to see the implementation of all other teams. The idea was to let them self-organize the demos but maybe it would have been better to help them here a bit more.

Beside the chaos during demo time the coding part was very interesting to watch. The hole working space was humming because of productivity and excitement. There was some swearing too but also a lot of laughter and cheering about every new tiny little working slice.

The review

Every team managed to get to 5 states + 5 discounts and started with validation and stuff like that. Together we calculated one order and everybody got the same correct result and was very happy about it. I was quite surprised because I expected much less progress, like given in the typical result in the facilitation guide I expected that they would get only to the hard-coded state tax. So I doubted again — did they focus too much on finishing the application and not learning something during the exercise? As we were close to the end of our time box already we only had a few minutes for debrief.

Unsurprisingly the developers weren’t very happy about the quality of their code. But so we could discuss the impact of (time) pressure to software quality once again and this time the product owners really could see the lack of quality in the code compared to our mob programming the day before, where we practiced strict TDD.

The product owners highlighted especially the fun they had during the coding, which they didn’t expect. I think non-developers enjoy such hands on coding sessions quite a lot, as long as it leads to such results. They really liked it that they could understand parts of the code and the idea, that they could contribute to the code.

Beside that everybody agreed that this exercise was very extreme — but it showed us, that there is a lot of potential to make our stories smaller. This will improve our product and our development process.

The learnings

Although the exercise went totally different than expected and I felt very doubtful about my facilitation — everybody emphasized that they had fun and could take away some insights.

The greatest moment for me was directly after the review, as one of the developers wanted to talk to me in private. He is the junior developer of the team and it was his first face to face meeting with the two product owners. So he told me how insecure he had been about this but that it was a great experience for him and how it was a very good way to get introduced to the customer. So I would say the team building factor of this exercise should also be highlighted.

Things I have learned during this exercise or I would try to make different next time:

• Balance between risk reduction and customer value is not that obvious. Highlight that it is OK to start with risk-reduction slices but everybody should think carefully about when they should switch from risk reduction to deliver customer value to get feedback.
• Always be careful with learning exercises including time pressure. Participants often loose track on the learning topics by ultimately willing to reach the goal.
• Stop timer between iterations (1 minute) and manage which teams have to demo and which have to watch.
• Non-Developers have fun at coding — if they see results while doing it.

I am very curious about your experiences with the Elephant Carpaccio exercise so feel free to comment.