CMMI process work item types and workflow

Last Update: 5/5/2017

Team Services | TFS 2017 | TFS 2015 | TFS 2013

Teams use the work item types (WITs) provided with the MSF for CMMI Process Improvement 2015 (CMMI) process to plan and track progress of software projects. Teams define requirements to manage the backlog of work and then, using the Kanban board, track progress by updating the status of requirements.

CMMI process, WITs used to plan and track

To gain insight into a portfolio of requirements, product owners can map requirements to features. When teams work in iterations, they define tasks that automatically link to requirements.

Using Microsoft Test Manager and the web portal, testers create and run test cases and define bugs to track code defects.

To support additional CMMI processes, teams can track change requests, risks, issues, and notes captured in review meetings.

NOTE

Feature availability: Work item tracking forms and features available to you differ depending on whether you connect to the cloud or an on-premises Team Foundation Server (TFS), and whether you open the form from the web portal or Visual Studio Team Explorer. Forms and guidance provided in this topic reflect those available with the new form experience (Team Services and the web portal for TFS 2017 and later versions).

If you connect to TFS 2015 or earlier versions, or open the form from Visual Studio Team Explorer, see Add work items (TFS).

Define requirements

Create requirements from the quick add panel on the product backlog page. Alternatively, you can bulk add requirements using Excel or Project.

CMMI process, Quick add panel on the requirements backlog page

Later, you can open each requirement to provide more details and estimate its size.

Requirement work item form

Requirements specify the functions and product elements that teams need to create. Product owners typically define and stack rank requirements on the product backlog page. The team then scopes the size of the effort to deliver the highest priority items.

Use the following guidance and that provided for fields used in common across work item types when filling out the form. For additional guidance, see Plan a project.

Field Usage

Description

Provide enough detail for estimating how much work will be required to implement the requirement. Focus on who the requirement is for, what users want to accomplish, and why. Don't describe how the requirement should be developed. Do provide sufficient details so that your team can write tasks and test cases to implement the item.

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

Impact Assessment

The customer impact of not implementing this requirement. You might include details from the Kano model about whether this requirement is in the surprise, required, or obvious categories. You capture this information in the rich-text HTML field which corresponds to Impact Assessment.

Requirement Type (Required)

The kind of requirement to implement. You can specify one of the following values:

  • Business Objective

  • Feature (default)

  • Functional

  • Interface

  • Operational

  • Quality of Service

  • Safety

  • Scenario

  • Security

Value area

The area of customer value addressed by the epic, feature, requirement, or backlog item. Values include:

  • Architectural : Technical services to implement business features that deliver solution

  • Business: Services that fulfill customers or stakeholder needs that directly deliver customer value to support the business (Default)

Size

Estimate the amount of work required to complete a requirement using any numeric unit of measurement your team prefers.

By defining the Size for requirements, teams can use the Agile velocity charts and forecast tools to estimate future iterations or work efforts. The Kanban Cumulative Flow Diagram references the values in this field. For additional guidance, see the Estimating white paper.

Original Estimate

The amount of estimated work required to complete a task. Typically, this field doesn't change after it is assigned.

You can specify work in hours or in days. There are no inherent time units associated with this field.

Start Date/Finish Date

The target dates for when the work will start or finish. These fields are filled in by Microsoft Project when you use it for scheduling.

You can specify work in hours or in days. There are no inherent time units associated with this field.

Priority (Required)

A subjective rating of the requirement as it relates to the business. Allowed values are:

  • 1: Product cannot ship without the item.

  • 2: (default) Product cannot ship without the item, but it doesn't have to be addressed immediately.

  • 3: Implementation of the item is optional based on resources, time, and risk.

Triage (Required)

Indicates the type of triage decision that is pending for the work item. Use this field when the work item is in the Proposed state and specify one of the following values: Pending (default), More Info, Info Received, and Triaged.

Blocked

Indicates whether a team member is prevented from making progress toward implementing a requirement or task or resolving a bug, change request, or risk. If an issue has been opened to track a blocking problem, you can create a link to the issue. You can specify Yes of No.

Committed (Required)

Indicates whether the requirement is committed in the project or not. You can specify Yes or No (default).

Integrated In

Product build number that incorporates the requirement, change request, or fixes a bug.

User Acceptance Test (Required)

The status of the user acceptance test for a requirement. You can specify one of the following values:

  • Pass

  • Fail

  • Not Ready (default)

  • Ready

  • Skipped

  • Info Received

You specify Not Ready when the requirement is in the Active state, and you specify Ready when the requirement is in the Resolved state.

Subject Matter Experts

The names of team members who are familiar with the customer area that this requirement represents.

TIP

Use the Discussion section to add and review comments made about the work being performed. This feature is only available from Team Services.

Track progress

As work progresses, you change the State field to update the status. Optionally, you can specify a reason. The state and reason fields appear on the work item form in the header area.

