Story Mapping - Revision history

Mmusij: /* Slice for Releases */

2021-06-15T23:57:47Z

Slice for Releases

← Older revision		Revision as of 23:57, 15 June 2021
Line 23:		Line 23:

	==Slice for Releases==		==Slice for Releases==
	Once a story map has enough information on it to roughly describe the intentions then try to slice it horizontally into releases or milestones. A good way to do this is to use tape or ribbon as a horizontal line through the story map with items above the line in the current release, and those below the line in the next release. Additionally, goals for the release can be placed at one side of the story map to give a reference for the horizontal release slice.		Once a story map has enough information on it to roughly describe the intentions then try to slice it horizontally into iterative releases or milestones. A good way to do this is to use tape or ribbon as a horizontal line through the story map with items above the line in the current release, and those below the line in the next release. Additionally, goals for the release can be placed at one side of the story map to give a reference for the horizontal release slice.

	Items that may not make it to the releases can be placed under the release slices.		Items that may not make it to the releases can be placed under the release slices.

Mmusij: /* Activities, Details, Backbones and Ribs */

2021-06-15T23:56:35Z

Activities, Details, Backbones and Ribs

← Older revision		Revision as of 23:56, 15 June 2021
Line 10:		Line 10:
	===Activities, Details, Backbones and Ribs===		===Activities, Details, Backbones and Ribs===
	Start by telling a high level story of how the different groups of people will interact with the end product. Note them down with a few words on cards and sticky notes and begin to place them on the floor or on the wall in order, and these become the activities or backbone of the story map that show a user journey of how the end product is intended to be used.		Start by telling a high level story of how the different groups of people will interact with the end product. Note them down with a few words on cards and sticky notes and begin to place them on the floor or on the wall in order, and these become the activities or backbone of the story map that show a user journey of how the end product is intended to be used.

	(User stories were always intended to be conversation reminders rather than an exhaustive replacement for requirements. The name user story is to remind us about how they are used, not how they are written.)		(User stories were always intended to be conversation reminders rather than an exhaustive replacement for requirements. The name user story is to remind us about how they are used, not how they are written.)

	As you continue the narrative to elaborate the story further, there may be higher level activities in the map as a higher level of abstraction that can take the form of headers or diagrams etc. to show the parent context, or lower level details to the story that form the detailed steps needed to achieve the activities, which begin to emerge. The "laddering up" and "laddering down" approach as the conversation continues can be useful to begin to fill out the story map with the activities or "backbone" arranged horizontally, and elaborating the detailed steps to achieve them, arranged vertically to form the "ribs".		As you continue the narrative to elaborate the story further, there may be higher level activities in the map as a higher level of abstraction that can take the form of headers or diagrams etc. to show the parent context, or lower level details to the story that form the detailed steps needed to achieve the activities, which begin to emerge. The "laddering up" and "laddering down" approach as the conversation continues can be useful to begin to fill out the story map with the activities or "backbone" arranged horizontally, and elaborating the detailed steps to achieve them, arranged vertically to form the "ribs".

			====Outcomes====
	The outcomes of a story map can be either a workflow, user experience journey or a system interaction for example. A story map can be enhanced with diagrams as the backbone of the story map to show the high level interactions either as a workflow, user experience or an architecture or system diagram for example that provides a wider context and allows the team to orientate themselves and the work for the initiative.		The outcomes of a story map can be either a workflow, user experience journey or a system interaction for example. A story map can be enhanced with diagrams as the backbone of the story map to show the high level interactions either as a workflow, user experience or an architecture or system diagram for example that provides a wider context and allows the team to orientate themselves and the work for the initiative.

Mmusij at 01:31, 20 December 2018

2018-12-20T01:31:58Z

