Post navigation

Splitting user stories: the hamburger method

Problems: Story is too big to split and estimate; business users don’t accept any breakdown proposed by the delivery team; team is inexperienced and thinks about technical splitting only;new project starts and no simple starting stories can be foundSolution: User Story Hamburger

I’ve evolved a new technique for splitting user stories over the last few months shamelessly stealing repurposing Jeff Patton’s User Story Mapping and ideas described by Craig Larman and Bas Vodde in Practices for Scaling Lean & Agile Development. I think it works particularly well in situations where a team cannot find a good way to break things down and is insisting on technical divisions. It has the visual playful aspect similar to innovation games and it’s easy to remember. I call it the User Story Hamburger.

Inexperienced teams often can’t get their heads around splitting stories into smaller stories that still deliver business value. But they will happily break a story down into technical workflow or component tasks. I like the idea of User Story Maps which show the big picture under a breakdown of a business workflow. We can do the same on a much lower level, for tasks making up a user story, keeping the team in their comfort zone. Then we use this breakdown to identify different levels of quality for each step, and create vertical slices to identify smaller deliverables. Here is how to create the hamburger:

Step 1: Identify tasks

As a group, identify technical steps that would be involved in implementing a story on a high level. Breaking it down into technical/component workflow is OK. The tasks become layers in a hamburger bun – meat, lettuce, tomato, cheese – throw in some bacon for fun as well.

For example, if we’re working on a story to contact dormant customers by e-mail, the steps might be: query db for dormant customers; send e-mail to customers; retrieve delivery report; remove bounced addresses from the system; mark non-bounced as ‘recently contacted’.

Step 2: Identify options for tasks

Split the team into several small groups and ask them to define quality for each task, or what would make a particular task good. Then they should write down several options on different levels of quality on post-it notes.

For example, speed of execution and accuracy of results might be a measure of quality for database query for dormant customers. Two possible options could be to make a slow and relatively inaccurate query on all customers compared with overnight transaction reports, which won’t pick up intraday changes. Another option to increase accuracy would be to have a nightly job making customers dormant and remove the dormant mark on every transaction, which would enable us to be 100% accurate and faster. The first option would work only if we send e-mails once a month, the second would work at any time.

Another example might be the volume we can send, the content personalisation and spam-regulation compliance for sending e-mail. We have an option of sending things manually, slow and low-volume. Second option is to use an automated process and send generic e-mails, with a manual unsubscribe process. A third option would be to use an automated process and send personalised e-mails, with manual unsubscribing. The fourth option would be to send personalised e-mail automatically and enable people to unsubscribe automatically. Yet another option would be integrating with a third party service that does all that.

Step 3: Combine results

Create a single hamburger on a big board. Ask representatives from each team to bring post-it notes and fill in the layers of your hamburger, briefly introducing what each note it. Identify duplicates and throw them away. Align task options from left to right based on the level of quality.

Step 4: Trim the hamburger

As a group, go through tasks and compare the lowest quality options with things next to them, based on how difficult it would roughly be to implement each option. Mark that information on the post-its. It might be worth breaking things down into relatively same-size technical tasks to do some simple comparisons. Think about throwing away lower quality items that would take more or less the same to implement as a higher quality option.

Also decide what is the maximum needed level of quality for each task. For example, intra-day bounced e-mail removal won’t really bring much more value than overnight bounced e-mail removal. Take items over the line out – that’s what will be left in the box after you eat the hamburger.

Step 5: Take the first bite

Now that you have a hamburger, decide how deep you’ll take the first bite. Discuss what is the minimum acceptable level of quality for each step. For example, manual sending might not be acceptable at all, because of the low volume. But sending e-mail once a month might be acceptable. If the lowest quality option is more-less the same size as the higher quality one, you might go deeper straight away. For example, sending generic e-mail with manual unsubscribing might be more or less the same effort as integrating with Mailchimp. On the other hand, a fast realtime update of customer activity might be much more difficult than a on-demand slow database query. For some steps, eg removing bounced addresses, doing nothing might be a valid level of quality initially.

Step 6: Take another bite… and continue

From there on, any further bite should provide more quality, regardless of what you add. Eg implementing initial bounced e-mail removal enhances the quality. So does more frequent e-mail sending. Use complexity comparisons between tasks to decide how deep you want to take further bites.

