January 14, 2016 at 12:48Breaking User Stories - Hamburger Method
I bring to your attention a translation of a short article by Goiko Adzic on the topic of the separation of user stories from 2012, with illustrations and examples by the author: " Splitting User Stories: The Hamburger Method " - made it, first of all, for myself.
Issues: The story is too long and the process of breaking up and evaluating is too complicated; business users are not satisfied with any layout option proposed by the development team; the team does not have enough experience and uses only the technical separation of stories; a new project has been launched and the team doesn’t have a chance to formulate fairly simple user stories.
Solution: Hamburger Method
Over the past few months, I have developed a new technique for splitting user stories,shamelessly stealing the revision and using the method of compiling user stories by Jeff Patton and the ideas described by Craig Larman and Bas Wodde in Lean and Agile development scaling Practices. I think that this technique works especially well in situations where a team cannot destroy the tradition of the technical separation of tasks from history. She has a visual gaming aspect, as in Innovative games, and is easy to remember. I call her User Storey Hamburger.
Inexperienced teams often cannot figure out 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 Custom Story Map, which displays the overall picture, broken down according to business processes. We can do the same at a lower level, for the tasks that make up the user story, thereby not taking the team out of its comfort zone. In this case, we break the story to determine different quality levels for each iteration and create vertical slices to determine the criteria for the released functionality. Below is how to make a hamburger.
STEP 1: Defining Tasks - Hamburger Layers
The team needs to determine 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, salad, tomatoes, cheese - you can add a little bacon for a 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: selection of inactive clients from the database; sending letters for this sample; receipt of a delivery report; removal of incorrect contacts; marking successful contacts.
STEP 2: Identify the various ways to accomplish tasks
Break the team into several small groups and ask them to determine how to implement a different level of quality for each task. Let them write down several such levels on stickers.
For example, execution speed and accuracy of results can be indicators of the quality of a sample of inactive clients from a database. In this case, there are two ways - to prepare a slow and relatively inaccurate request from the entire database, or to prepare samples based on daily transactions that do not reflect intraday changes. Another way to increase accuracy is to start a night task that assigns a sign of inactivity and delete a sign of inactivity for each completed transaction, which will allow us to achieve greater accuracy and complete 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 getting into anti-spam filters. The first option is slow and unproductive manual mailing. The second is the automatic sending of non-personalized letters with the possibility of manual unsubscribing. The third way is an auto-mail of personalized letters, but with a manual reply. Fourth - a personalized auto-unsubscribe. And another option may be integration with a third-party service, which provides all the described features.
STEP 3: Combining the results
Combine the information received in a common hamburger on the board. Let the representatives of each group paste their stickers in the right places inside the hamburger, briefly describing the options presented. Remove duplicate stickers from the board. Line up stickers from left to right based on increasing quality levels.
STEP 4: Cut the hamburger.
Walk the whole team through the options found, compare them among themselves, based on the complexity of the implementation, and note the complexity of each option on the sticker. You can group tasks by size for ease of comparison. Think about which lower-quality options you can throw out, while leaving options that are approximately equal in volume, but of higher quality.
It is also necessary to determine the maximum necessary level of quality for each task. For example, implementing the process of deleting invalid addresses in realtime will not be a much more valuable option than the nightly task of removing these addresses. Take stickers with options that exceed the maximum level of quality beyond the limits of the hamburger - this is what will remain after you “eat” the hamburger.
STEP 5: Take the first bite
Now that the hamburger is ready, decide how big a piece you are ready to bite. Decide on the minimum acceptable level of quality for each layer of a hamburger. For example, we consider manual mailing unacceptable due to low efficiency, but monthly sending may be quite acceptable. If the option with a lower level of quality is more or less close to the higher quality option in terms of implementation complexity, then you should immediately bite off a bigger piece. For example, the implementation of automatic sending of non-personalized letters with manual unsubscription will not be much more complicated than integration with MailChimp. The reverse example is that updating client activity in real time can be more time consuming than a slow request from the database on demand. And for some stages, for example, for the task of removing invalid addresses,
STEP 6: Bite off again ... and continue.
In the future, each new “bite” of a hamburger should provide higher quality - for example, even the simplest implementation of deleting invalid addresses improves the quality, as does a more frequent distribution. Always compare the difficulty of implementing possible options before deciding on the size of a “bitten” burger piece.
This method works well in the first place due to the fact that it is sufficiently visual, and this helps the team to think about alternative ways, remaining in its comfort zone. The analogy to biting a hamburger also works well. Using this method, you can quite easily explain why the implementation of an individual component in the context of history does not make sense, because usually people do not choose only a salad from a hamburger. At least while they are hungry.
Issues: The story is too long and the process of breaking up and evaluating is too complicated; business users are not satisfied with any layout option proposed by the development team; the team does not have enough experience and uses only the technical separation of stories; a new project has been launched and the team doesn’t have a chance to formulate fairly simple user stories.
Solution: Hamburger Method
Over the past few months, I have developed a new technique for splitting user stories,
Inexperienced teams often cannot figure out 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 Custom Story Map, which displays the overall picture, broken down according to business processes. We can do the same at a lower level, for the tasks that make up the user story, thereby not taking the team out of its comfort zone. In this case, we break the story to determine different quality levels for each iteration and create vertical slices to determine the criteria for the released functionality. Below is how to make a hamburger.
STEP 1: Defining Tasks - Hamburger Layers
The team needs to determine 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, salad, tomatoes, cheese - you can add a little bacon for a 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: selection of inactive clients from the database; sending letters for this sample; receipt of a delivery report; removal of incorrect contacts; marking successful contacts.
STEP 2: Identify the various ways to accomplish tasks
Break the team into several small groups and ask them to determine how to implement a different level of quality for each task. Let them write down several such levels on stickers.
For example, execution speed and accuracy of results can be indicators of the quality of a sample of inactive clients from a database. In this case, there are two ways - to prepare a slow and relatively inaccurate request from the entire database, or to prepare samples based on daily transactions that do not reflect intraday changes. Another way to increase accuracy is to start a night task that assigns a sign of inactivity and delete a sign of inactivity for each completed transaction, which will allow us to achieve greater accuracy and complete 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 getting into anti-spam filters. The first option is slow and unproductive manual mailing. The second is the automatic sending of non-personalized letters with the possibility of manual unsubscribing. The third way is an auto-mail of personalized letters, but with a manual reply. Fourth - a personalized auto-unsubscribe. And another option may be integration with a third-party service, which provides all the described features.
STEP 3: Combining the results
Combine the information received in a common hamburger on the board. Let the representatives of each group paste their stickers in the right places inside the hamburger, briefly describing the options presented. Remove duplicate stickers from the board. Line up stickers from left to right based on increasing quality levels.
STEP 4: Cut the hamburger.
Walk the whole team through the options found, compare them among themselves, based on the complexity of the implementation, and note the complexity of each option on the sticker. You can group tasks by size for ease of comparison. Think about which lower-quality options you can throw out, while leaving options that are approximately equal in volume, but of higher quality.
It is also necessary to determine the maximum necessary level of quality for each task. For example, implementing the process of deleting invalid addresses in realtime will not be a much more valuable option than the nightly task of removing these addresses. Take stickers with options that exceed the maximum level of quality beyond the limits of the hamburger - this is what will remain after you “eat” the hamburger.
STEP 5: Take the first bite
Now that the hamburger is ready, decide how big a piece you are ready to bite. Decide on the minimum acceptable level of quality for each layer of a hamburger. For example, we consider manual mailing unacceptable due to low efficiency, but monthly sending may be quite acceptable. If the option with a lower level of quality is more or less close to the higher quality option in terms of implementation complexity, then you should immediately bite off a bigger piece. For example, the implementation of automatic sending of non-personalized letters with manual unsubscription will not be much more complicated than integration with MailChimp. The reverse example is that updating client activity in real time can be more time consuming than a slow request from the database on demand. And for some stages, for example, for the task of removing invalid addresses,
STEP 6: Bite off again ... and continue.
In the future, each new “bite” of a hamburger should provide higher quality - for example, even the simplest implementation of deleting invalid addresses improves the quality, as does a more frequent distribution. Always compare the difficulty of implementing possible options before deciding on the size of a “bitten” burger piece.
This method works well in the first place due to the fact that it is sufficiently visual, and this helps the team to think about alternative ways, remaining in its comfort zone. The analogy to biting a hamburger also works well. Using this method, you can quite easily explain why the implementation of an individual component in the context of history does not make sense, because usually people do not choose only a salad from a hamburger. At least while they are hungry.