Task (CMMI)

You can learn how to fill in the details of a task work item in this topic. A task communicates the need to do some work. For more information about how to estimate development tasks, see Implementing Development Tasks.

For information about how to create this type of work item, see Work Items and Workflow (CMMI).

In this topic

Related topics

Defining a Task Linking a Task to Other Work Items Adding Details, Attachments, or Hyperlinks to a Task Changing the State of a Task

Process Guidance Planning the Project (CMMI) Iteration Activities Planning an Iteration (CMMI) Implementing Development Tasks Workbooks Triage Workbook (CMMI) Dashboards and Reports My Dashboard (CMMI) Progress Dashboard (CMMI) Burndown and Burn Rate Report (CMMI) Remaining Work Report Status on All Iterations Report Field Reference Titles, IDs, Descriptions, and History Field Reference Assignments and Workflow Field Reference Effort, Schedules, and Tracking Work Field Reference Planning, Ranking, and Priorities Field Reference Areas and Iterations Field Reference Link Controls, Restrictions, and Field Reference Attachment Controls and Field Reference

Required Permissions

To view a task, you must be a member of the Readers group or your View work items in this node permission must be set to Allow. To create or modify a task, you must be a member of the Contributors group or your Edit work items in this node permission must be set to Allow. For more information, see Managing Permissions.

Defining a Task

Each team member can define tasks to represent the work that they must accomplish. For example, a developer can define development tasks to implement requirements. A tester can define test tasks to assign herself the job of writing and running test cases. A team member can also use tasks to signal regressions or to suggest that exploratory testing should be performed. Also, a team member can define a task to represent generic work for the project.

The form for task work items stores data in the fields and tabs that the following illustrations show:

When you define a task, you must define the Title. You can leave all other fields blank or accept their default values.

To define a single task

1. In the top section of the work item form, specify one or more of the following types of information:

   • In Title, verify and, if necessary, update the title to better define the area of work to be accomplished.

     The title provides a concise overview of the task to be completed. The title should be descriptive enough to allow the team to understand what area of the product is affected and how it is affected.

   • In the Assigned To list, choose the appropriate owner for the task.

     Note

     You can assign work items only to members of the Contributors group.

     If you leave the task unassigned, it is automatically assigned to you.

     Note

     You can assign only one resource to each task. If more than one team member will work on the same task, divide it into separate tasks or subtasks, and assign a single team member to each.

   • In the State list, leave the default value, Proposed.

     By default, the value of Reason is New. For more information about this field and how you can use it to track workflow, see Changing the State of a Task later in this topic.

   • In the Priority list, choose a value to specify the importance of the task on a scale of 1 to 4, 1 being most important.

     The default value is 2.

   • In the Triage list, choose the triage substate.

     Valid values are Pending (default), More Info, Info Received, and Triaged. This field identifies a level of triage for tasks that are in the Proposed state.

   • In the Blocked list, choose Yes if an issue is blocking progress toward the resolution of the task.

   • In the Area and Iteration lists, choose the appropriate area and iteration, or leave these fields blank to be assigned later during a planning meeting.

     Note

     The project administrator for each team project defines area and iteration paths for that project so that the team can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

   • In the Task Type list, choose the kind of task that a member of the team will implement.

     You can specify one of the following values: Corrective Action, Mitigation Action, or Planned.

   • In the Discipline list, choose the discipline of the team member who will complete the task. You can specify one of the following values: Analysis, User Experience, User Education, Development, or Test.

   • In Original Estimate, type a number that represents the hours of work that the task will take to complete.

     Important

     If you subdivide a task into subtasks, specify hours for the subtasks only. In Team Foundation reports, hours that you define for the subtask are rolled up as summary values for the parent task and the requirement. If you assign hours in both places, hours will be counted twice in those reports that track hours. For more information about how to correct this condition, see Address Inaccuracies Published for Summary Values.

   • In Completed work, type 0 to specify that no work has been completed.

   • In Remaining work, type the same value that you specified in Original Estimate.

     If your team is using the Original Estimate, Completed, and Remaining fields to determine team capacity, burndown, and burn rate, you will want to update the Completed and Remaining fields as you perform the work. Also, these fields are synchronized with Office Project, which you can use to schedule the project plan. For more information, see Scheduling Tasks and Assigning Resources Using Microsoft Project.