This method works very nicely because it is visual, and it gets people thinking about alternatives while still staying in their comfort zone. It also works nicely with ‘bite-size chunks’ analogies. And you can easily explain why releasing just a technical task doesn’t make sense because no sane person would eat only the lettuce. On a final note, make sure not to do this while people are hungry.

This is pretty much what our team does, though we don’t use a hamburger. We identify some thin slice or steel thread, we usually try to pick a high-risk one first because we aren’t sure how long it will take. Once we have done that, the others are easier to estimate and do. I love this metaphor!

Also, on my team, we aren’t slaves to the idea that a user story has to deliver biz value. Sometimes, the first thing we need to do in the existing code base is something such as break an existing 1 to 1 relationship that now needs to be 1 to many. So breaking the relationship is the first story we do – no direct biz value there, but a necessary prerequisite to subsequent stories.

Dhinesh – I believe this approach can still deliver 100% quality by explaining the difference between subjective and objective quality as I have been taught by Jeff Patton. The functionality in the example is sliced by subjective quality instead of objective quality. The solution gets better over time (improving subjective quality) but each user story is still delivered ‘perfectly’ (100% objective quality at all times).

In this example the Overnight Transaction Report, Autosend Personalized Email, and Text Import all work perfectly in the first delivery. This enables the team to validate that they are solving the problem correctly and allows the business to start solving the problem earlier. The next user stories improve upon the solution by improving the subjective quality – making it easier to for the business to solve the problem.

Thank you for another great wrote up gojko!
I’ve been using this approach implicitly in tough cases but this is a very nice explicit exercise I will probably use as early as tomorrow.

As you say it is a great “training wheels” exercise. My experience is this takes quite long per feature, and once you identify good slices the team should learn to identify those slices more quickly without diving into tasks. So we should make it clear this is a beginners tool as well as a secret weapon for real tough cases

Again, very useful thanks!
And I have the appetite for a cheeseburger now…

I like the approach though I think using the word “quality” is improper. For example, consider bounced emails. An option to automatically remove these addresses from the distribution list is a feature enhancement not a quality improvement in my view.

Referring to such items as quality issues will antagonize some business stakeholders. Think in terms of epics and associated stories. Building out more stories within an epic doesn’t improve the quality of the epic. They improve the functionality of the epic, making it full featured.

It may be a bit of a semantic debate but some people get horribly hung up on established keywords. “Quality” is a big potential hang-up.

Interesting analogy. Ive seen similar ones that used an analogy to pizza with topings and slices, and another that used a “sandwich” analagy with various condiments (like your hamburger) as well as slices,

They both stemmed from a much more boring analogy that used slices, scenarios, and steps.

If a story seems too big, then we try to see if we can envision multiple “slices” thru the system for it. These might be multiple perspectives (from different personas as the instigator), or different “modes” (e.g., normal “mode” versus other possible modes like safety, disaster, failure, recovery), etc.

If we can split-up into such slices (and even if we cant) next we look for scenarios or “threads”) for that story, I suppose similar to possible different/alternate paths of a use-case.

Once we’ve exhausted that, if something still seems to big, then we look for significant “steps” within a scenario or “slice”. Since we regard a “slice” as a vertical slice thru the system, we tend to use the term “step” instead of horizontal slice (but it could be called a horizontal slice).

Sometimes we’d use the term “slice and dice” if we ended-up mixing and matching slices/scenarios with “steps”.

While this is an interesting way to present the idea of thin vertical slice, and sure I can see the appeal in using burger as a metaphor, with a variety of ingredients being an analogy for tasks. The real challenge is that burgers aren’t cooked in a thin vertical slice. While no doubt they are consumed as vertical slices they are build up in layers – horizontal layers to be precise.

How about slider style mini burgers – does the trick, so just postulate the same as 6 sliders, with each slider having no more then one vertical stack of tasks.

So when is the hamburger really “done” – what’s the done definition for this story ? Does the user make an entry at any point until the entire hamburger is done? Do you demo interim bites and let the customer decide on acceptable quality ?

Really nice metaphor. I have been talking about “slicing the cheese/cake in another direction”, and I have also been talking about sandwich-eating. Howver, “hamburger” strikes a much stronger association. Nice one.

