Work Items and Workflow (CMMI)

A team uses work items to track, monitor, and report on the development of a product and its features. A work item is a database record that a team member creates in Visual Studio Team Foundation Server to record the definition, assignment, priority, and state of work. The process template for MSF for CMMI Process Improvement v5.0 defines nine types of work items: requirement, task, change request, bug, issue, risk, review, test case, and shared steps. Test cases and shared steps are specifically for use with Test Runner and Microsoft Test Manager. 

In this topic Defining Requirements, Tasks, and Other Work Items Creating a Requirement, a Task, or Another Type of Work Item Creating Many Requirements, Tasks, or Other Work Items at One Time Creating a Work Item that Automatically Links to Another Work Item Creating Test Cases and Test Plans By Using Test and Lab Manager Opening and Tracking Bugs By Using Test Runner and Test and Lab Manager Viewing Work Items Assigned to You Customizing Work Item Types and Related Tasks

To create a work item, open your team project in Team Explorer, right-click Work Items, and click the type of work item that you want to create.

By defining individual work items and storing them in a common database and metrics warehouse, you can answer questions on project health whenever they come up. Work items, links between work items, and file attachments are all stored in the Team Foundation database for tracking work items, as the following illustration shows.

Defining Requirements, Tasks, and Other Work Items

You can specify and update information for work items on the work item form. The topics in this section provide details about how you work within each work item form.

Tasks	Related content
Define and track functional and operational requirements. A team creates requirements to capture and track how the product must address a customer problem. A team can use requirements to describe scenarios and quality of service, safety, security, functional, operational, and user interface criteria. Requirements move through the workflow states of Proposed, Active, Resolved, and Closed.	Requirement (CMMI)
Track and approve requests for changes. A team can use a change request to track proposed changes to some part of the product or baseline. A team member should create a change request when a change is proposed to any work product that is in the configuration management system. The change control board should analyze and then accept or reject proposed changes. If the board accepts a change request, the team generates tasks to implement the change. Change requests move through the workflow states of Proposed, Active, Resolved, and Closed.	Change Request (CMMI)
Track and estimate work. A team creates tasks to track the number of hours that it must spend to implement a Requirement or other area of work. Tasks should represent a unit of work that can be accomplished in one to two days. You can break larger tasks down into smaller subtasks. You can create a task to track work to develop code, design and run tests, address bugs, and perform regression testing. In addition, you can create tasks to support generic work that the team must perform. By tracking work hours for each task, the team can gain insight into the progress that it has made on the project. Tasks move through the workflow states of Proposed, Active, Resolved, and Closed. You can use the Remaining Work and Burndown and Burn Rate reports to monitor team progress, identify problems in the flow of work, and determine the team burn rate.	Task (CMMI) Remaining Work Report Burndown and Burn Rate Report (Agile)
Open and track bugs. You can track a code defect by creating a bug work item. By creating a bug, you can accurately report the defect in a way that helps other members of the team to understand the full impact of the problem. In the bug, you should describe the steps that led to the unexpected behavior so that others can reproduce it, and the test results should clearly show the problem. The clarity and completeness of this description often affects the probability that the bug will be fixed. Bugs move through the workflow states of Proposed, Active, Resolved, and Closed. You can use the Bug Status report to track the team's progress toward resolving and closing bugs.	Bug (CMMI) Bug Status Report
Define and manage impediments to progress. You can define known or potential problems or impediments to your project by creating issue work items. When concrete action is required, an issue might translate into one or more tasks that the team must complete to mitigate the issue. For example, a technical issue can lead to an architectural prototyping effort. Teams should always encourage its members to identify Issues and ensure that they contribute as much information as possible about issues that jeopardize team success. Teams should empower individuals to identify Issues without fear of retribution for honestly expressing tentative or controversial views. Teams who create and sustain positive environments for managing Issues will identify and address them earlier, faster, and with less confusion and conflict than teams who sustain negative risk environments. Issues move through the workflow states of Proposed, Active, Resolved, and Closed. You can use the Issues workbook to review, rank, and manage Issues.	Issue (CMMI) Issues Workbook
Identify and mitigate risks to project success. The team uses the risk work item to document a possible event or condition that can have a negative outcome on the project. A critical aspect of project management is identifying and managing the risks of a project. The risk work item provides specific fields to record mitigation and contingency plans and to track the potential impact of risks on the development effort. Risks move through the workflow states of Proposed, Active, Resolved, and Closed.	Risk (CMMI)
Capture the details and decisions that the team makes during code reviews. The team uses the review work item to document the results of a design or code review. The review work item has specific fields to record detailed information about how the design or code met standards in areas of name correctness, code relevance, extensibility, code complexity, algorithmic complexity, and code security. The review work item supports maintaining a record of decisions and work that the team performed to support product quality. Reviews move through the workflow states of Active, Resolved, and Closed.	Review (CMMI)
Test the application. A team uses test cases to define tests that will support testing of user stories. You can define manual test cases that specify a sequence of action and validation steps to run, or you can specify automated test cases that reference an automation file. Note The recommended client for creating and defining test cases is Test Manager. By using this tool, you can also create test suites and test configurations that address the complete range of testing criteria for your project. In test configurations, you specify the software environment under which you want to run your test cases and test suites. For more information, see Testing the Application. Test cases move through the workflow states of Design, Ready, and Closed. You can use the Test Case Readiness report to determine the progress that the team is making toward defining test cases.	Test Case (CMMI) Test Case Readiness Report
Define shared steps. A team uses shared steps to streamline definition and maintenance of manual test cases. In shared steps, you define a sequence of action and validation steps to run as part of a test case. Many tests require the same sequence of steps to be performed for multiple test cases. By creating shared steps, you can define a sequence of steps once and insert it into many test cases. Important The recommended client for creating and defining shared steps is Test Manager. You can view these types of work items by using Team Explorer and Team Web Access; however, you cannot use Team Web Access to modify or update certain fields. Shared steps move through the workflow states of Active and Closed.	Shared Steps (CMMI)

