Using User Stories to Build a Product Backlog and Manage Agile Development with TFS

This is the first article of the series that introduced how to use user stories to help a team create requirements; in this piece we examine how to turn those user stories and feature points into a product backlog.

A product backlog is the agile tool for managing a list of requirements, prioritizing them, forming iteration plans, and organizing development, testing, and delivery; it is the core around which all activities and deliverables revolve, and it must be continuously tracked to ensure timely, quality delivery and timely adjustments.

From this point we need electronic tools to manage the development process. Most teams already use some electronic tool—often Office software like Word/Excel/Project, or dedicated tools such as Jira, Redmine, Bugzilla. Software development management must cover: 1) requirements/tasks/test cases/bugs, 2) source code, 3) various plans (iteration, release, test), 4) artifacts (JAR, WAR, NuGet, NPM, installers, delivery packages), 5) people/teams. Therefore a software development management system should provide at least: work‑item tracking, planning and tracking, personnel (including permission) management, source‑code management, and automation engine.

Many agile coaches are hesitant about electronic tools, fearing they reduce team participation and flexibility. I agree that during creative phases, physical boards foster brainstorming and involvement, and electronic tools can feel restrictive.

Nevertheless, electronic tools are indispensable for continuous tracking, data analysis, and distributed teams; they become essential when physical boards cannot serve, and the complexity of software development makes manual management impractical.

While leading my team with a user‑story map, the growing number of stories caused the team to lose the connection between stories and feature points, with features getting buried across modules and stories fading away. This warning sign prompted me to require the adoption of electronic tools.

Sample Application

To illustrate the process, I use the book "The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win" as background and create a sample application called PartsUnlimited with a set of user stories.

The Phoenix Project tells the story of an IT manager who, with the help of a board member and his "three‑step work method," saves a long‑standing automotive parts manufacturer. The novel reveals commonalities between managing modern IT organizations and traditional factories, helping readers understand IT management and view their work environment from a fresh perspective. For more information, see the DevOps overview article. You can purchase the Chinese edition of the book at the provided link.

The sample application can be accessed at the following address:

http://pucd.chinacloudsites.cn/

This is a simple e‑commerce prototype with product listings, a shopping cart, admin management, promotions, and order processing. Feel free to browse the site to get a quick sense of its functionality.

User Story List

Below are the stories I organized using an impact map and a user‑story map; each picture shows the impact map on the left (one story) and the corresponding feature points placed on the user‑story map on the right.

The five user stories above have their feature points color‑coded on the story map; as stories increase, the map becomes larger and more complex, making it harder to distinguish individual stories.

Using Team Foundation Server to Manage User Stories

Team Foundation Server (TFS) is Microsoft’s integrated development platform that provides end‑to‑end DevOps capabilities, including requirements, project, source‑code, test, build, release, and deployment management. Most Microsoft products use TFS, and it offers strong support for agile development.

When organizing user stories, we can first record them in Excel together with their feature points and the functional area each belongs to, as shown in the following screenshot.

When importing this spreadsheet into TFS, keep in mind:

The story map is essentially a two‑dimensional table; the top row of functional areas/modules can be expressed using TFS’s Area Path field.

Each story (left side WHY‑WHO‑HOW/WHAT) and its associated feature points have a parent‑child one‑to‑many relationship, which can be represented by different work‑item levels in the TFS backlog.

Each feature card on the right corresponds to a specific functional area/module at the top of the table; during import, set the Area Path field of each work item accordingly to maintain this mapping.

First, create Area Paths in TFS that match the functional areas and modules from the story‑map header.

Now we can import our user stories into TFS.

For details on bulk adding or updating work items from Excel, see: https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel

The resulting backlog shows how TFS maintains the relationship between user stories and feature points while preserving the functional area for each feature, providing a clear view from multiple perspectives.

The imported work items retain the key information from the story map using different fields.

Nevertheless, you still need to enrich each user‑story work item and each feature‑point work item with details captured during team discussions, such as user background, flow diagrams, UI prototypes for stories, and data dictionaries, input/output specifications, validation rules, UI mock‑ups for features. These can be added to the work item’s Description field or attached as files.

In the planning part I emphasized that user stories drive the process rather than the documentation itself. However, we still need to record the critical information generated during discussions so the team can recall details later. Physical boards or whiteboards cannot capture this information, making electronic tools essential at this stage.

The imported stories and feature points become the backlog for subsequent development, supporting prioritization, iteration planning, task breakdown, test‑plan creation, and test‑case derivation. In other words, the future software development lifecycle will follow this backlog as its backbone. Teams can view the backlog from a user‑centric perspective to extract relevant features, or from a product‑module perspective to see the list of functionalities and the user needs influencing each module, enabling balanced decisions between user demand and architectural evolution. This also creates a complete requirements‑traceability view (often called a requirements‑traceability matrix ).

See the diagram below: the left side represents the Architecture Model and the right side the Itemized Requirements , linking the two and forming the foundation of a software development management system.

Thus we have completed the conversion from user stories to a product backlog. The next article will cover how to create development and test plans and introduce Kanban for tracking progress.

Note: The above scenario is part of the "DevOps Agile Hands‑On Lab". Click the link below to access the lab documentation: 【DevOps Agile Hands‑On Lab】 Documentation Release

Reference Materials (clickable in WeChat):

User‑Story‑Driven Agile Development – 1. Planning

Eight Steps to Create a User‑Story Map

First Experience with User‑Story Mapping

Please follow the WeChat public account devopshub for more information on DevOps integration and end‑to‑end R&D operations.