2. On the DESCRIPTION tab, type as much detail as you want to describe the work to be performed.

3. On the HISTORY tab, type comments that you want to capture as part of the historical record.

   Every time that a team member updates the work item, its history shows the date of the change, the team member who made the change, and the fields that changed.

4. On the OTHER tab, specify the following types of information:

   • In the Requires review list, choose Yes if the work requires a formal review.

     If you chose Yes, you should add a link to the Review work item from the task.

   • In the Requires test list, choose Yes if the work requires testing.

     If you chose Yes, you should add a link to the test case work item from the task.

   • In Integrated in, do not specify a build when you create the task. When you resolve it, type the name of the build that incorporates the code that the task created.

5. On the IMPLEMENTATION and ALL LINKS tabs, create links from the task to other work items, such as requirements, change requests, bugs, and issues.

   On the ATTACHMENTS tab, attach specifications, images, or other files that provide more details about the task to be completed.

   For more information, see the following sections later in this topic:

   • Linking the Task to Other Work Items

   • Adding Details, Attachments, or Hyperlinks to a Task

6. Choose Save Work Item.

   Note

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

Linking a Task to Other Work Items

By creating relationships between tasks and other work items, you can track dependencies and find relevant information more quickly. From the work item form for a task, you can create a work item that is automatically linked to the task, or you can create links to existing work items.

You use the Implementation and All Links tabs to create links for specific types of work items and specific types of links. For more information about the restrictions for each tab, see Linking Work Items (CMMI).

You link tasks to requirements to track the progress of work that the team has accomplished to complete each requirement.

To create a subtask or other work item and link it to a task

1. Open the work item form for the task, and perform one of the following actions:

   • To create and link to a requirement or task, choose the Implementation tab, and then choose New.

   • To link to one or more work items of other types, choose the All Links tab, and then choose New.

   The Add new Linked Work Item dialog box opens.

   

2. In the Link Type list, leave the default value, or choose one of the following options:

   • To create a link to a subtask, choose Child.

   • To create a link to a parent task or a requirement, choose Parent.

   • To create a link to a test case, choose Tested By.

   • To create a link to any other type of work items, choose Related or another type of link that represents the relationship that you want to track.

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

4. In Title, type a short but specific description.

5. (Optional) In Comment, type additional information.

6. Choose OK.

   A form for the type of work item that you specified opens with the information that you provided.

7. Specify the remaining fields as the following topics describe:

   • Bug (CMMI)

   • Change Request (CMMI)

   • Test Case

   • Issue (CMMI)

   • Risk (CMMI)

   • Review (CMMI)

8. Choose Save Work Item.

To link several existing work items to a task

1. Open the work item form for the task, and perform one of the following actions:

   • To link to one or more requirements or tasks, choose the Implementation tab, and then choose Link to.

   • To link to one or more work items of other types, choose the All Links tab, and then choose Link to.

   The Add Link to Task dialog box opens.

   

2. In the Link Type list, leave the default value, or choose one of the following options:

   • To create links to requirements, choose Parent.

   • To create links to subtasks, choose Child.

   • To create links to any other type of work item, choose Related or another type of link that represents the relationship that you want to track.

3. Choose Browse.

   The Choose Linked Work Items dialog box appears.

   

4. Type the items in Work item IDs, or browse for the items to which you want to link.

   You can also run a team query to locate the work items to which you want to link. These queries include Product Requirements, Open Tasks, Open Test Cases, Active Bugs, Change Requests, and Blocked Work Items.

5. Select the check box next to each work item that you want to link to the requirement.

   For more information, see Find Work Items to Link or Import.

6. (Optional) Type a description of the work items to which you are linking.

7. Choose OK, and then choose Save Work Item.

   Note

   Both the task and the work items to which you linked it are updated.

Adding Details, Attachments, or Hyperlinks to a Task

You can add information to a task that supports its implementation. You add details to tasks in the following ways:

