CMMI process template work item types and workflow

Teams use the work item types (WITs) provided with the MSF for CMMI Process Improvement 2013 (CMMI) process template 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.

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 Team Web Access (TWA), 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.

Plan a project by defining requirements and estimating the size of the effort

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

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

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.

By defining the Size for requirements, teams can use the forecast feature and velocity charts to estimate future iterations or work efforts. Capture essential information using the following fields and tabs. For additional guidance, see Plan a project.

Field/tab	Usage
Size (see note 1)	Estimate the amount of work required to complete a requirement using any unit of measurement your team prefers, such as t-shirt size, story points, or time. Agile velocity charts and forecast tools reference the values in this field. This is a required field to generate the velocity chart.
Priority [Required] (2)	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] (2)	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 (2)	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] (2)	Indicates whether the requirement is committed in the project or not. You can specify Yes or No (default).
Stack Rank (1)	Used to track the relative ranking of requirements. The sequence of items on the product 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 which is assigned to type="Order" in the ProcessConfiguration file.
(Requirement) Type [Required] (2)	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
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.
Analysis (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.
Other	The following fields, located on the Other tab, are not required. Integrated In: Product build number that incorporates the requirement, change request, or fixes a bug. User Acceptance Test [Required] (2): The status of the user acceptance test. Pass Fail Not Ready (default) Ready Skipped Info Received Specify Not Ready when the requirement is Active and Ready when the requirement is Resolved. Original Estimate (3): The amount of hours or days required to complete a task. Subject Matter Experts: The names of team members who are familiar with the customer area that this requirement represents. Start Date, Finish Date (3): 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.

Notes:

1. To change the field assignment, see Configure and customize Agile planning tools for a team project.

2. To change the menu selection, see Customize a pick list.

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

   If you use Microsoft Project to assign resources and track a schedule, you can update these fields using Project.

Track progress

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

You can customize the Kanban board to support additional swim lanes or columns. Or, you can customize the workflow for the requirement and task WITs, which will change the default column headings.

A typical workflow progression for a requirement follows:

• 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.

Map requirements to features

When 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.

From the Feature backlog page, you can quickly add features, in the same way that you added requirements.

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

The Requirements tab captures the links to mapped requirements.

Field	Usage
Business Value	Specify a number that captures the relative value of a feature compared to other features. The higher the number, the greater the business value.
Target Date	Specify the date by which the feature should be implemented.

From the backlog page with Mapping turned on, you can drag requirements to the feature that they implement.

This mapping creates parent-child links from feature to requirements, which is captured in the Requirements tab.

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.

Define the tasks required to implement requirements and track team capacity and burndown

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

Name the task and estimate the work it will take.

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 (see note 1)	Select the kind of task to implement from the allowed values: Corrective Action Mitigation Action Planned
Discipline (1)	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 (3)	The amount of estimated work required to complete a task. Typically, this field doesn’t change after it is assigned.
Remaining Work (3)	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 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 (3)	The amount of work that has been spent implementing a task.

Notes:

1. To change the menu selection, see Customize a pick list.

2. To change the field assignment, see Configure and customize Agile planning tools for a team project.

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

   If you use Microsoft Project to assign resources and track a schedule, you can update these fields using Project.

Track test progress on user stories and capture code defects

Test requirements

From Test Manager or TWA, you can create test cases that automatically link to a requirement or bug.

The test case contains several fields, many of which are automated and integrated with Test Manager and the build process. For a description of each field, see Build and test integration field reference.

The Tested Requirements 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 (CMMI) report.

Track code defects

You can create bugs from TWA, Visual Studio, or when testing with Test Manager. For additional guidance, see Track bugs.

Field/tab	Usage
Root Cause	Select the cause of the error from the allowed values: Coding Error Design Error Specification Error Communication Error Unknown To change the menu selection, see Customize a pick list.
Steps to Reproduce	Capture enough information so that other team members can understand the full impact of the problem as well as whether they have fixed the bug. This includes actions taken to find or reproduce the bug and expected behavior. Describe the criteria that the team should use to verify whether the code defect is fixed.
Severity	Select from one of the allowed values that represent a subjective rating of the impact of a bug on the project: 1 - Critical 2 - High 3 - Medium 4 - Low To change the menu selection, see Customize a pick list.
System Info Found In Build Integrated in Build	When Test Manager creates bugs, it automatically populates System Info and Found in Build with information about the software environment and build where the bug occurred. To learn more about defining the software environments, see Setting Up Test Machines to Run Tests or Collect Data. When you resolve the bug, use Integrated in Build to indicate the name of the build that incorporates the code that fixes the bug. To access a drop-down menu of all builds that have been run, you can update the FIELD definitions for Found in Build and Integrated in Build to reference a global list. The global list is automatically updated with each build that is run. To learn more, see Fields that support integration with test, build, and version control. For information about how to define build names, see Use build numbers to give meaningful names to completed builds.

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

With the following WITs, teams can track information recommended by the CMMI process.

• Create a change request whenever a change is proposed to any work product that is under change control. For additional usage guidance, see Manage changes and Change request field reference (CMMI).

  

  On the Analysis tab, provide details for the impact that the change request will have on the architecture, user experience, test, design/development, or technical publications.

• Create an issue to track an event or situation that might block work or is blocking work on the product. Issues differ from risks in that teams identify issues spontaneously, generally during daily team meetings.

  

  For additional guidance, see Manage issues and Bugs, issues, and risks field reference (CMMI).

• Create a risk to track an event or situation that might block work or is blocking work on the product. Issues differ from risks in that teams identify issues spontaneously, generally during daily team meetings.

  

  For additional guidance, see Manage risks and Bugs, issues, and risks field reference (CMMI).

• Create a review to document the results of a design or code review. Team members can capture the details of how the design or code meets standards in areas of name correctness, code relevance, extensibility, code complexity, algorithmic complexity, and code security.

  

  For additional guidance, see Implement development tasks and Review meeting field reference (CMMI).

Define common work item fields and tabs

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

The only required field is Title. When the work item is saved, the system assigns it a unique ID.

Field/tab	Usage
Title (Required)	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	Use the default value first. As work progresses, update it to reflect current state. To change the drop-down list of states, see Change the workflow for a work item type.
Reason	Use the default first. Update it when you change state. Each State is associated with a default reason. To change the drop-down list of reasons, see Change the workflow for a work item type.
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.
All 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, even those defined in other links control tabs.
Attachments	Share more detailed information by adding files to the work item, such as email threads, documents, images, log files, or other file types.
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.

To look up information about other fields, see Index of Work Item Fields.

Start tracking work

Before you start tracking work, you must have a team project. Go here to create one.

To start tracking work, do one or more of the following tasks:

• To get familiar with common work item tasks, see Get started using work items.

• To create a backlog, use TWA. See Create your backlog.

• To create a work breakdown structure, use Project or Excel.

• To learn about which client to use, see Choose the Team Foundation client to support your tasks.

Q & A

Q: What workflow states does CMMI support?

A: These diagrams show the main progression and regression states of Feature, Requirement, Bug, and Task. To customize the workflow, go here.

Feature

Requirement

Bug

Task

Q: How do I resolve a bug as a duplicate?

A: Set the State to Removed and specify the Reason as Duplicate.

Q: How do I link to an existing bug from Test Runner?

A: See Update an Existing Bug while using Test Runner.