CMMI process work item types and workflow in Azure Boards

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Teams use the work item types (WITs) that ship with the MSF for CMMI Process Improvement 2015 (CMMI) to plan and track software projects. Product owners define requirements to manage the backlog, and teams track progress on your board by updating requirement and task status.

Product owners map requirements to features to view portfolio-level progress. When teams work in iterations, they create tasks that automatically link to requirements.

Testers create and run test cases using Microsoft Test Manager or the web portal, and they file bugs to track code defects.

Teams also track change requests, risks, issues, and notes captured during review meetings. If you're new to the CMMI process, start with Plan and track work with CMMI.

Define requirements

Create requirements from the quick add panel on the product backlog page. Later, open each requirement to supply details and estimate its size.

Requirements describe the product elements and functions teams need to build. Product owners typically define and stack-rank requirements on the product backlog page. The team then scopes the required effort and writes tasks and test cases to implement each item.

Use the following guidance and the section fields used in common across work item types when you complete the form. For more information, see Plan a project.

Capture comments in the Discussion section

Use the Discussion section to add and review comments made about the work being performed.

The rich text editor toolbar appears under the text entry area when you place your cursor in any text box that supports text formatting.

Mention someone, a group, work item, or pull request

Select one of the following icons to open a menu of recent entries where you mentioned someone, linked to a work item, or linked to a pull request:

You can open the same menu by using keyboard shortcuts: at-mention @, hash tag #, and exclamation point !.

Enter a name or number to filter the menu list to match your entry. Select the entry you want to add. To bring a group into the discussion, enter the at symbol @ followed by the group name, such as a team or security group.

Edit or delete a comment

To edit or delete any of your discussion comments, select Edit or More actions ( ) and then select Delete:

After you update the comment, select Update. To delete the comment, confirm the deletion. The History tab on the work item form maintains a full audit trail of all edited and deleted comments.

Track work progress

As work progresses, update the State field to reflect the current status. Optionally provide a reason; the state and reason fields appear in the work item form header.

CMMI workflow states

The following diagrams show the main progression and regression states for the Requirement, Bug, and Task WITs.

Requirement	Bug	Task

The typical workflow for a requirement follows these steps:

• The product owner creates a requirement in the Proposed state with the default reason, New requirement.
• The product owner moves the requirement to Active when work begins.
• The team sets the requirement to Resolved when development is finished and system tests pass.
• Finally, the team or product owner moves the requirement to Closed after acceptance criteria and validation tests confirm completion.

Update work status with a board or Taskboards

Use the board or the sprint taskboard to update item states. Dragging an item to a different column updates both the State and Reason fields.

You can customize the board to add more swim lanes or columns.

Map requirements to features

When you manage multiple products or user experiences, define features and map requirements to those features to view scope and progress across the portfolio.

Use portfolio backlogs to drill down between backlog levels and to roll up work in progress across teams. You can also view rollups after you set up a hierarchy of teams.

The feature work item contains fields similar to requirements plus other fields described in its reference.

Define tasks

When your team delivers work in sprints, break requirements into tasks from the sprint backlog page and estimate the effort.

Name the task and estimate the work.

When teams estimate work, they define tasks and estimate hours or days to complete them. Teams forecast capacity and refine tasks at the start of an iteration; each team member then performs a subset of tasks. Tasks can include development, testing, and other activities. For example, a developer creates tasks to implement a requirement while a tester creates tasks to write and run test cases. By linking tasks to requirements and bugs, teams clearly see implementation progress. For more information, see Iteration activities.

Track test progress

Test requirements

From the web portal or Test Manager, create test cases that automatically link to a requirement or bug, or add a link from the (links tab).

The test case contains many fields, including fields that integrate with the build and test process. See Query based on build and test integration fields for details.

The (links tab) lists all requirements and bugs referenced by a test case. Linking helps teams track test progress and supports reports such as the Requirements Overview Report.

Track code defects

Create bugs from the web portal, Visual Studio, or Test Manager (see Manage bugs).

Track change requests, risks, issues, and notes captured in review meetings

In addition to requirements, features, tasks, and bugs, the CMMI process recommends these WITs:

• Change request to manage proposed changes to work products under change control.
• Issue to track events or situations that might block work. Issues differ from risks because teams typically identify issues spontaneously during daily meetings.
• Risk to track probability and variance between actual and desired outcomes. When you manage risks, you minimize the variance between expected and actual outcomes.
• Review to document how a design or code review meets standards such as name correctness, code relevance, extensibility, complexity, and security.

You can add an issue using the New work item widget on a team dashboard or from the New menu on the Queries page.

Work items added from the widget automatically scope to your team's default area and iteration paths. To change the team context, see Switch team context.

Definitions for common work tracking fields

The following fields and tabs appear in most work items. Each tab is used to track specific information. Commonly used tabs include History, Links, and Attachments.

The only required field for all work item types is Title. When you save a work item, the system assigns a unique identifier, ID. The form highlights required fields in yellow. For information about other fields, see Work item field index.

Customize work item types

Related content

• Create a project
• Add work items and manage a project
• Create a backlog
• Manage access to specific features
• Learn about default permissions and access levels for Azure Boards

Backlog list order

Use the Stack Rank field to track the relative ranking of requirements, features, or epics. The backlog page determines sequence based on where you add or move items on the page (see Create your backlog). As you drag items, a background process updates the Stack Rank field. This field doesn't appear on the work item form by default.