Bug work item form, header area

CMMI workflow states

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

Requirement

Requirement workflow states, CMMI process

Bug

Bug workflow states, CMMI process

Task

Task workflow states, CMMI process

The typical workflow progression for a requirement is:

  • The product owner creates a requirement in the Proposed state with the default reason, New requirement.
  • The product owner updates the status to Active when they begin work to implement it.
  • The team updates the status to Resolved when code development is finished and system tests have passed.
  • Lastly, the team or product owner moves the requirement to Closed when the product owner agrees that it has been implemented according to the Acceptance Criteria and passed all validation tests.

Update status with Kanban or task boards

Teams can use the Kanban board to update the status of requirements, and the sprint task board to update the status of tasks. Dragging items to a new state column updates both the State and Reason fields.

Web portal, Track progress on the Kanban board

You can customize the Kanban board to support additional swim lanes or columns. For additional customization options, see Customize your work tracking experience.

Map requirements to features

hen you manage a suite of products or user experiences, you might want to view the scope and progress of work across the product portfolio. You can do this by defining features and mapping requirements to features.

Using portfolio backlogs, you can drill down from one backlog to another to view the level of detail you want. Also, you can use portfolio backlogs to view a rollup of work in progress across several teams when you setup a hierarchy of teams.

The feature work item contains similar fields provided for requirements and includes additional fields, as the following table describes.

Define tasks

When your team manages their work in sprints, they can use the sprint backlog page to break down the work to be accomplished into distinct tasks.

Web portal, Add task link on a sprint backlog page

Name the task and estimate the work it will take.

CMMI Task work item form

When teams estimate work they define tasks and estimate the hours or days to complete tasks. Teams forecast work and define tasks at the start of an iteration, and each team member performs a subset of those tasks. Tasks can include development, testing, and other kinds of work. For example, a developer can define tasks to implement requirements, and a tester can define tasks to write and run test cases. By linking tasks to requirements and bugs, they see the progress made on these items. For additional guidance, see Iteration activities.

Field

Usage

Task Type

Select the kind of task to implement from the allowed values:

  • Corrective Action

  • Mitigation Action

  • Planned

Discipline

Select the discipline this task represents when your team estimates sprint capacity by activity.

  • Analysis

  • Development

  • Test

  • User Education

  • User Experience

This field is also used to calculate capacity by discipline. It is assigned to type="Activity" in the ProcessConfiguration file. (2)

For additional guidance, see Implement development tasks.

Original Estimate

The amount of estimated work required to complete a task. Typically, this field doesn't change after it is assigned.

Remaining Work

Indicate how many hours or days of work remain to complete a task. As work progresses, update this field. It's used to calculate capacity charts, the sprint burndown chart, and the Burndown and Burn Rate Report.

If you divide a task into subtasks, specify hours for the subtasks only. You can specify work in any unit of measurement your team chooses.

The amount of work remaining to complete a task. As work progresses, update this field. It's used to calculate capacity charts, the sprint burndown chart, and the Sprint Burndown report.

If you divide a task into subtasks, specify hours for the subtasks only. You can specify work in any unit of measurement your team chooses.

Completed Work

The amount of work that has been spent implementing a task.

Track test progress

Test requirements

From the web portal or Test Manager, you can create test cases that automatically link to a requirement or bug. Or, you can link a requirement to a test case from the Links tab icon (links tab).

Select the test suite and add a test case

The test case contains a number of fields, many of which are automated and integrated with Test Manager and the build process. For a description of each field, see Query based on build and test integration fields.

Web portal, Test case work item form

The Links tab icon (links tab) lists all the requirements and bugs in a test case. By using linking, the team can track the progress made in testing each item and supports information that appears in the Requirements Overview Report report.

Track code defects

You can create bugs from the web portal web portal, Visual Studio, or when testing with Test Manager.

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

In addition to the requirement, feature, task, and bug WITs, you can track information recommended by the CMMI process with the following WITS.

Add work item from a New work item widget

Work items you add from the widget are automatically scoped to your team's default area and iteration paths. To change the team context, see Switch team context.

Definitions for common WIT fields

The following fields and tabs appear in most work items. Each tab is used to track specific information, such as History tab icon history, Links tab icon links, or Attachment tab icon attachments. These three tabs provide a history of changes, view of linked work items, and ability to view and attach files.

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

Field/tab

Usage

Title

Enter a description of 255 characters or less. You can always modify the title later.

Assigned To

Assign the work item to the team member responsible for performing the work. Depending on the context you are working in, the drop-down menu will list only team members or contributors to the team project.

State

When the work item is created, the State defaults to the first state in the workflow. As work progresses, update it to reflect the current state.

Reason

Use the default first. Update it when you change state. Each State is associated with a default reason.

Area

Choose the area path associated with the product or team, or leave blank until assigned during a planning meeting.

