how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list [2016/04/30 10:08] – [Need to Know More] hpsamios | how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list [2022/04/20 13:35] (current) – Readability hans | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== How Do We Build and Maintain Context When All We Have Is a Backlog List? ====== | ====== How Do We Build and Maintain Context When All We Have Is a Backlog List? ====== | ||
| - | Or "What is User Story Mapping" | + | > Or "What is User Story Mapping" |
| + | > Or "How Do We Break Down a Big Chunk of Work" | ||
| - | ====== Premise ====== | + | A lot of people, while they like the simplicity of the approach of maintaining a backlog, feel like they lose context when they just have a list of user stories. Others cannot think in terms of lists but rather need something more pictorial to help them understand what is going on. One approach that I have seen useful in these contexts is the use of "User Story Mapping" |
| - | + | ||
| - | I lot of people, while they like the simplicity of the approach of maintaining a backlog, feel like they lose context when they just have a list of user stories. Others cannot think in terms of lists but rather need something more pictorial to help them understand what is going on. One approach that I have seen useful in these contexts is the user of "User Story Mapping" | + | |
| ====== Practice ====== | ====== Practice ====== | ||
| - | The basic idea, made popular by Jeff Patton is pretty straight-forward. It is a top-down exercise to understand the workflow. | + | The basic idea, made popular by Jeff Patton is pretty straight-forward. It is a top-down exercise to understand the workflow. The idea is to start with the activities a user / role needs to do to accomplish an objective / goal. Then detail out stories that represent the effort done by each user. Next, prioritize them into sprints (or whatever time horizon you are working toward). The activities can be based on larger features or epics coming into a planning session or perhaps are just something that needs to be elaborated. |
| - | + | ||
| - | What you end up with is a matrix with activities / stories on the horizontal axis (user does this, then does that, then does that) and priority in the vertical axis (this is the most important function to provide, this is the second, etc. Swim lanes identify potential delivery timescales. In other words, a visual workflow and plan combined in one. Here is an example for an online shopping type experience: | + | What you end up with is a matrix with activities / stories on the horizontal axis (user does this, then does that, then does that) and priority in the vertical axis (this is the most important function to provide, this is the second, etc. Swim lanes identify potential delivery timescales. In other words, a visual workflow and plan combined in one. Here is an example for an email client |
| + | |||
| + | [[https:// | ||
| + | |||
| + | In this picture you can see blue user activities, the with stories required to support that activity in yellow underneath. You can see they have said “this is what will happen in the first increment” by creating swim lanes. These time horizons can be whatever makes sense in your situation. Perhaps a sprint by sprint view, perhaps a " | ||
| - | [[http:// | ||
| - | |||
| - | In this picture you can see yellow user activities, the with stories required to support that activity in yellow underneath (in white). You can see they have said “this is what will happen in Release 1” by creating swim lanes. These time horizons can be whatever makes sense in your situation. Perhaps a sprint by sprint view, perhaps a " | ||
| - | |||
| A couple of notes: | A couple of notes: | ||
| - | + | ||
| - | * This is clearly a way to start the identification of a solution. As you discover more, the basic picture can be expected to change. If you already have business process documentation in place, feel free to leverage this (it is a “waste” not to leverage the intellect of the organization.) | + | * This is clearly a way to start the identification of a solution. As you discover more, the basic picture can be expected to change. If you already have business process documentation in place, feel free to leverage this (it is a “waste” not to leverage the intellect of the organization.) |
| * Another approach to story map is to take a bottom up approach – do a brainstorm of business activities, group into processes then map to the feature’s acceptance criteria. The approach you take will depend on your current level of knowledge. | * Another approach to story map is to take a bottom up approach – do a brainstorm of business activities, group into processes then map to the feature’s acceptance criteria. The approach you take will depend on your current level of knowledge. | ||
| * You can use this picture help others understand where you are and to maintain context. For example, you could mark on each story “done” as things are complete, and as you get feedback update / add items to the story map that you already have. | * You can use this picture help others understand where you are and to maintain context. For example, you could mark on each story “done” as things are complete, and as you get feedback update / add items to the story map that you already have. | ||
| Line 26: | Line 25: | ||
| By way of understanding, | By way of understanding, | ||
| - | + | ||
| * It helps the team to visualize all the tasks that make up something valuable to a customers, pinpointing dependencies | * It helps the team to visualize all the tasks that make up something valuable to a customers, pinpointing dependencies | ||
| * It encourages iterative development by slicing activities into smaller efforts, and is particularly good at helping to write and present these as a user's view (i.e. user stories) | * It encourages iterative development by slicing activities into smaller efforts, and is particularly good at helping to write and present these as a user's view (i.e. user stories) | ||
| Line 34: | Line 33: | ||
| * It helps the team gain more insights into the user’s journey and experience with using the solution in its overall context, increasing end user domain knowledge | * It helps the team gain more insights into the user’s journey and experience with using the solution in its overall context, increasing end user domain knowledge | ||
| * It helps the Product Owner think about and convey better the value a solution offers to the team and other stakeholders | * It helps the Product Owner think about and convey better the value a solution offers to the team and other stakeholders | ||
| - | + | ||
| ====== Need to Know More ====== | ====== Need to Know More ====== | ||
| + | * [[https:// | ||
| * [[http:// | * [[http:// | ||
| * [[http:// | * [[http:// | ||
| - | * [[how_do_we_split_user_stories|How Do We Split a User Story?]] | + | * [[:how_do_we_split_user_stories|How Do We Split a User Story]] |
| * [[https:// | * [[https:// | ||
| * [[http:// | * [[http:// | ||
| - | |||
| - | |||
| {{tag> | {{tag> | ||
| - | ~~LINKBACK~~ | + | |
| - | ~~DISCUSSION~~ | + | |
| - | + | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_do_we_build_and_maintain_context_when_all_we_have_is_a_backlog_list.1462036086.txt.gz · Last modified: 2020/06/02 14:24 (external edit)