Creating a Requirement, a Task, or Another Type of Work Item

You can create a work item by opening Team Web Access or Team Explorer and following the procedure in this section. After you create a work item, you can always modify and add details as a sprint progresses.

To create a requirement, a task, or another type of work item

1. Open either Team Web Access or Team Explorer, and connect to the team project collection that contains the team project in which you want to create the work item.

   For more information, see Connect to and Access Team Projects in Team Foundation Server.

2. Perform one of the following steps:

   • In Team Web Access, find the quick launch area of the navigation pane, and then click the New Work Item arrow. On the Work Item Types menu, click the type of work item that you want to create.

   • In Team Explorer, open the Team menu, point to Add Work Item, and click the type of work item.

   A work item form opens of the type that you specified.

   

      

   

3. Define the fields in the top portion of the form and for each tab in the bottom portion of the form as the type of work item requires.

   For more information, see Defining User Stories, Tasks, or Other Work Itemsearlier in this topic.

4. On the work item toolbar, click Save Work Item.

   Note

   After you save the work item, the identifier appears in the title under the work item toolbar.

Creating Many Requirements, Tasks, or Other Work Items at One Time

You can quickly define multiple tasks that are automatically linked to requirements by using Office Excel. Also, you can quickly define Requirements, Tasks, and Issues by using Office Excel. For more information, see the following topics:

• Managing Work Items Using Microsoft Excel Bound to Team Foundation Server

• Performing Top-Down Planning Using a Tree List of Work Items (In Excel)

Creating a Work Item that Automatically Links to Another Work Item

You can create a work item that automatically links to an existing requirement or other work item. You can perform this action from an open work item form or from a list of results for a work item query.

To create a work item that is linked to an existing work item

1. Open either Team Web Access or Team Explorer, and connect to the project collection that contains the team project where you want to define the linked work item.

2. Right-click the Open Work Items team query, and then click Open.

3. Perform one of the following actions:

   • In Team Web Access, click the arrow next to the existing work item to which you want to link the new work item, and then click Add New Linked Work Item.

   • In Team Explorer, right-click the existing work item to which you want to link the new work item, and then click Add New Linked Work Item.

   The Add new Linked Work Item dialog box opens.

   

4. Define the following fields:

   • In the Link Type list, click the type of link that corresponds to the relationship between the work items that you want to create.

     For a link to a task from a requirement, click Child.

     For a link to a change request, click Affected By.

     For a link to a test case, click Tested By.

     For a link to any other type of work items, click Related or another type of link that represents the relationship that you want to track.

   • In the Work Item Type list, click the type of work item that you want to create.

   • In Title, type a name that describes the requirement, task, or other type of work item to be tracked.

   • (Optional) In Comment, type additional information.

5. Click OK.

   A work item form opens with the information that you have provided.

6. Define the remaining fields as the type of work item requires.

   For more information, see Defining Requirements, Tasks, or Other Work Items earlier in this topic.

7. Click Save Work Item.

Creating Test Cases and Test Plans By Using Test and Lab Manager

By using Test Manager, you can create not only test cases but also test suites and test configurations that support testing your project. You can use test configurations to define the software environment under which you want to run your test cases and test suites.

Test Plans, Test Suites, and Test Configurations

You can group your test cases together by organizing them into a hierarchy of test suites in your test plan. By creating test suites, you can run sets of test cases as a group. For more information about how to use Test Manager to define test cases, test suites, and test plans, see Testing the Application.

Opening and Tracking Bugs using Test Runner and Test and Lab Manager

By using Test Manager, you can submit bugs that automatically contain information about the test case and test environment that you ran, in addition to the specific test step on which you discovered a code defect. Bugs that you create by using Test Manager automatically link the bug to the test case that you were running when you discovered the bug.

You can create bugs in the following ways:

• From Test Manager when you run a test by using Test Runner, view a test result, or view your bugs

• From Team Web Access or Team Explorer

• From Office Excel (useful if you are submitting multiple bugs at the same time)

For information about how to submit, track, and verify bugs and fixes by using Test Manager, see the related content in the following table.

Viewing Work Items That Are Assigned to You

As a team member, you can quickly find the work items that are assigned to you by either opening the My Work Items team query or by accessing My Dashboard. For more information, see the following topics:

• Team Queries (CMMI)

• My Dashboard (Agile)

• Find and Edit Work Items Assigned to You

Customizing Work Item Types and Related Tasks

See Also

Concepts

Choose a Process Template

Artifacts (CMMI)