Refining large work items on the map

Story maps help you to prioritize incremental delivery of features over time to deliver key value to users quickly while keeping track of the overall scope of planned work.

SpecMap helps to translate this incremental planning and visualization into Azure DevOps by allowing to break up large work items into multiple smaller child work items and planning them over multiple iterations.

Breaking large work items into smaller work items

In SpecMap, you can add child items to cards on your story map, such as adding PBIs to features. You can track the overall completion status of the child items from the parent.

In this example, the “Search for books” feature has 6 child PBIs, none of which have yet been completed (“0/6”). As the PBIs are completed, the counter in the parent item is updated accordingly, allowing you to track the overall progress of the feature.

Adding Child Items to Cards

There are a number of ways you can add children to stories on the story map:

• Click on Add Child (only visible when no children exist) to add a child item. If only one type of child item is supported by the parent item, the name of this option includes the name of the child item type (e.g. Add User Story)
• Drag a work item onto the child area of a card (below the state), either from the map or from your backlog.

You can do this when the child area is both expanded and contracted.

If children have already been added, expand the children and click on Add (Item Type) to add more child items of the same type to the card. To add a child of a different type, you need to drag it onto the card from the backlog (or the map).

If you open up one of the child work items, you will notice that its parent has automatically been set.

Mapping Child Items

If you expand the list of child items in SpecMap, you can drag items from the list and place them on the map.

Depending on whether your columns (user activities) are linked to work items or not, the behavior when moving the card onto the story map is different:

• If user activities are linked to work items, moving a child work item onto the story map will change the item’s parent to the user activity’s work item. It will no longer be listed as a child item of the card you removed it from.
• If user activities are not linked to work items, moving a child work item onto the map will not change the item’s parent. It will continue to be listed as a child work item in the parent card, as well as be its own entry on the map. This is the case in the example above, there the child continues to be listed after being placed on the story map. You can use this to help you plan bigger stories that will take more than one iteration to complete.

Slicing Longer Stories

Big features often need several iterations to implement, and parts of the feature may depend on other stories. SpecMap offers a way of splitting up these features and helping you to plan their implementation over multiple sprints while keeping track of the overall progress of the feature.

To illustrate this, let’s look at two features relating to an online book store: one about searching for books and one about reviewing books. Both of these features should be completed before the next release, and both will take a couple of iterations to complete. Part of the search story covers searching for books based on their review rating, which requires reviews to be implemented first.

In this example, we will only link rows (slices) in the story map to iterations, while leaving the column headers unlinked (see above). We will also add a sperate row (not linked to an iteration) representing the release itself. This row is where we will place the parent stories, allowing us to monitor the overall progress towards the release at a glance.

To start off with, we define our iterations (3 in this case), and an additional row that represents a release. Each row representing an iteration is linked to an iteration in DevOps, while the release row is left unlinked:

The next step is to add the features that should be included in the release to the release lane, including all child stories required by the features:

In this case, you can see stories related to searching for books and to adding reviews. The two features are not independent, as “Search books by review rating” requires “Review out of 5” to be implemented first (you cannot search by review rating without support for review ratings).

This means that certain stories should be completed in earlier iterations than others. You can assign the stories to iterations by dragging them out of the list of child items and onto the map in the correct iteration:

As you can see, the story relating to reviews out of 5 is scheduled for iteration 2, while the story for searching for books by review rating is in iteration 3.

Because there are no work items assigned to the columns, dragging stories out of the features and placing them on the map does not change their parent:

You can now start working on the stories in iteration one, and as their state is set to completed, the completion status of the parent feature in DevOps is updated accordingly. So once all stories in sprint 1 are completed, the “Search for books” feature will look like this:

This is because 3 of the 6 stories have now been completed:

Once all DevOps features in the release lane indicate that all child stories as complete, you are ready to release!