Manage requirements
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018
Become familiar with the essential concepts to manage projects using Agile tools. Gain an overview of Azure DevOps tools and features to manage requirements. This article maps Agile requirements management tasks by project managers to the tools Azure DevOps supports. More detailed information is provided under Related articles.
Note
Requirements management is a continuous process throughout a project lifecycle—encompassing the processes of documenting, analyzing, prioritizing, tracking, and collaborating with stakeholders to agree on work to be performed. A single requirement corresponds to a capability which a project outcome—product, service, architecture, performance—should conform.
Agile requirements management supports the following scenarios.
- Define and track status of requirements
- Analyze and prioritize requirements
- Assign requirements to timeboxes
- Group and organize requirements
- Manage dependencies
- Determine what can ship and when
- Monitor and report on progress
When managing requirements using Agile methods, you'll also perform within an Agile culture which supports the following principles and methods:
- Alignment within the organization
- Autonomous teams
- Kanban and lean management
- Scrum
Capture requirements
You capture requirements using work items, where each work item is based on a work item type. You have a choice of work item types to use based on the process you select. Or, you can add a custom work item type.
Note
Requirements specify expectations of users for a software product. In Azure Boards, requirements are defined by work items that appear on your product backlog. They correspond to User Stories (Agile), Product Backlog Items (Scrum), Issues (Basic), or Requirements (CMMI) based on the process selected for your project. They also belong to the Requirements Category which manages which work item types appear on the product backlog.
Work item fields and form
You can use work items to track anything you need to track. Each work item represents an object stored in the work item data store. Each work item is based on a work item type and is assigned a unique identifier.
Each work item supports tracking data contained in work item fields. Also, it captures changes as updates are made within the History field and comments made in the Discussion section. The following image shows a sample work item form for the User Story work item type.
Example work item form
In a nutshell, you use work items to support these tasks:
- Add information, update status, assign to team members, link work items, and attach files
- Assign work to a timebox or sprint
- Quickly fill in work item fields using work item templates
- Contribute to a queryable discussion thread
- Prioritize work and triage work items.
Other features that support end-to-end traceability are the Development and Deployment sections. These sections support the following tasks and insights:
- Create a new branch or pull request from a work item
- Complete the pull request
- Perform a squash merge
- Create a branch for several work items
- Link a work item to existing development and build objects
- View the release stages associated with the work item within the work item form in real time
- View the status of releases within those work items that are associated with commits in the build and release pipelines
Work item types
Different work item types support capturing different information and workflow processes. Each work item is based on a work item type. The following images illustrate the default work item types used to capture requirements and code defects. They are based on the four system processes—Agile, Basic, Scrum, or Capability Maturity Model Integration (CMMI).
Each Azure DevOps project is defined based on one of these customizable processes. Each team can determine how they want to track bugs.
Default work item types
The following image shows the Agile process backlog work item hierarchy. User Stories and Tasks are used to track work, Bugs track code defects, and Epics and Features are used to group work under larger scenarios.
Each team can configure how they manage Bugs—at the same level as User Stories or Tasks—by configuring the Working with bugs setting. For more information about using these work item types, see Agile process.
Customize work item types
You can add custom work item types or customize the default work item types. Supported customizations include the following additions:
- Add custom fields and workflow states
- Add custom rules to support business workflow processes
- Add custom portfolio backlogs and customize backlogs and boards
- Add custom controls to work item forms to gain enhanced functionality.
Add work items to product backlog or board
Capturing requirements typically starts by adding a Title to a product backlog. You add details later.
Capture requirements on the product backlog
Import and update requirements using Excel
Alternatively, you can import and update requirements you've defined through a .csv file or Excel spreadsheet. These tools support a flat list or a hierarchy of work items. As shown in the following image, a hierarchy of Epics, Features, and User Stories are defined in Excel and then imported to Azure DevOps.
Import requirements from Excel
Functional and non-functional requirements
Any work that you or a development team need to track can be captured using work items. You can use the same type of work item to capture both functional and non-functional requirements. Non-functional requirements specify criteria associated with system operations rather than specific product or service functionality.
You can differentiate your requirements using tags, the Business Value field, or a custom field.
Maintain requirement specifications
Requirements often require specifications to provide details that aren't readily captured within the work item. You can use Azure DevOps to maintain and version control your requirements under an Azure Repos repository. Or, you can use a project wiki to provide a central source and repository for specifications.
You can then link your specifications or attach them to your requirements.
Analyze and prioritize requirements
Once you have a working backlog, you'll want to get it in priority order. You'll want to review and refine your requirements and make sure the acceptance criteria is well-defined. These tasks are supported through the following Azure Boards tools:
- Product backlog: Supports drag-and-drop of work items to get them in priority order. Supports bulk-edit of work items to change assignments or update fields.
- Query Results, Triage mode: Supports review of a list of work items and their forms so that you can quickly update work items and add details.
Here the features backlog shows the sequence of features to ship.
Prioritize feature backlog
Group and organize requirements
The product backlog starts out as a flat list. However, often you want to group requirements that support specific features or business objectives. Azure Boards supports this by providing portfolio work item types, portfolio backlogs and boards, and a Mapping tool to quickly link requirements to a portfolio work item.
Work item tags are another way you can group requirements.
Epics, features, and portfolio backlogs
You group requirements under Features, and Features under Epics, using parent-child hierarchical links. This type of grouping is recommended for organizations with several teams that want to view rollups associated with multiple teams and to take advantage of all portfolio planning tools.
By grouping work within a hierarchy, you can manage a portfolio of features that are supported by different development and management teams. Also, you can view a rollup of estimates, progress bars, and more on product backlogs.
Group User Stories under Features using Mapping
Use tags to group work items
With work item tags, team members can assign ad-hoc tags to work items. You can use these tags to filter backlogs and boards as well as query on work items. For example, the following image illustrates a Kanban board filtered on the web keyword which displays cards with the Web tag.
Filter backlogs and boards based on tags
Implement Kanban or Scrum
Two of the major Agile methods are Kanban and Scrum. Azure Boards supports both methods. Or, teams can adapt them to use a combination of methods such as Scrumban.
Implement Kanban
Each product and portfolio backlog is associated with a corresponding Kanban board. Both backlogs and boards are associated with a team, and display work items based on the area and iteration paths selected by the team.
Each board supports many Kanban practices such as defining columns and swimlanes, setting Work-in-Progress (WIP) limits, defining the Definition of Done, and more. As work completes in one stage, you update the status of an item by dragging it to a downstream stage.
Example Kanban board
Each team can quickly configure their board and the cards to support their business needs.
Implement Scrum
Sprint backlogs and Taskboards provide a filtered view of work items a team has assigned to a specific iteration path, or sprint. From your requirements backlog, you can drag-and-drop work items onto an iteration path, and then view that work in a separate Sprint Backlog.
Example Sprint Backlog
Supported Scrum practices include the following tasks:
- Assign requirements to a sprint
- Add tasks to requirements
- Set sprint capacity for team members
- Adjust work to fit sprint capacity
- Share your sprint plan
- Filter, update tasks, and update task status
- Monitor sprint burndown
Sprint burndown chart
By updating the status of work daily throughout a sprint, you can easily track sprint progress with the Sprint burndown chart, as shown in the following image.
Example Sprint burndown chart
Manage dependencies
In Microsoft Project, you manage tasks that depend on the completion of other tasks by linking them. To manage dependencies in Azure Boards, you can link work items using the Predecessor/Successor link type. Once you've linked work items, you can view link relationships using the Work Item Visualization Marketplace extension. The following image illustrates link relationships among several work items.
To see the full image, click the image to expand. Choose the close icon to close.
Minimum Viable Product versus Critical Path Management
Azure Boards doesn't provide a native view of the critical path. In part, as Agile methodologies favor a Minimum Viable Product (MVP) over Critical Path Management (CPM). By using MVP, you identify the shortest path and dependencies by prioritizing epics, features, stories, and tasks.
Perform milestone planning
Two tools that support planning what can ship when are team velocity and forecasting.
Team velocity
One of the advantages of working in sprints is that you gain insight into team velocity. Velocity provides an indication of how much work a team can complete during a sprint based either on a count of completed work items or the sum of requirement estimates.
Example team Velocity chart
Forecast requirements
The Forecast tool requires that you provide estimates to the Story Points, Effort, or Size field for each requirement.
With estimates assigned to each requirement, you can set a team velocity. In the example below, we specify 12 for the velocity, equivalent to stating that on average the team can complete 12 Story Points per sprint. The Forecast tool shows which requirements and features the team can complete within the next six sprints. Using the Planning tool, you can quickly assign requirements to the forecasted sprints.
Example Forecast of requirements backlog
To see the full image, click the image to expand. Choose the close icon to close.
[]../boards/media/best-practices/forecast-product-backlog-ordered-parent.png#lightbox)
If you want to integrate your requirements planning with Microsoft Project tools, you may do so via a Marketplace extension.
Milestone markers
Milestone markers aren't used in Azure Boards work tracking, except for Delivery Plans. Delivery Plans provide a calendar view and allow you to define a milestone marker. However, you can use one or more of the following options to mark a work item as a milestone:
- Simply prepend or append the word Milestone in the title of your work item
- Add a work item tag labeled Milestone
- Add a custom field labeled Milestone and populate it with a pick list of milestones
- Link work items using the Predecessor/Successor or Related link type to a milestone work item
- Assign a milestone work item to the sprint in which it's targeted for completion.
Assign requirements to timeboxes
You can quickly assign work items to a sprint through drag-and-drop from the product backlog to the sprint listed within the Planning pane.
Example assign requirements to sprints
Monitor and report on progress
The three main tools you'll want to use to review progress and deliverables are:
- Features Kanban board
- Features backlog with rollup columns
- Delivery plans
Features Kanban board
Your Features board is another place to review progress and ensure the continuous flow of deliverables. The following image illustrates a customized Features board. In progress columns have been added such as Need more info, Spec Complete, In Progress, and Customer Rollout. These column labels provide a more natural set of states as Features get proposed, researched, designed, developed, and then deployed to production.
Example of Features board with customized columns
To see the full image, click the image to expand. Choose the close icon to close.
Rollup
One quick and visual way to monitor progress is from the Features backlog. By adding the rollup progress bar column, you can see what percentage of work items are completed for each feature, as shown in the following image.
Example of Requirements backlog showing progress rollup
Delivery plans and multiple team deliverables
To review features delivered across several teams, configure a delivery plan. Delivery plans provide an interactive board to review a calendar schedule of stories or features several teams plan to deliver.
Example of multi-team Delivery Plan