← Older revision		Revision as of 01:31, 20 December 2018
Line 1:		Line 1:
	[[Category:Agile:Articles]][[Category:Agile]]		[[Category:Agile:Articles]][[Category:Agile]]

	Story mapping is a useful approach when strategic choices are needed in a [[Scrum Artefacts\|Product Backlog]] or similar, and works by providing a highly visible grid like representation of the product features and their decomposition into items such as ~~user stories~~.		Story mapping is a useful approach when strategic choices are needed in a [[Scrum Artefacts\|Product Backlog]] or similar, and works by providing a highly visible grid like representation of the product features and their decomposition into items such as [[User Stories]].

	The approach helps [[Product Owner]]s to make good decisions with respect to the feedback about which combination of features or options of features will provide the best outcome and the greatest impact within the time and cost available.		The approach helps [[Product Owner]]s to make good decisions with respect to the feedback about which combination of features or options of features will provide the best outcome and the greatest impact within the time and cost available.

Mmusij at 06:29, 28 November 2018

2018-11-28T06:29:22Z

← Older revision		Revision as of 06:29, 28 November 2018
Line 60:		Line 60:
	* [[Backlog Strategy Archetypes]]		* [[Backlog Strategy Archetypes]]
	* [[Product Owner]]		* [[Product Owner]]

			==References==
			# User Story Mapping, Patton J, 2014

Mmusij: /* See Also */

2018-11-28T05:06:46Z

Mmusij: /* See Also */

2018-11-28T05:03:16Z

Mmusij at 05:02, 28 November 2018

2018-11-28T05:02:29Z

