When TechTalk started to develop SpecMap more than two years ago, our goal was to help both small and large teams improve collaboration and use Story Mapping to develop software that offers an excellent user experience.
Today we are excited to announce that SpecMap and SpecFlow have been acquired by Tricentis, a leading international software provider for software testing solutions.
For Tricentis, SpecMap offers a unique opportunity to accelerate the adoption of agile practices and Behavior-Driven development (BDD) within the enterprise market. Agile practices like BDD and User Story Mapping enable teams to deliver valuable software to end users in shorter cycles and with better results.
What does this mean for current SpecMap customers?
We are excited to announce that partnering with Tricentis will allow us to offer SpecMap licenses to you free of charge. Starting from today, SpecMap will be available for free for any number of users. As an existing customer you can continue to use your current licenses. More details will be announced soon.
If you have any further questions, you can contact us by sending a mail to support [at] specmap.cc
We look forward to partnering with Tricentis and
helping more teams from around the world collaborate!
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.
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
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.
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.
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!
https://specmap.cc/wp-content/uploads/2018/07/SM_Logo_small-n87rn7blumryl92dswiy0cwrtxtnnbba1gs3o5y7hs.png00Stephen McCaffertyhttps://specmap.cc/wp-content/uploads/2018/07/SM_Logo_small-n87rn7blumryl92dswiy0cwrtxtnnbba1gs3o5y7hs.pngStephen McCafferty2019-12-05 12:45:582019-12-09 12:37:20Refining Large Work Items in SpecMap
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.