Who to Split User Stories 101
Hamburger technique to Split User Stories from Development team perspective
Learn how to use the Hamburger technique in Agile: step by step with real life examples
The main reason why I use the Hamburger technique as a excellent method to split user stories is to coach the teams to transit from the waterfall way to approach work. I usually hear “we must do all the development, we cannot split it in half, it is not possible, it doesn’t work..” and then I stop listening.
I use the HAMBURGER technique of splitting user stories when from the Product Owner perspective, the story cannot be broken anymore, or when we are dealing with a technical story.
What I love in using the hamburger method of splitting user stories, is that I talk the team language and we understand each other. In consequence, the process goes quickly and sweetly.
The hamburger method of splitting user stories consists in making the list of all the tasks and alternative scenarios that the team must do to complete the user story. Then we order them in the order of value for the end-user and take sound bites from it until we “eat” the entire hamburger.
Why do we want to split user stories using the Hamburger technique:
- Smaller stories allow the team to fail early,
- Smaller stories enable the team to fail fast,
- Smaller stories enable the team to learn quick (both technically and user experience)
- Smaller stories make space to innovation
- Smaller stories pass more quickly through the workflow
- Smaller stories have more certainty and clarity
- Smaller stories make the team faster!
- Smaller stories boost the return of investment
I recommend stories of a maximum of 5–8 story points. More than that it brings a lot of unclarity, risk, and pressure to the team.
I’ll use the CooLab project to exemplify this method and how I use it. CooLab aims to connect passionate cooks with people who value time with their families and cooking. The representative cook persona is Oscar. You can read here more about Oscar in the article How and why the personas must be the starting point of our user stories to build better products.
Let’s take an example of hard to split the user story from the CooLab project.
As a Cook (Oscar), I want to upload a new receipt to the platform so that my followers can prepare a special meal for the summer vacation.
The user story was split as much as possible, but besides that, it is still massive.
Step 1: Identify your hamburger layers: bread, steak, onion, lettuce, cheese, bread.
- Query the database
- Input screen
- Data processing
- Email notifications
- Push notifications
Step 2: Identify alternative scenarios for each layer defined above.
- Query the database: You can query the database in Batch or Live.
— Use Batch Query to get all the data every night about all the recipes loaded during the day.
— Create an interface that will do a Live Query to display the recipe just added. It makes it available to Oscar’s followers exactly when he loads it - Input screen
— One option will be to create a user interface to insert all the fields related to a recipe. However, when Oscar wants to charge multiple recipes at a time, this might be very time-consuming.
— A bulk upload will allow Oscar to upload numerous recipes at the same time. - Data processing
— Save to database operation will send the data to the respective databases without doing any formatting or processing.
— Optimize data. For images for example will be imperial that an optimization function is implemented, so they don’t load the application. - Email notifications
— Send Manual email will allow Oscar to send a personalized email to specific followers saying about the new recipes. It is perfect for a low volume of emails.
— Automatic Send of Notifications sends an email to all Oscar followers every time he uploads a new recipe.
— Automatic Send of Personalised notification. Oscar can personalize the emails that he sends, but the email is sent out based on the system configurations, not on Oscar’s command - Push notifications
— Simple push notifications when the users are informed about the new recipes being available
— Actionable push notifications when the users can act without launching the application: e.g. add to favorite recipes, add a comment.
Step 3: Remove the duplicates, unnecessary tasks, combine the tasks if needed. In the example of CooLab, we do not need the import task as the functions will be covered through a Bulk upload. Also, at this stage, there is no need for importing recipes from other formats.
Step 4: Sort the tasks based on the business value for the final user.
- Query the database: You can query the database in Batch or Live.
— Live Query makes the recipes available to the users as soon as Oscar loads them. However, due to the significant amount of data, it is prolonged to access it, and it doesn’t appear in searches. CooLab doesn’t have many users yet. At this stage, it is essential to build the momentum and the community around the recipes. In effect, making the recipe available quick, even if it is slow brings more benefits for the users.
— Batch Query is running every night to make available all the recipes loaded during the day. It makes the application to be quick and the searches to be accurate. - Input screen
— Graphical Interface — Standardising the recipes information is very important as it keeps the recipes easy to read, to search. It is one of the characteristics of the application that the users appreciate the most on the application.
— A bulk upload will encourage the cooks to share more recipes as it will be quicker. - Data processing
— Save to database without any data processing gives access to the recipes without any delays. It is the goal of the application.
— Optimize data. While not a priority, all the data stored in the application must be optimized for speed and space optimization. - Email notifications
— Automatic Send of Notifications will provide the highest value to the users at first because that is how the users will be encouraged to use the application, return to it, get to know Oscar, and his recipes.
— Automatic Send of Personalised notification. A passionate cook wants to share that with his fans. It will boost the community of users and will allow Oscar to share recommendations for the recipes and other bits of advice.
— Send Manual function will be used more when the community there will be a community of users, so will be the last on the list of priorities. - Push notifications
— Simple push notifications bring value to the users because they are informed quickly about new recipes.
— Actionable push notifications will be more used when there is already a community built; it comes last in the order of priorities.
Step 5: Take the first bite. Select which tasks can be part of the first bite. Sometimes it can have several tasks from a layer or none from a layer. It is really like a hamburger. You might have bites with no tomatoes, which is perfectly fine.
The bite will be the first user story to implement.
Step 6: Take one bite at a time. Similar to the first bite, you’ll continue the process of defining the bites (user stories) based on the team recommendation.
In the beginning, I was doing this exercise only for tremendous stories with much uncertainty. It can be very time consuming initially. There are many tasks to think about and to plan for only one story. Nowadays, I use it to any extent when it seems hard to break a user story, especially for technical stories. From my experience, the significant advantage of the Hamburger method of splitting user stories is that it works as a mindset transformation exercise. With practice, the team and the PO start to decompose the technical complexity into smaller iterative deliverables which provide value to the users. What is your experience with the Hamburger method?
My top selected articles recommendation:
