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.

Tasks	Related content
Create a bug. When you notice unexpected behavior of the application during ad hoc testing, you can quickly create a Bug.	How to: Submit a Bug Using Microsoft Test Manager
Collect diagnostic data to support debugging. By using Test Runner, you can collect diagnostic trace data on an application that was written with managed code, which a developer can then use with Intellitrace to isolate errors.	Including Diagnostic Trace Data with Bugs that are Difficult to Reproduce
Create a recorded action log file and add it to a bug. You can record actions as text in a log file when you run manual tests. You can automatically add this file to any bug that you create as you run your manual test.	How to: Use Recorded Actions in Bugs to Create Test Cases
Create a test case from a bug and a recorded action log file. You can use an action log to create a manual test case from a bug or a test result. By taking this approach, you can create test cases without having to type in all the steps.	How to: Use Recorded Actions to Create Test Cases
Verify and update the status of a bug based on test results. If you submit a bug that is based on a test case, you can verify that bug directly from the My Bugs list in Microsoft Test Manager. To take this approach, a test result must be associated with that test case. You can quickly rerun the test, change the status of the bug based on the results, and add comments to the bug.	How to: Verify a Bug is Fixed Using Microsoft Test Manager

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

Tasks	Related content
Learn about the fields that you can use to track information across all types of work items. The database for tracking work items stores data for fields that do not appear on the work item forms. You can learn more about these work item fields, restrictions on specific fields, and which fields that are reported and indexed.	Work Item Fields (Agile)
Add, remove, or customize how you use each type of work item to track data. You can customize an existing type of work item or create a type to meet your requirements. Each type of work item corresponds to an XML definition file that is imported into a team project.	All WITD XML Elements Reference
Customize objects for tracking work items to support your requirements for tracking projects. You can customize data fields, workflow, and work item forms that your team uses to track progress. To customize an object for tracking work items, you modify an XML file and import it into the server that hosts the project collection.	Customizing Project Tracking Data, Forms, Workflow, and Other Objects
Add, remove, or modify the states or transitions that control workflow. You control the workflow by defining its initial state, its valid states, the valid transitions between those states, and the users or groups who have permission to perform those transitions. The WORKFLOW section of the work item type controls how a work item is tracked.	Defining and Customizing Work Item Workflow
Modify and customize the form for a type of work item. You can control how a work item type displays user-interface elements through the FORM section of the definition for the type of work item. Each type of work item must have only one form. You can describe the whole form, which includes all its tabs, fields, and groups.	Designing and Customizing a Work Item Form

See Also

Concepts

Choose a Process Template

Artifacts (CMMI)