← Older revision		Revision as of 05:02, 28 November 2018
Line 1:		Line 1:
	[[Category:Agile:~~Illustrations~~]][[Category:Agile]]		[[Category:Agile:Articles]][[Category:Agile]]
	[[File:Story_Mapping.jpg\|~~700px~~\|Scaling Scrum]]
			Story mapping is a useful approach when strategic choices are needed in a [[Scrum Artefacts\|Product Backlog]] or similar, and works by providing a highly visible grid like representation of the product features and their decomposition into items such as user stories.

			The approach helps [[Product Owner]]s to make good decisions with respect to the feedback about which combination of features or options of features will provide the best outcome and the greatest impact within the time and cost available.

			[[File:Story_Mapping.jpg\|500px\|Scaling Scrum]]

			==Building a Story Map==
			===Activities, Details, Backbones and Ribs===
			Start by telling a high level story of how the different groups of people will interact with the end product. Note them down with a few words on cards and sticky notes and begin to place them on the floor or on the wall in order, and these become the activities or backbone of the story map that show a user journey of how the end product is intended to be used.
			(User stories were always intended to be conversation reminders rather than an exhaustive replacement for requirements. The name user story is to remind us about how they are used, not how they are written.)

			As you continue the narrative to elaborate the story further, there may be higher level activities in the map as a higher level of abstraction that can take the form of headers or diagrams etc. to show the parent context, or lower level details to the story that form the detailed steps needed to achieve the activities, which begin to emerge. The "laddering up" and "laddering down" approach as the conversation continues can be useful to begin to fill out the story map with the activities or "backbone" arranged horizontally, and elaborating the detailed steps to achieve them, arranged vertically to form the "ribs".

			The outcomes of a story map can be either a workflow, user experience journey or a system interaction for example. A story map can be enhanced with diagrams as the backbone of the story map to show the high level interactions either as a workflow, user experience or an architecture or system diagram for example that provides a wider context and allows the team to orientate themselves and the work for the initiative.

			Other elements that may be useful are cards representing the goals of the project or initiative, the groups of people who might interact with the end product and cards describing any guiding principles or ideas for the work.

			Good story maps use diagrams and drawings and allow some creativity to creep into the work. I once worked with a team that used a series of photos to indicate the user story's meaning and intention.

			==Slice for Releases==
			Once a story map has enough information on it to roughly describe the intentions then try to slice it horizontally into releases or milestones. A good way to do this is to use tape or ribbon as a horizontal line through the story map with items above the line in the current release, and those below the line in the next release. Additionally, goals for the release can be placed at one side of the story map to give a reference for the horizontal release slice.

			Items that may not make it to the releases can be placed under the release slices.

			==Slice for Learning==
			In addition to releases, it is also good to think about how to add horizontal slices in the story map for learning to provide answers to questions, neutralise risk or determine the way forwards. These slices are more strategic in nature when compared to the progress of releases, but can really help to influence the success of a project or product.

			===Tracer Bullet or Steel Thread===
			Arranging the very first release in a way to provide a very quick and basic end to end prototype can provide more insights into how things are going to work overall. These early releases are termed as "steel threads" or "tracer bullets" that form a backbone for the product that can then be built upon with successive releases. (Typically steel threads have the absolute minimum to provide the end to end connectivity, which may be simple request response interactions just to prove that a connection has been made ok.) This can be very useful too neutralise integration risk right from the start if there are a number of interconnecting systems and dependencies, or if early user feedback is needed to provide a basic prototype to understand if the concept is going to work or not.

			The learning obtained from these quick prototypes can be invaluable at the start of a project and can positively influence the remainder of the work to be done whilst there is still time.

			===Iterative or Incremental===
			A release strategy can take the default approach of incrementally delivering features or user stories in a sequential order. An alternative is to take an iterative approach to deliver the rough first cut of the product, and then deliver subsequently improving iterations thereafter. The latter approach has the benefit of feedback early and often and is great to figure out how the product is going to work or hang together. The incremental approach is also good for small things that are well known, and so a composite strategy of incorporating horizontal iterations across the story map with vertical increments of known items that can be just dropped into a release can provide a dynamic and evolving strategy for the product delivery.

			This approach can be great for uncovering the unknowns in a project and allow feedback and adjustment to be made.

			==Slice for Delivery==
			Once the story map has been sliced for releases with a learning approach applied, there should be a number of items that are not being worked on and a number of items still left in the release. Now is the time to now break these items down into the Minimum Viable Product (MVP) to form the absolute minimum to provide a product that is still viable. The intention here is to deliver something quickly to market with less work in order to gain some customer feedback or enable a revenue stream to pay for future features for example.
			Horizontal slices may now indicate goals, initiatives or iterations within the releases, and begins to form a detailed release plan or delivery road map.

			==Tags==
			A good idea is to tag stories or items with sticky notes, stickers, or coloured marks so that they can be easily categorised in a highly visible way that shows at a glance which items share the same tags. Tags can also be used to add temporary information, notes or questions for example.

			Dots, coloured marks, stickers and coloured cards can be used to indicate different tags of things such as sub contexts, dependencies, exciters, "cheap" items, "expensive" options, needs more UX, gnarly brain problem or done items for example. Let your imagination go free.

			==Maintenance==
			When working with story maps it is a good idea to copy the cards from the story map and place them on team boards rather than take the story map card itself. This preserves the integrity of the story map and can be helpful if stories that are in the current iteration are tagged as "in progress".

			When cards are done, simply tag them as done in a visible way on the story map rather than to remove them from the map, as this will show which work is done and provides a sense of progress.

			Encouraging the product owner to constantly adjust and curate the story map is a good idea, as the story map is kept fresh and helps to stimulate further thoughts about the product from the product owner, rather than being a static list of cards that eventually fall off the wall. A little and often adjustment by the product owner is very useful to keep the story map alive and relevant.

			==See Also==
			* [[Sprint Planning & Product Backlog Refinement]]
			* [[Product Backlog Refinement]]
			* [[Backlog Strategy]]

Mmusij: Created page with "Category:Agile:IllustrationsCategory:Agile Scaling Scrum"

2018-11-18T03:42:44Z

Created page with "Category:Agile:Illustrations Category:Agile 700px|Scaling Scrum"

New page

[[Category:Agile:Illustrations]][[Category:Agile]]
[[File:Story_Mapping.jpg|700px|Scaling Scrum]]

← Older revision		Revision as of 05:06, 28 November 2018
Line 59:		Line 59:
	* [[Backlog Strategy]]		* [[Backlog Strategy]]
	* [[Backlog Strategy Archetypes]]		* [[Backlog Strategy Archetypes]]
			* [[Product Owner]]

← Older revision		Revision as of 05:03, 28 November 2018
Line 58:		Line 58:
	* [[Product Backlog Refinement]]		* [[Product Backlog Refinement]]
	* [[Backlog Strategy]]		* [[Backlog Strategy]]
			* [[Backlog Strategy Archetypes]]