To change the dropdown list of areas, see Add and modify area and iteration paths.

Iteration

Choose the sprint or iteration in which the work is to be completed, or leave it blank and assign it later, during a planning meeting.

To change the drop-down list of iterations, see Add and modify area and iteration paths.

History tab icon(History)

Review the audit trail that the system captures and capture additional information.

Every time that the work item is updated, information is appended to the history. History includes the date of the change, who made the change, and which fields were changed. You can also add formatted text to the history field.

Links tab icon (Links)

Add all types of links, such as hyperlinks, changesets, source files, and so on.

This tab also lists all links defined for the work item.

Attachment tab icon(Attachments)

Share more detailed information by adding files to the work item, such as email threads, documents, images, log files, or other file types.

Before you start tracking work, you must have a team project. To create one hosted in the cloud, see Sign up for Visual Studio Team Services. To create one hosted on an on-premises TFS, see Create a team project.

If you have a team project, start tracking work:

For more information on Agile tools:

Customize work tracking

You can customize work item types by adding custom fields, custom workflow states, and custom pages on the form. The methods available to you depend on which platform you work from. For an overview of what you can customize, see Customize work.

Backlog list order

The Stack Rank field is used to track the relative ranking of requirements, features, or epics. However, by default it doesn't appear on the work item form. The sequence of items on the backlog page is determined according to where you have added the items or moved the items on the page. As you drag items, a background process updates this field.

This field doesn't appear on the work item form.

Switch team project or team focus

Several features depend on the team project or team that you have selected. For example, dashboards, backlogs, and board views will change depending on the context selected.

For example, when you add a work item, the system references the default area and iteration paths defined for the team context. Work items you add from the team dashboard (new work item widget) and queries page are assigned the team default iteration. Work items you add from a team backlog or board, are assigned the team default backlog iteration. To change team defaults, see Set team defaults.

You navigate to your team context from the top navigation bar. The method changes slightly depending on the platform/version you work from.

NOTE

Feature availability: The Account Landing Page feature is in preview mode for Team Services, and enabled for all users from web portal for TFS 2017.1 and later versions. To learn more about this feature, see Work effectively from your account hub. To enable or disable the feature, see Enable preview features.

You can switch your team focus to a team project or team you've recently viewed from the team project/team drop-down menu. If you don't see the team or team project you want, click Browse… to browse all team projects and teams. To access your account hub, click the Team Services icon Team Services icon. If you haven't yet enabled the Account Landing Page, you'll be taken to the account home page.

To go directly to the project vision and status page, choose the project home icon from the drop-down menu, for example, project home icon.

Choose another team from the team project menu

To switch your team focus to a team project or team you've recently viewed, hover over the Team Services icon Team Services icon and choose from the drop-down menu of options. If you don't see the team or team project you want, choose Browse… to browse all team projects and teams. Your selection will open the project vision and status page for the team project.

To access your account hub, click the Team Services icon Team Services icon. If you haven't yet enabled the Account Landing Page, you'll be taken to the account home page.

To go directly to the project vision and status page, choose the project home icon from the drop-down menu, for example, project home icon.

Choose another team from the team project menu

Open the team project/team drop-down menu and select the team project/team that you've recently visited. If you don't see the team or team project you want, choose Browse all to browse all team projects and teams.

Choose another team from the team project menu

Open the team project/team drop-down menu and select the team project/team that you've recently visited. If you don't see the team or team project you want, choose Browse all to browse all team projects and teams.

Choose another team from the team project menu

Work item forms displayed in a client and the web portal for TFS 2015 and earlier versions display link tabs and link control restrictions as described in the following table.

Tab name

Work item type

Link restrictions

All Links

Requirement

Bug

Change Request

Feedback Request

Issue

Review

Risk

Shared Steps

Task

Test Case

  • No restrictions.

Implementation

Task

  • Allows only Parent and Child links between requirements and tasks.

  • Excludes links to work items in other team projects.

Links

Code Review Request

  • Allows only Parent and Child links to Code Review Response work items.

  • Excludes links to work items in other team projects.

Requirements

Change Request

  • Allows only Affects link type to link change requests to requirements.

  • Excludes links to work items in other team projects.

Stories

Feedback Response

  • Allows only Related links to requirements.

  • Excludes links to work items in other team projects.

Storyboards

Requirement

  • Allows only Storyboard links.

Test Cases

Requirement

Bug

  • Allows only Tested By links.

  • Allows links only to test cases.

  • Excludes links to work items in other team projects.

Tested Requirements

Test case

  • Allows only Tests links.

  • Allows links only to requirements.

  • Excludes links to work items in other team projects.

Feedback and support

We welcome your feedback.

Send suggestions on UserVoice, and follow us on Twitter @VSTeam. Or, tell us what you think with Send-a-Smile on the title bar ... Send-a-Smile.

Or, see our comprehensive feedback and support page.