Get notified of changes
Azure DevOps provides a robust alert system, allowing project members to set alerts for themselves, a team, or a project.
As changes occur to work items, code reviews, source control files, and builds, you can receive email notifications. For example, you can set an alert to be notified whenever a bug that you opened is resolved or a work item is assigned to you. You can set personal alerts, team, project, or organization alerts.
Related articles
To learn more about any of the concepts introduced in this article, refer to the following articles.
Agile and Agile culture
- What is Agile?
- Agile culture
- Best practices for "light-weight" Agile project management
- Scaling Agile - Practices that scale
Work items, work item types, and process models
- About work items
- Add work item tags to categorize and filter lists and boards
- About processes and process templates
- About process customization and inherited processes
- Bulk add or modify work items with Excel
- About Area and Iteration Paths (sprints)
- Work tracking, process, and project limits
Backlogs and boards
- Create your backlog
- Organize your backlog
- Define features and epics
- About teams and Agile tools
- Tasks supported by Backlogs, Boards, Taskboards, and Plans
- Configure and customize Azure Boards
Kanban
- Start using your Kanban board
- Add columns to your Kanban board
- Customize cards
- Filter your Kanban board
Scrum
Dependency management
Milestone planning
- View or configure team velocity
- Forecast your product backlog
- The Critical Path on Agile Projects
- Running a lean startup on Azure DevOps
Monitor and report on progress
Maintain specifications and share information
Notifications
Feedback
Submit and view feedback for