Elephant Carpaccio - Use Case

In my previous post I talked about a technique called "Elephant Carpaccio" for splitting large projects and epics to smaller, measurable and valuable stories and tasks.

I would like to share now an example for a real-life scenario and show how to apply the carpaccio technique for this scenario.

Our example case

Let's say we're working on an enterprise product. We started with one language in our UI - English. And now the company's salespersons say we're missing great deals due to our lack of support in a multi lingual interface. And now your PO asks your team to implement this new feature.

Let's try to think about this feature request. Where do we start? What is most important? And one of the most important questions of all - how long will it take?!

It's obvious we can't just run and implement such a feature because it probably requires some infrastructure to support a generic addition of new languages and most probably this addition of a new multi-language support will require a lot of changes in a lot of places.

Ask questions

A good start I found useful for me is to first ask questions. Many questions. It will be very beneficial to include a few people (at least the team and a product representative) in the discussions and let everybody ask questions. Here are some questions that you will probably want to answer before running and implementing the feature:

1. Will the users of the product be able to change the language whenever they want? Or is it set on the system level for all users?
2. Where in the UI will the user change the language?
3. Do we need to support also things like error messages in our translations? Or is it ok to leave them in English?
4. Should we support any RTL (Right-To-Left) languages?
5. If we support RTL languages - should the entire UI be viewed in an RTL direction?
6. Should the language selection be persisted or is it ok to always start a user session in English and allow the user to change?

Make assumptions

Asking these questions will help both product and R&D to understand where the value for this feature lies and what can be delayed for a later version/sprint.

After the value is clear, you can prioritize and create user stories. Each user story must deliver some value to the user and be estimated according to the efforts and risks that are assumed to be put into it:

Story #1 - Support Spanish in a specific UI menu:

1. DoD (Definition of Done): The user will have a language selection list. When the user selects Spanish, a specific menu will be changed to Spanish
2. Assumptions:
1. The language is not persisted and the next time the user will log-in the system will be in English again.
2. Only one menu should be translated when choosing Spanish
3. Story points - 8: This is a hard story - we need to create the infrastructure.
4. Tasks:
1. Infrastructure design. (1 day - net, after design review and discussions)
2. UI addition (0.5 day - just adding the language list widget is easy. It can be done while waiting for feedback on the design)
3. Implementing infrastructure - storage of language codes, maybe failover (if a message doesn't exist in Spanish we'd like to fall back to English), a generic API for converting message codes to locale strings, etc... (4 days)
4. Change the UI menu to use the converter API (0.5 day)
5. Value: After this story there's a robust infrastructure and an already working spanish menu. The value addition is huge both in the user/product experience it adds and the easement of now changing other places.

Story #2 - Support Spanish in whole of the UI (No error support yet)

1. DoD: All UI texts will be in spanish
2. Assumptions:
1. No support for errors (exceptions)
3. Story points - 5: This is not hard but requires a lot of tedious work of replacing any string to the translation API call. This also requires a lot of time from QA to make sure everything is replaced correctly.
4. Tasks: Just replacing string with the translated text (2 days + 3-4 QA days)
5. Value: After this story we can see a UI that's in a different language and get the main multi-language experience.

Defining other languages

After the previous stories are done we can, in fact, add languages in a very low development (and even QA) costs. If the infrastructure is built correctly it will require no more then adding a file or a DB records with the translated strings. We can now choose 2 methods for splitting the stories:

• All other languages once - Due the easiness of adding a new language splitting each language to its own story would be an overhead so all the languages could be combined into a 2-3 story-points story. Better approach
• Adding languages one at a time - in case other languages are not given in advance, splitting the stories into 1 story-points stories is also fine.

Future features

After we finished the main feature, and we no longer loosing deals it's much easier to prioritize the remaining features like translating error codes, and support RTL and so on. We lowered the pressure from the business side, we provided a huge amount of value.
If these features that haven't made the cut are important enough - they will be waiting at the head of the backlog stack. If not, they will be pushed down the backlog which probably means that they were not that valuable to begin with.


This example is of course very specific and was born out of former projects I worked on. I hope I managed to give you the idea of how to do such tasks. Mastering Carpaccio takes time, but will benefit you a lot.

Find me on Twitter: @AviEtzioni

More interesting posts from this blog:

