In some cases, the submitter of
a work item speaks with the developer responsible for the functional
area and assigns the work item to that developer. However, it is also
common that the submitter leaves the work item unassigned, and a member
of the team area associated with the work item category must triage
the work item.
About this task
Triaging is the process of analyzing work items that have
been submitted to add them to an iteration, assign ownership, and
set priority To triage work items:
To triage a work item, first run a query that retrieves
work items that have been submitted but not assigned to a specific
owner. In the Work Items view, double-click
an entry in the results grid to open it.
Verify that the Filed Against field
is set correctly. If the work item belongs to a different category,
change the Filed Against field. If you are not a member of the team
associated with the new category, click Save to
save the change. Otherwise, continue.
Click the Find Potential Duplicates icon
to see if another work item has already been submitted about the same
issue. If a duplicate work item exists, set the state of one of the
work items to Resolved and set its Resolution
to Duplicate.
The Owned By property lists all
members of the team area associated with the work item category. Select
an owner from that list or click More at the
bottom of the list to search for a member of another team. Optionally,
select a priority level. The priority level identifies the importance
of the work item from the owning team's perspective. Optionally, set
the Planned For property to a planned iteration
for resolving the work item. Optionally enter a value in the Due property.
To add a comment, click Add Comment in the Discussion section
and enter your text.
Click the Approvals tab to add an
approval. An approval is a request for other users to review, approve,
or verify the work that is done to resolve the work item. Click New
Approval and specify the type (Approval, Review, or Verification)
and due date. Click Add Approver to specify
the user or users responsible for approving the resolution. You might
want to create different approval types for different users. For example,
you might want to have a lead developer review the owner's proposed
resolution, and a test engineer validate the delivered fix.
Another
use of approvals is to remind team members to perform a common task.
For example, you might create a work item for developers to update
the copyright year in their files. You could add each developer as
an approver to the work item. When they finish making the change in
their files, they change the State for their approval to Approved.