Applying User Story Mapping in TFS: Direct Mapping and Transformation Methods

Topic

This article, inspired by Xu Lei's "Building Efficient DevOps Teams" training course, summarizes how the "User Story Mapping" method can be applied on the TFS platform.

First method: directly map system work items (epic, feature, and scenario) to the layers of a user story map (activity, task, and sub‑task). Second method: convert business requirements into technical implementation by mapping the task layer directly to system functions, as described in the "Transformation Mapping" section below.

Direct Mapping Method

The hierarchy of a user story map does not have to be three layers; it can be two or even more. TFS 2015 supports three default layers named "Epic, Feature, and Scenario" (when using the Agile template), which can be mapped one‑to‑one with a three‑layer user story map, as shown in the figure.

The layer names in TFS can be customized, for example to "Business Function, System Function, User Story" as illustrated below.

A handy tip is to open the "Mapping" view and drag‑and‑drop to establish parent‑child relationships without clicking each link individually.

Link the third‑level "User Story" to the second‑level "User Task":

Link the second‑level "User Task" to the first‑level "User Activity":

Each backlog list shows the global "User Story Map":

Transformation Mapping Method

This approach converts the original three‑layer business "User Story Map" into a two‑layer TFS "User Story Map" by defining regions, as illustrated in the following diagram created during Xu Lei's DevOps training.

To achieve the constrained goal of "doubling revenue within one month," the current iteration plans to develop only two features: "Lottery" and "National Day Promotion." Since this is an extension of an existing system with front‑end, back‑end, and homepage modules, the second layer is defined as a region, resulting in the following mapping.

Thus the "User Task" layer becomes a region, forming a two‑layer user story map that creates a deeper connection between business and technical maps.

Related Fundamentals

Introduction to "User Story Mapping"

"User Story Mapping" is an agile technique for building consensus, applicable in various ALM and agile tools such as TFS and Jira. Its core purpose is to enhance team collaboration, uncover real needs, and refine quality products.

Martin Fowler says: "Story mapping is a technique for keeping a panoramic view during requirement decomposition." Kent Beck originally introduced stories to spark communication, urging teams to treat communication as a core value. Stories are essential for developers and other roles to communicate; story maps organize these elements structurally, strengthening the most critical part of software development – communication. Alan Cooper believes "User story mapping bridges development and design." Interaction design discovers user behavior and narrates it; software development then breaks down, implements, and integrates those narratives. By using story maps, design retains its narrative structure while development can efficiently decompose work.

Building a user story map helps form an MVP (Minimum Viable Product) for rapid validation and iteration, delivering valuable products to users.

Numerous experts and agile coaches have written insightful articles on user story maps (see appendix); this article does not repeat them.

3C and 5C Principles of User Stories, and the INVEST Characteristics

Ron Jeffries' 3C

User stories are described by Ron Jeffries using three C's:

Card – The story is written on a small index card, often with a brief description and effort estimate.
Conversation – Details emerge from discussions with the customer or product owner.
Confirmation – Acceptance tests verify that the story is completed correctly.

Extended 5C Principles

Building on Jeffries' 3C, two additional C's are added:

Construction – Begin building and implementing the user story.

Consequence – The observable result after the story is implemented.

card → conversation → confirmation → construction → consequence → card … 卡片 → 交谈 → 确认 → 构建 → 结果 → 卡片 …

INVEST – Six Characteristics of a Good User Story

INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, Testable. A good user story should satisfy these criteria.

Independent – Stories should be as independent as possible to simplify planning, prioritization, and estimation.

Negotiable – Stories are not contracts; details are refined during conversation, not fixed on the card.

Valuable – Each story must deliver value to the customer; involving customers in writing stories ensures this.

Estimable – Teams need to estimate stories to set priorities and plan work; lack of domain knowledge or overly large stories hinder estimation.

Small – Stories should be small enough to be completed within a single sprint (ideally no more than 10 ideal person‑days).

Testable – Stories must be testable to confirm completion; non‑testable stories cannot be reliably finished.

Using User Stories in Agile and Kanban Processes

User story cards flow through the entire development lifecycle. Product owners write stories into the Product Backlog. During Sprint Planning, the team discusses, refines, and estimates them (e.g., using Planning Poker). Stories are broken into tasks, estimated, and moved to the Sprint Backlog.

During the sprint, tasks move from "To Do" to "Doing" to "Done" on the board. After all tasks for a story are completed, the product owner validates and accepts the story, moving it to "Done." At the end of the sprint, the team demonstrates completed stories to stakeholders, delivering business value iteratively.

Appendix

Reference articles:

User Story Mapping – First Experience

8 Steps to Create a User Story Map

Building Efficient DevOps Teams Training Course

Reference books:

"User Stories and Agile Methods"

"User Story Mapping"

Please follow the WeChat public account devopshub for more DevOps R&D integration information.