• Type information in the Description field, History field, or both.

• Attach a file.

  For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

• Add a hyperlink to a Web site or to a file that is stored on a server or Web site.

To add details to a task

1. Choose the Details tab, and specify the following types of information:

   • In Description, type information.

   • In History, type information.

     You can format information to provide emphasis or capture a bulleted list. For more information, see Requirement Field Reference (CMMI).

2. Choose Save Work Item.

To add an attachment to a task

1. On the Attachments tab, perform one of the following actions:

   • Drag a file into the attachment area.

   • Choose or press CTRL-V to paste a file that you have copied.

   • Choose Add, and then choose Browse. In the Attachment dialog box, type or browse to the name of the file that you want to attach.

     (Optional) In the Comment box, you can type additional information about the attachment. To close the Attachment dialog box, choose OK.

2. Choose Save Work Item.

To add a hyperlink to a task

1. On the All Links tab, choose Link to.

   

2. In the Link Type list, choose Hyperlink.

3. In the Address box, perform one of the following actions:

   • If the link target is a Web site, type the URL, or copy it from your Internet browser and paste it into the Address box.

   • If the target is a server location, type the address in the form of a UNC name.

4. (Optional) In the Comment box, type additional information about the hyperlink.

5. Choose OK, and then choose Save Work Item.

Changing the State of a Task

A team can track the progress of a task by setting its State to one of the following values:

• Proposed

• Active

• Resolved

• Closed

When a team member creates a task, it is in the Proposed state by default. When the team accepts a task for the current iteration, the team changes the state of the task to Active and may create subtasks to implement it. When a team member completes the task, he changes its state from Active to Resolved. When the task work has been reviewed or verified, a team member changes its state from Resolved to Closed.

Any team member can change the state of a task. Also, a task can be closed for other reasons, as described later in this topic.

For more information about the data fields that you can use to track work item states, see Assignments, Workflow, and Planning (CMMI).

To close a task

1. Open the work item form for the task.

2. In the State list, choose Active, Resolved or Closed.

   • If you change the state from Proposed to Active, the Reason field changes to Accepted.

   • If you change the state from Active to Resolved, the Reason field changes to Complete.

   • If you change the state from Resolved to Closed, the Reason field changes to Review/Test Pass.

3. If you change the state from Active to Closed, choose an option that matches your intent in the Reason list.

   Valid options are Completed & Does Not Require Review/Test (default), Deferred, Cut, Over Taken by Events (OBE), and Cancelled.

4. Choose Save Work Item.

Typical workflow progression: A team member creates a task in the default state, Proposed, with the default reason, New. A team member changes the state from Proposed to Active with the default reason, Accepted. A team member changes the state from Active to Resolved when he has completed the work that the task represents. A team member changes the state from Resolved to Closed when the team has verified that the task is complete. Atypical transitions: A team member changes the state from Proposed to Closed with the default reason, Rejected. A team member changes the state from Active to Proposed with the default reason, Investigation. Complete. A team member determines that the task is not relevant or is out of scope and changes the state from Active to Closed. A review or verification test for the task fails. Therefore, a team member changes the state from Resolved to Active with the default reason Review/Test Failed. A team member determines that the task was closed in error and changes the state from Closed to Active.

Task State Diagram

Proposed (New)

Proposed tasks represent work that the team has not yet agreed must be performed. The team triages proposed tasks and either accepts or rejects them during the triage process.

The following data is automatically captured when a team member creates a task:

• Created By: Name of the team member who created the task.

• Created Date: Date and time when the task was created, as recorded by the server clock.

From Proposed to Active

A team member can change the state of a task from Proposed to Active for the reasons that the following table describes:

Reason	When to use	Additional actions to take
Accepted	When the triage committee approves the task for implementation in the current iteration.	Assign the task to the team member who will implement it.
Investigate	When the triage committee determines that the team must investigate the customer impact before deciding whether the task should be implemented.	Return the task to the Proposed state when the investigation is finished.

The following data is captured when a team member activates a task:

• Activated By: Name of the team member who activated the task.

