CMMI process work item types and workflow in Azure Boards

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

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.

Or, you can bulk add requirements using a CSV file (see Import work items from CSV).

Important

Microsoft Project Integration is no longer supported

Microsoft Project Integration and the TFSFieldMapping command are discontinued for:

• Visual Studio 2019 and later versions (including Azure DevOps Office Integration)
• Azure DevOps Server 2020 and later versions
• Azure DevOps Services

What still works: Microsoft Excel integration remains fully supported for bulk import and update of work items.

Recommended alternatives:

• Delivery Plans - Native Azure DevOps feature for project planning and cross-team tracking
• Project management extensions - Browse the Azure DevOps Marketplace for current Gantt chart and project management solutions
• Third-party integrations - Many project management tools offer Azure DevOps connectors for seamless workflow integration

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.

Field

Usage

---

Description

Provide enough detail for your team to estimate implementation effort. Focus on who the requirement serves, what users want to accomplish, and why. Avoid describing how to implement the requirement. Include enough context that your team can write tasks and test cases from the item.

In HTML fields, you can add rich text and images.

Impact Assessment

Capture the customer impact of not implementing the requirement in the Impact Assessment rich-text field. You might include Kano-model details that indicate whether the requirement is a surprise, required, or obvious feature.

Requirement Type (Required)

Specify one of these values for Requirement Type:

• Business Objective
• Feature (default)
• Functional
• Interface
• Operational
• Quality of Service
• Safety
• Scenario
• Security

Value area

Indicate the area of customer value that the epic, feature, or requirement addresses. Common values include:

• Architectural: Technical services to implement business features that deliver solution capabilities.
• Business: Services that fulfill stakeholder needs and directly deliver customer value (Default).

Size

Estimate the work required to complete a requirement using any numeric unit your team prefers. Teams use Size for velocity charts and forecasts. The Cumulative Flow Diagram also references values in this field. For more background, see the Estimating white paper.

Original Estimate

Provide the original estimate for a task. Typically this value doesn't change once the task is assigned. You can specify work in hours or days; the field has no inherent time unit.

Start Date/Finish Date

Supply the target start and finish dates for the work.

Priority (Required)

Set a subjective rating that reflects business priority:

• 1: Product can't ship without the item.
• 2: (default) Product can't ship without the item, but it doesn't require immediate attention.
• 3: Implementation is optional based on resources, time, and risk.

Triage (Required)

Use Triage when a work item is in the Proposed state. Choose one of: Pending (default), More Info, Info Received, Triaged.

Blocked

Indicate whether a team member can't make progress on the work item. If an issue blocks work, create a link to the issue. Choose Yes or No.

Committed (Required)

Indicate whether the team committed to delivering the requirement. Choose Yes or No (default).

Integrated In

Record the product build number that includes the requirement, change request, or bug fix.

User Acceptance Test (Required)

Set the status of the user acceptance test for a requirement from:

• Pass
• Fail
• Not Ready (default)
• Ready
• Skipped
• Info Received

Use Not Ready when the requirement is Active, and Ready when it's Resolved.

Subject Matter Experts

List team members familiar with the customer area that the requirement represents.

---

Capture comments in the Discussion section

Use the Discussion section to collaborate on work items by adding and reviewing comments.

When you place your cursor in a text box that supports formatting, the rich-text editor toolbar appears.

Note

A Discussion work item field doesn't exist. To query work items with comments from the Discussion area, filter on the History field. The full content of the text entered in the Discussion text box is added to the History field.

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

Use one of the following icons to open recent entries for people, work items, or pull requests:

• 
• 
• 

You can open the same menu with keyboard shortcuts: at-mention @, hashtag #, and exclamation point !.

Enter a name or number to filter the list, and then select the item you want to add. To mention a group, enter @ followed by the group name, such as a team or security group.

Edit or delete a comment

To update or remove one of your comments, select Edit or select More actions ( ) and then select Delete:

After you change a comment, select Update. To remove a comment, confirm deletion. The History tab maintains an audit trail of all edited and deleted comments.

Add a reaction to a comment

Add one or more reactions to a comment by selecting an emoji on the comment. To remove your reaction, select the same reaction again. The following image shows an example of adding and viewing reactions on a comment.

Save a comment without saving the work item

Note

This feature is available starting in Azure DevOps Server 2022.1.

If you only have permissions to add to the Discussion of a work item, then you can do so by saving comments. This permission is controlled by Area Path nodes and the Edit work item comments in this node permission. For more information, see Set work tracking permissions - Create child nodes, modify work items under an area or iteration path.

When you save comments, you don't need to save the work item.

Note

When you save changes made to the Discussion control, only the comment is saved. No work item rules defined for the work item type are executed.

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.

Field

Usage

Task Type

Select the task type from:

• Corrective Action
• Mitigation Action
• Planned

Discipline

Choose the discipline this task represents when you estimate sprint capacity by activity:

• Analysis
• Development
• Test
• User Education
• User Experience

This field also helps calculate capacity by discipline. It's assigned to type="Activity" in the ProcessConfiguration file. For more information, see Implement development tasks.

Original Estimate

Enter the original estimate for the task.

Remaining Work

Update Remaining Work as the team progresses. This value feeds capacity charts, the sprint burndown chart, and related reports. If you break a task into subtasks, track hours on the subtasks only.

Completed Work

Record the work already spent implementing the task.

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. Common tabs include History, Links, and Attachments.

For all work item types, Title is the only universally required field. When you save a work item, Azure DevOps assigns a unique ID. Required fields are highlighted in yellow. For more fields, see Work item field index.

Note

Other fields might be required based on process and project customizations.

Field or tab	Usage
Title	Enter a short description (up to 255 characters). You can edit the Title later.
Assigned To	Assign the work item to the person responsible for completing it, or leave it unassigned until ownership is clear.
State	On creation, State defaults to the first workflow state (such as New or Unassigned). Update it as work progresses.
Reason	Reason explains why the item is in the current State. Default values vary by work item type and process.
Area	Select the area path for the product or team. For details, see Define area paths and assign to a team.
Iteration	Select the sprint/iteration for planned completion. For details, see Define iteration paths (sprints) and configure team iterations.
History tab	View the full change log for the work item, including author, date, and updated fields. You can also add formatted text in History.
Links tab	Add relationships to other artifacts (for example, parent/child work items, changesets, source files, or test results).
Attachments tab	Add supporting files such as documents, images, logs, or email threads.

Customize work item types

For most work item types, you can add fields, update the workflow, define custom rules, add custom pages, and create custom work item types. For more information, see Customize an inheritance process.

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.