Edit

Manage requirements

  • Article

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

Screenshot of User Story 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.

Conceptual image, Agile work item type.

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

Screenshot of add product backlog item

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

Screenshot of Excel tree list of requirements to import.

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

Screenshot of Features backlog, ordered by feature parent.

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

Screenshot of mapping User Stories under Features using Mapping tool.

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

Screenshot of Kanban board, Filter using keyword search.

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

Screenshot of Kanban board, Agile template, update status of work item.

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

Screenshot of Boards>Sprints>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

Screenshot of Analytics 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 close icon to close.

Screenshot of Visualize work item relationships.

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

Screenshot of 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 close icon to close.

[Screenshot of Forecast of Requirements backlog, ordered by feature parent.]../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

Boards>Backlogs>Drag-drop items onto sprint

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 close icon to close.

Screenshot of Features board with customized columns.

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

Screenshot of Features backlog showing progress bars column option.

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

Screenshot with callouts of Delivery Plans, collapsed teams.

Interactive plan elements

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.

To learn more about any of the concepts introduced in this article, refer to the following articles.

Agile and Agile culture

Work items, work item types, and process models

Backlogs and boards

Kanban

Scrum

Dependency management

Milestone planning

Monitor and report on progress

Maintain specifications and share information

Notifications