• Activated Date: Date and time when the task was activated, as recorded by the server clock.

• State Change Date: Date and time when the state of the task was changed.

From Proposed to Closed

A team member can close a task that is in the Proposed state when the triage committee determines that the task cannot be implemented or a requirement or the product no longer needs it. The default reason is Rejected.

The following data is captured when a team member closes a task:

• Closed By: Name of the team member who closed the task.

• Closed Date: Date and time when the task was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the task was changed.

Active

An active task indicates that the team approved some element of work to be worked on. All active tasks should be assigned to an owner. The task remains active as long as the team is implementing it. The team member who has been assigned the task tracks the level of effort of the task by updating it with Completed and Remaining hours.

From Active to Resolved

A team member resolves an active task when the work that the task represents, such as developing code or writing documentation, is complete and now requires review through testing or peer reviews. The default reason is Complete and Requires Review/Test.

The following data is captured when a team member resolves an active task:

• Resolved By: Name of the team member who resolved the task.

• Resolved Date: Date and time when the task was resolved, as recorded by the server clock.

• State Change Date: Date and time when the state of the tasks was changed.

From Active to Closed

When a team member closes an active task, he must specify one of the reasons in the following table:

Reason	When to use	Additional actions to take
Completed and Does Not Require Review/Test (default)	If a task does not require review or test, it can be closed without the need to resolve it.	None.
Deferred	When the work cannot be implemented in the current iteration. You might defer a task because the team has insufficient time or because blocking issues prevent work.	Update the Iteration field to the correct iteration in which the task will be implemented, or set it to the backlog.
Cut	When the original work item, such as a requirement or issue, is closed and not to be worked on.	None.
Over Taken by Events (OBE)	A task is closed as Overtaken by Events when something has occurred that eliminates the need for it. Typically an untracked activity that accomplishes the same work as the task causes this situation to occur.	None.
Cancelled	When the work that the task represents no longer contributes to completion of the product.	None.

The following data is automatically captured when a team member closes a task:

• Closed By: Name of the team member who closed the task.

• Closed Date: Date and time when the task was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the task was changed.

Resolved

A resolved task is completed. The output from the task must be reviewed or tested, and if acceptable, closed. If the output is not acceptable, the task returns to the Active state for additional work. The team member who is assigned to work on the task resolves it when the work is complete. Or, a team member might determine that the task should be resolved or closed for other reasons.

From Resolved to Closed

A team member closes a task as Review/Test Passed if the review or test passes for the output of the task.

The following data is automatically captured when a team member closes a task:

• Closed By: Name of the team member who closed the task.

• Closed Date: Date and time when the task was closed, as recorded by the server clock.

• State Change Date: Date and time when the state of the task was changed.

From Resolved to Active

A team member can reactivate a task from a resolved state as Review/Test Failed if the review or test fails for the output of the task.

The following data is automatically captured when a team member reactivates a task from a resolved state:

• Activated By: Name of the team member who reactivated the task.

• Activated Date: Date and time when the task was reactivated, as recorded by the server clock.

Closed

A closed task means that no additional work is to be done on it for the current product version. A development task is closed after the code changes have been integrated. A test task is closed when all of the tests are complete for that area.

From Closed to Active

A team member can reactivate a closed task for the reasons that are described in the following table:

Reason	When to use	Additional actions to take
Reactivated (default)	When the task was deferred in a previous iteration and can now be completed in the current iteration.	Review the information and linked work items that are defined for the task to determine whether any data must be updated.
Closed in error	When a task was accidentally closed.	Review the information and linked work items that are defined for the task to determine whether any data must be updated.

When a team member reactivates a task, the Assigned To field is automatically populated with the name of the team member who closed the task. The following data is automatically captured when a team member reactivates a closed task:

• Activated By: Name of the team member who reactivated the task.

• Activated Date: Date and time when the task was reactivated, as recorded by the server clock.

• State Change Date: Date and time when the state of the task work item was changed.

See Also

Concepts

Requirement (CMMI)

Artifacts (CMMI)

Work Item Field Reference for Visual Studio ALM

Other Resources

Work Items and Workflow (CMMI)