User story splitting - hamburger method

I bring to your attention the translation of a small article by Gojko Ajic on the topic of sharing user stories from 2012, with illustrations and examples of the author: " Splitting User Stories: The Hamburger Method " - made it, first of all, for myself.

Problems: The story is too big and the process of splitting and evaluating is too complicated; business users are not satisfied with any version of the breakdown proposed by the development team; the team does not have enough experience and uses only technical division of stories; A new project has been launched and the team does not have to formulate fairly simple user stories.

Solution: Hamburger Method
')


Over the past few months, I have developed a new technique for breaking user stories, shamelessly stealing by revising and using Jeff Patton's user story compilation method and the ideas described by Craig Larman and Bass Vodde in Lean and Agile Scaling Practices. I think that this technique works especially well in situations where a team cannot destroy the tradition of technical division of tasks into stories. She has a visual game aspect, as in Innovative games, and it's easy to remember. I call her User Story-Hamburger.

Inexperienced teams often cannot understand how to break user stories while maintaining business value, and instead stubbornly break stories into technical tasks and components. I like the idea of ​​a User History Map, which displays the big picture, broken down according to business processes. We can do the same at a lower level, for tasks that make up a user story, thereby not taking the team out of its comfort zone. In this case, we split the history to determine the different quality levels for each iteration and create vertical sections to determine the criteria for the output functional. Below is about how to make a hamburger.

STEP 1: Definition of tasks - hamburger layers



The team needs to identify the technical stages of the upper level that will be present in the implementation of the story. At this stage, splitting into technical tasks or components is normal. Such tasks become layers in a hamburger - meat, lettuce, tomatoes, cheese - you can add a little bacon for better taste.

For example, if we are working on a story, the meaning of which is to establish communication with inactive clients by e-mail, then the steps may be as follows: sampling inactive clients from the database; sending letters on this sample; receipt of a delivery report; remove invalid contacts; marking successful contacts.

STEP 2: Identify different ways to accomplish tasks

Split the team into several small groups and ask them to determine how to implement different levels of quality for each task. Let them write on the stickers of several such levels.

For example, the execution speed and accuracy of the results can be indicators of the quality of a sample of inactive clients from the database. In this case, there are two ways - prepare a slow and relatively inaccurate request from the entire database, or prepare samples based on daily transactions that do not reflect intraday changes. Another way to increase accuracy is to launch a night task assigning a sign of inactivity, and remove a sign of inactivity for each completed transaction, which will allow us to achieve greater accuracy and perform the task faster. The first option will work only in the case of monthly sending letters, the second option is suitable without restrictions.

Another example is the volume of mail sent, personalization of content and protection against entering anti-spam filters. The first option is slow and unproductive manual mailing. The second is automatic sending of non-personalized letters with the possibility of manual unsubscribing. The third way is to auto-link personalized letters, but with manual unsubscribe. The fourth is a personalized auto-link with auto-post. And another option can be integration with a third-party service, which provides all the described features.

STEP 3: Merge Results



Combine the information received into a common hamburger on the board. Let the representatives of each group stick their stickers to the right places inside the hamburger, briefly describing the options presented. Remove duplicate stickers from the board. Line up the stickers from left to right, based on the increasing quality level.

STEP 4: Cut the hamburger



Go through the whole team on the found options, compare them with each other, based on the complexity of the implementation, and note the complexity of each option on the sticker. You can group tasks by size for easy comparison. Think about which options of lower quality can be thrown out, while leaving options that are approximately equal in volume but of superior quality.

It is also necessary to determine the maximum level of quality for each task. For example, the implementation of the process of deleting incorrect addresses in realtime will not be a much more valuable option than the nightly task of deleting these addresses. Take out stickers with options that exceed the maximum level of quality, beyond the limits of a hamburger - this is what will remain after you "eat" a hamburger.

STEP 5: Take the first bite



Now that the hamburger is ready, decide how big the piece you are ready to bite off. Decide on the minimum acceptable level of quality for each layer of the hamburger. For example, we will consider manual mailing unacceptable due to low efficiency, but monthly dispatch may be quite acceptable. If the option with a lower quality level is more or less close to the top quality option in terms of complexity of implementation, then you should bite off a bigger piece at once. For example, the implementation of auto-linking non-personalized letters with manual unsubscribing will not be much more complicated than integration with MailChimp. A reverse example — updating real-time client activity may be more time consuming than a slow request from the base on demand. And for some stages, for example, for the task of deleting incorrect addresses, the lack of implementation may already be the minimum requirement.

STEP 6: Take another bite ... and continue

In the future, each new "bite" of a hamburger should provide a higher quality - for example, even the simplest implementation of removing incorrect addresses improves the quality, as well as more frequent sending. Always compare the complexity of the implementation of possible options before you determine the value of the "bitten off" piece of hamburger.

This method works well, primarily due to the fact that it is quite visual, and it helps the team to think about alternative ways, while remaining in their comfort zone. The analogy with “biting” a hamburger also works well. Using this method, you can fairly easily explain why the implementation of a separate component within the framework of the story does not make sense, because usually people do not choose a salad from a hamburger. At least as long as they are hungry.