Cooking an elephant carpaccio

Disclaimer: No elephants or other animals were harmed during the writing of this post.

Make me an elephant

What if I asked you to make me an elephant? Can you tell me how long would it take you? Can you guarantee that under this time estimation you gave me you will be able to create a great elephant, with all the capabilities and characteristics an elephant possesses?

Image taken from here

Tackle this huge story

Ok, so us, software engineers, are not that good at creating elephants. We'll leave this to the lady elephants to cook new elephants. But we aim to be good at creating software.
Tackling a large story may be very puzzling. Both from our (developers) perspective and from the product manager's eyes.

How many times have you started working on such an enormous story and found out that there were a lot of holes in your complete mega-design? How many times have you been mistaken in your estimations? How many times have you found out that large portion of your code is not in use or not what the customer/product described?

It's hard for us to plan every little detail in the system ahead. There are a lot of unknowns down the road, which will be careless of us to presume we know, and will make it difficult for us to give an honest estimation. Also it's not easy for the product as well to define every little detail given all these unknowns.

Elephant carpaccio

Elephant carpaccio is a technique that helps us tackle such a big problem. Instead of trying to create an entire elephant, we can try breaking the manufacturing process to small stories. Each such story must stand on its own - meaning, provide some (some == more than 0) value to our users and be independently testable (meaning - no need to wait for other parts of the story to end in order to test it).

In an elephant carpaccio we'll try to follow a simple pattern:

1. Create a very thin flow
2. Thicken this flow by each time adding another layer or sub-feature to it.

Creating the initial flow

In order to find this main flow we better ask ourselves what is the main problem we try to solve. We can then map the main use-case. The one that solves a large portion of the problem. Then we can decide this will be the flow.

It's important to understand that this is ok to state that this flow will not stand on its own for releasing to the market. If we would to design an ATM, our main flow would probably be - withdraw money. But we can't send it to production without making sure the flow is transactional, secured, audited in the bank's books and so on. But creating the really basic flow of withdrawing money, in a very naive way (maybe even without checking if the customer has sufficient funds in his account) will already give an enormous value and a great starting point.

Thickening the flow

After we understand the initial flow we're in a much better position to split the story. In this point we need to ask ourselves some questions to understand the more smaller details by which we can split the story. I'll give example on how we do it in my next post.

Focus, Build, Increase Trust

Sometimes in the work of engineers with product we encounter a lot of trust issues (if you speak Hebrew, take 5 minutes to hear from a former colleague of mine about this in this ignite talk or read her blog-post, in English, instead). Product managers often feel they do not exactly understand where the engineering are in the process and whether things go as they wanted. The engineers are not always aligned with the vision the product managers lead to. It sometimes makes them scatter to the less important areas of the feature, the ones that are a nice-to-have (for example - having an ultra beautiful button is important in an ATM, but less important than having the functionality to withdraw money).

By working with small portions we allow product to define the priorities of the work by having the engineering focused and aligned with what's really important. The engineers, when the carpaccio is done right, know exactly what they should do now. They're (usually) not distracted because they work in a very small units of work. It also allows product to change requirements on the way because the engineering process starts with the certainties and the most important things. We can change the rest of the plan as we continue to progress.
When combining such story-splitting techniques with other agile methodologies like sprints, dailies and so on, we can create a better communication between product and engineering, improve trust and improve the productivity of the team as a whole.

My Rules of Thumb for Carppacioing

1. Split an epic to stories in such a way that each story would provide value. Any value.
   How you define value you ask? Value is defined as something that you can show to a user and (s)he would actually care and be able to give you feedback about it. (A new button that doesn't do anything yet is value; A new table in the DB is not).
2. Repeat bullet #1 for each story you created and try to split it some more until you're absolutely certain you can't or that further splitting would just increase the overhead of implementing it too much.
3. In your sprint planning split each story to very short tasks. These tasks do not need to provide user value. They can and should be very small but not too small (less than 0.5 day is probably too small) in order to not increase overhead.

For those of you who would like to deepen your understanding on the subject I would suggest  Lars Thorup's presentation on the subject which I found very interesting and concise.

Also, in my next post I'll give a more detailed example of the carpaccio method. Stay tuned...

Find me on Twitter: @AviEtzioni

More interesting posts from this blog: