Work Item Process - quality-manager/onboarding GitHub Wiki

Work Item Process

Defects

Required fields and states

Required fields for creating new defects:

Description: Include all the information required in the defect template.
Summary: Write a summary of the problem
Found In: What release was this problem found?
How found: Explain what you were doing while you found this problem.
Severity: Estimated severity. Note, this is a suggestion for severity for development and can be changed at any given time. See: Work Item Severity Priority section.

Transition from "New" to "Triage":

Filed Against: What is the component affected because of this problem.
Owned by: Owner of the defect
Planned for: Release or iteration where the defect will be resolved.

Transition from "Triage" to "In progress":

Estimate: Estimate on how long this defect will take to fix.

Transition from "Triage" to "In Review:

Change summary: At the time the defect is resolved, add a high level summary of the problem analysis and the fix.
1 Approval: Approver must be a ETM Development Team Lead approval.
1 Review: Must be a developer that is knowledgeable in this area.

Transition from "In review" to "Resolved >> Fixed"

1 Approved approval: : Approver must be a ETM Development Team Lead approval.
1 Approved review: Must be a developer that is knowledgeable in this area.
Streams delivered: Stream where the change is being delivered to. Normally "Mainline".
Test Strategy: When a developer fixes a defect, identify any special instructions for how the fix should be tested.
Verification steps: Explain how this was tested to affected problem was fixed.
Translation: No PII changes if no strings were modified, or TVT test case required.

Transition from "Triaged" to "Tracked Elsewhere"

Add a comment with the link to the defect that is tracking this problem and the product/application where this defect is tracked.
Add an "Affected by Defect" link to the defect that is tracking this problem.
Assign ("Owned By") the work item to the ETM Development Team Lead.
Change the status from "Triaged" to "Tracked Elsewhere".
Set the Planned For to "Backlog".

Transition from "Tracked Elsewhere" to "Resolved >> Tracked Elsewhere"

Add a comment indicating that the defect that is tracking this problem is resolved (but not fixed).
Change the status from "Triaged" to "Resolved".
Set the resolution to "Tracked Elsewhere".
Set the Planned For to the release/sprint where the Tracked Elsewhere defect was resolved.

Transition from "Tracked Elsewhere" to "Resolved >> Resolved Elsewhere"

Add a comment indicating that the defect that is tracking this problem is fixed.
Change the status from "Triaged" to "Resolved".
Set the resolution to "Resolved Elsewhere".
Set the Planned For to the release/sprint where the Tracked Elsewhere defect was resolved.

When fixing APAR defects

Defects that contain an APAR in "Apar ID" field must also have "Backport Information" filled in.

For regressions

Regression From: The release or iteration (if introduced in the current development release) before the regression was introduced.
Depends On: Link to the RFE/enhancement/plan item/story/task/defect that introduced the regression.

For tracked elsewhere

Add a comment with the link to the defect that is tracking this problem and the product/application where this defect is tracked.
Add an "Affected by Defect" link to the defect that is tracking this problem.
Assign ("Owned By") the work item to the ETM Development Team Lead.
Set the planned for to "Backlog".

For duplicated defects

Add a "Duplicated by" link pointing to the work item being duplicated.

Process for defects

The ETM Development Team Lead will triage and assign defects during 7.0.2.
Developer will start investigating defect, change status to “In progress”
Work on changes
Or close as Won’t fix/explain reasoning
When change is ready, change state to “In review”, add 1 review (or more) and 1 approval
When defect is approved, fill required fields (see required fields section)
Send to state “resolved” >> “Fixed”.

RFEs

[Product Management] When a RFE is Under consideration move to state "Prioritize", this state is intended to denote we are considering this enhancement but has not been assigned yet to a developer.

[Product Management] Once the RFE is delivered/resolved, leave the RFE open for Offering Management to resolve after the current release GAs.

[Product Management] When a RFE is fixed by an existing fixed defect, close the RFE as a Defect, and update the following in the RFE:

Planned For: Release of the fixed defect.
Owned By: Owner of the fixed defect.
Priority: Priority of the fixed defect.
Time Spent: The amount of days/hours spent working on the fixed defect.
Depends On: Link to the fixed defect.
Associated Work Item: Link to the fixed defect.
Resolved By: Link to the fixed defect.

Note: RFEs are only resolved after General Availability (GA) of the release containing the fixed defect since resolution alerts the RFE community about the availability of the RFE.

Note: RFEs must use a version number (no iteration) in the Planned For field.

[Product Management] When a RFE is triaged, update the following in the RFE:

Status: Set to Uncommitted Candidate, Close, Need More Information, Under Consideration, or Planned for Future Release.
Priority: Priority of the RFE.

[Product Management] When a RFE is a duplicate of a new or existing unresolved enhancement/plan item/story/task, update the following in the RFE:

Depends On: Link to the enhancement/plan item/story/task.

Note: RFEs can not be closed as a duplicate of an enhancement/plan item/story/task.

[Product Management] When a RFE is a duplicate of a new or existing RFE, close the RFE as Duplicate, and update the following in the RFE:

Duplicated By: Link to the duplicate RFE.
Owned By: Owner of the duplicate RFE.
Priority: Priority of the duplicate RFE.

[Product Management] When a RFE is fixed by an existing fixed enhancement/plan item/story/task, close the RFE as Delivered, and update the following in the RFE:

Planned For: Release of the fixed enhancement/plan item/story/task.
Owned By: Owner of the fixed enhancement/plan item/story/task.
Time Spent: The amount of days/hours spent working on the fixed enhancement/plan item/story/task.
Depends On: Link to the fixed enhancement/plan item/story/task.
Associated Work Item: Link to the fixed enhancement/plan item/story/task.
Resolved By: Link to the fixed enhancement/plan item/story/task.

Note: RFEs are only resolved after General Availability (GA) of the release containing the fixed RFE/enhancement/plan item/story/task since resolution alerts the RFE community about the availability of the RFE.

Note: RFEs must use a version number (no iteration) in the Planned For field.

[Development] When a RFE (status: Uncommitted Candidate) implementation is started, create an enhancement, and update the following in the enhancement:

Planned For: Current release/iteration.
Owned By: Owner of the RFE.
Priority: Priority of the RFE.
Blocks: Link to the RFE.

Note: RFEs should not be used to deliver code changes.

Enhancements

[Product Management] When an enhancement is under consideration for current release, move to status "Prioritizing".

[Product Management] Once the enhancement is delivered/resolved, leave the enhancement open for Offering Management to resolve after the current release GAs.

[Development] When an enhancement is triaged and assigned to you, update the field "Estimate". Note: As part of the previous point when the enhancement is under consideration you can be asked to add an estimate too.

[Development] When an enhancement implementation is finished, resolve the enhancement as Fixed, and update the following in the enhancement:

Comment: Summarize the design, implementation, and testing/results.
Time Spent: The amount of days/hours spent working on the enhancement.

[Development] When an enhancement is a duplicate of an unresolved enhancement/plan item/story/task, resolve the enhancement as Duplicate and update the following in the enhancement:

Planned For: Current release/iteration.
Owned By: Owner of the duplicate enhancement/plan item/story/task.
Priority: Priority of the duplicate enhancement/plan item/story/task.
Duplicate Of: Link to the duplicate enhancement/plan item/story/task.

[Development] When an enhancement is fixed by a fixed enhancement/plan item/story/task, resolve the enhancement as Fixed Indirectly, and update the following in the enhancement:

Planned For: Release/iteration of the fixed enhancement/plan item/story/task.
Owned By: Owner of the fixed enhancement/plan item/story/task.
Priority: Priority of the fixed enhancement/plan item/story/task.
Resolved By: Link to the fixed enhancement/plan item/story/task.

Epic

Epics are plan items (Summary contains the [Epic] prefix) for features that span multiple releases. Epics contains plan item and related work items. Epics should only have children (link type: Children) that are plan items. If there are enhancements, RFEs, and defects related to the plan item, they should be linked as related (link type: Related). Note, any children that are resolved as Invalid should be linked as related (link type: Related) and not children (link type: Children) since the children make up the epic and invalid children do not accurately reflect the state of the epic. Epics should always be planned for the backlog.
See Epic tags.

Plan Items

[Development] When a plan item is created, update the following in the plan item:

Filed Against: Initially Feature Development. Note: Once the plan item is in plan, create a new Filed Against category with a meaningful name for the plan item (include the plan item ID and summary in the description of the new Filed Against category) and assign the new Filed Against category to the plan item and all decedent work items. Once the plan item is GAed, archive the new Filed Against category.

[Development] When a plan item is worked, remember:

Plan items should only have children (link type: Children) that are stories. There should be a story for each sprint of the release and the entire Done Criteria on the plan item should be covered by the stories. Stories should have children (link type: Children) that are tasks. If there are enhancements, RFEs, and defects related to the plan item, they should be linked as related (link type: Related). If an enhancement is part of a plan item, convert it to a story with child tasks. Note, any children that are resolved as Invalid should be linked as related (link type: Related) and not children (link type: Children) since the children make up the plan item and invalid children do not accurately reflect the state of the plan item. Note, all children should be planned for a sprint in the current release. Any children planned for the backlog, should not be children of the plan item or planned for a sprint in the current release.
Plan items always have the Planned For field set to the release (e.g. 7.0.1) but child stories, grandchild tasks, and related defects have the Planned For field set to an iteration (e.g. 7.0.1 M1) of the release.
Always use the Feature Development/<feature category> in the Filed Against field for the plan item, child stories, grandchild tasks, and related defects except for product documentation tasks, which should be filed against Documentation.
Before a plan item is marked as Done, all child stories, grandchild tasks, and related defects should be resolved (or deferred to a future release with the necessary approval(s)) and the Checklist completed.
When using the story template, that creates child tasks with a template Summary (e.g. Author TVT for <X>), update the summary to a meaningful summary.

Note: Tasks include New and Noteworthy work items.

Note: Plan items should not be used to deliver code changes.

Tip: To see the child stories and grandchild tasks of a plan item:

In the EWM Eclipse client, open the Work Items view.
Click View Menu >> Relationships >> Children >> OK.
Search for the plan item using the Summary text.
In the Summary column, recursively expand the arrow to the left of the Summary text. Unfortunately, there is no Expand All support.

[Development] When a plan item is completed:

Fill the checklist section with information regarding your plan item
Move the plan item to status: Done.

Stories

[Development] When a story is a duplicate of an enhancement/plan item/story/task, resolve the story as Duplicate, resolve all children as Won't Fix, and update the following in the story:

Planned For: Current release/iteration.
Owned By: Owner of the duplicate enhancement/plan item/story/task.
Priority: Priority of the duplicate enhancement/plan item/story/task.
Duplicate Of: Link to the duplicate enhancement/plan item/story/task.

Note: Stories should not be used to deliver code changes.

New and Noteworthy Tasks

[Development] Created only for New and Noteworthy entries for plan items, stories, enhancements or RFEs. Note, product documentation additions/updates should be opened as development-tasks, Filed Against Documentation. Update the following in the New and Noteworthy task:

Parent: Link to the source plan item, story, enhancement or RFE.

Release Notes

Create a Task-development in the Rational Quality Manager Project Area. This can be done using "Create from template" option while creating the workitem and choosing "Release Note Task". We need to provide the "Planned for" details and we can create the workitem.
Add the original defect as parent for newly created Task-Development workitem.
Add the content for the Workaround/Limitation into the description of the Task-Development.
Get the content technically verified by development team member.
Once we have Technical approval, get the content reviewed by the UA team.
Once we have UA approval, get final approval by Technical Team Lead.
Once all Approval/Review has been done, UA team will publish the Workaround/Limitation to the Jazz.net release notes page for applicable product version.