Refining Large Work Items in SpecMap

This article covers one way of using SpecMap’s child items to break up large work items over multiple iterations while keeping track of the overall progress. This helps you prioritise stories, deliver key functionality to users quickly and keep track of the overall status of large work items in Azure DevOps.

Child 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:

Feature with 0 completed stories out of 6

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

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.
    Adding children from the backlog explorer
    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.

Parent item under Related Work

Adding Child Items to the Map

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

Dragging a child item to the story 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:

Empty map with 3 sprints, one release lane and 2 user activity columns

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:

Release lane showing child user stories for 2 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:

Initial story map prior to starting sprint 1

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:

Parent features prior to sprint 1

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:

Search feature after 3 stories completed in sprint 1

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!

Release lane with all tasks completed in both users stories

Changes to SpecMap’s Licensing

Change in Visual Studio Marketplace Billing for Third-Party Extensions

As of July, Microsoft no longer accepts new payments for Azure DevOps extensions published by other companies. To continue using SpecMap, you’ll need to transition to making payments directly to TechTalk Software by August 31, 2019.  

New License Model (Floating Licenses)

Due to the changes in license infrastructure, SpecMap will no longer be provided using a monthly subscription model. Instead, licensing will be on a yearly basis. The annual cost will remain unchanged.
SpecMap will be unlocked using a license key valid for a specific number of users. You will no longer be able to assign specific users to SpecMap. Instead, SpecMap will simply track the number of users who log in per day, and once the user limit has been reached, no further users will be able to access SpecMap on that day. This user counter is reset on a daily basis.

Required action

Contact us to transition your payment for SpecMap before August 31, 2019,  before the change in Visual Studio Marketplace billing for third-party extensions takes place. Please include the number of users you want to use going forward. We will then send you a payment link where you can complete payment for the coming year via credit card. Upon payment, you will receive a license key that you can use to unlock SpecMap in future.

Please make sure you contact us as soon as possible to ensure that you have a license key ready to enter once marketplace licensing is no longer available and to prevent extended downtime.

 If you have questions, please contact us or contact TechTalk support.  

About Story Maps

Story Mapping is a collaborative technique invented and popularised by Jeff Patton. Story maps are intended to foster discussion and collaboration about how to achieve a particular outcome or business impact.

Story maps provide a great basis for discussing the needs of your users, and prioritising development to deliver the biggest impact. A typical story map has a hierarchic structure involving user activities and user stories. The story maps tell stories from the user’s perspective and represents the user’s progress through the system as a series of activities.

Story mapping workshops are best held face-to-face, traditionally using sticky notes to build up the map as a team. These sticky notes – or cards – are arranged to depict the user’s typical progresses through the process from left to right; activities on the left are typically carried out before those on the right. In order for a user to achieve a goal, the user needs to perform a series of activities (browse for books, add books to the cart, enter shipping details, complete payment etc.).

By engaging directly with stakeholders, story maps help you get quick and meaningful feedback and adopt an iterative build-measure-learn approach to product development. Directly discussing stories with stakeholders helps identify key features, allowing you to slice and prioritise your product backlog to support the desired flow of user activities at an early stage, and refine it incrementally. As they grow, story maps can become quite large.

While a physical environment encourages collaboration and discussion, there are practical limitations of physical story maps: they are tied to a particular location and not suitable for archiving electronically. Quite often, photographs of the map are taken for archiving, but this means the story map is essentially frozen in time, and cannot be edited and refined.

SpecMap allows you to capture your physical story maps electronically and integrate them directly with your product backlog in TFS/VSTS, with all the advantages this brings.

Each activity can be further broken down into smaller chunks, which are the user stories themselves. For example, browsing for books may involve searching the product catalog, viewing details and reviews of the books, and viewing other recommended books related to the current product.

Once the user stories have been discussed and defined, the next step is to prioritize development to deliver the biggest impact possible over the next development cycle. User stories that relate to the same activity are prioritized vertically, with more important stories at the top and less important stories lower down. This priority applies to all activities and should take into account factors such as dependent features (e.g. you cannot add products to the shopping cart if you cannot view products), as well as the needs of end users. Items on the same vertical level are referred to as “slices”, and typically represent one development cycle or sprint. In SpecMap, slices can be linked to iterations in TFS/VSTS, allowing you to plan development once you have prioritised the individual user stories.

For more information on Story Mapping, see Jeff Patton’s site.