I really like the approach of splitting one user story into many different and then deciding on what implementation to develop considering effort and complexity vs. business value.

However, wouldn’t it be smarter to simply split all of them into single user stories and group them as a feature. My point being that in a lean and agile environment you wouldn’t have to wait for every single of the steps being implemented in any shape or form, you could just go and deploy step by step. And reaccess the results as you go along…

You actually suggest something similar by leaving out certain steps, however the user story as a whole does not get finished… Which might be a motivational drawback to the team, don’t you think?

algorithm steps are internal design decisions and could in theory be changed and are primarily of interest to the dev team. scenario steps are probably visible to actors/users (at least, during a requirements discussion), and are of interest to them; they may be automated, or involve the actor interacting with the system for the step.

think it is noteworthy to identify these 2 different kinds of steps, because it may lead to organizing, generalizing, or refactoring the steps, or talking about the steps, in different and useful ways.

btw, observe that splitting by algorithm or scenario *steps* is *the* most common default approach of developers when they are first introduced to splitting, because of their conditioning. an alternative to reinforcing their default mindset (which the hamburger method tends to reinforce) is to address the root-cause issue: a lack of education/knowledge/examples of different ways of splitting. so, when i work with teams, rather than go down the hamburger path — clever/useful as it is — am more apt to coach them (and show them) the myriad “vertical” end-2-end ways of splitting that avoid reverting to their too-comfortable step-splitting habit, to address the root cause education/behavior-change issue head on.

I like the article and I think all the comments are good as well. Yet, it seems to me all these ideas address a symptom of an underlying problem – the customer in this scenario does not understand how incremental delivery works and probably does not understand the value or the mechanisms of feedback.

The customer may be assuming that the first solution he sees will be the only solution the team ever delivers. That is the real problem, and not merely how to construct the hamburger for today’s “lunch.”

This isn’t obvious to many practitioners, either. One of the commenters, Andrej, appears to miss this point when he writes, “…the user story as a whole does not get finished.” Another, Gishu, asks “when is the hamburger really ‘done’?” They are looking at the immediate result of the first “bite,” and not at the big picture. Have they experienced incremental delivery? Can they visualize the process? If not, then how much more challenging will the concept be for business stakeholders who have not worked in an incremental fashion before?

Hamburgers and pizza might seem less “boring” or more “fun” than talking about slices and so forth, but it’s like a bandage designed for children – the cartoon characters on the bandage make the children smile through their pain, but it’s a bandage nonetheless, and not a cure. After a while, bleeding stops being fun, no matter how cheerful one’s bandage may be.

If we don’t get the customer on board with incremental delivery and feedback, we’ll be drawing a lot of pictures of hamburgers. The 100th hamburger will not be as much “fun” as the first. I can just imagine the frustrated customer’s reaction when we start to draw that 100th hamburger bun.

Your point about the ultimate problem being the customer doesn’t understand or value fast feedback is very good.
What Godjo provides here though remains valuable for the technical team to help business owners break down a user story when they can’t see how to split the story into valuable chunks.
I’ve seen this multiple times. Technical people need some training/guidance for this in order to avoid a “deadlock” situation when business people wait for technical people for help, and technical people are waiting for business people to do the same…….

The first hamburger delivered doesn’t actually deliver a hamburger, as some of the functionality (no delivery report or bounce removal) isn’t implemented (in other words, my cheeseburger has no cheese or relish).

What you have illustrated, in an interesting (and slightly deceptive) visual way is how to remove scope.

I agree with some of the other comments that it may be fun once, but it doesn’t address the underlying issues. Spending just a little time working with the customer to create a better user story may have been easier (at least for your example) and I suspect could have lead to two distinct user stories, one for sending the mails and another for handling bounced mails, which if implemented separately may even lead to a different architecture/design.

I don’t think it would take 100 hamburgers for the business to get bored, and the techies to get frustrated, because I suspect that the hamburgers may never get finished (business users like to change their minds/direction in my experience).

Awesome! This is much better than sashimi slices or Peking duck as the hamburger metaphor brings in the heterogenous bits of verticale architecture components. Tomatoe, pickles, lettuce, onions really are very different for the hamburger. Very good!