|
What is CollabNet’s Product Issue
Council?
The "Product Issue Council" (PIC for short) is
a group of cross-functional team members from CTF Engineering, CERT, Support,
and Ops who meet on a weekly basis to make decisions about the disposition of
support/cert/ops-driven product defects (CRIs) and other tactical
customer-driven change requests (mini-CRUSs). The idea is to give people
outside of Product Management a chance to represent their constituents.
What are the PIC’s primary objectives?
· Make
decisions about CRIs and CRUSs that have been escalated for discussion
· Accept
or reject CRIs and CRUSs that have been requested for release deferral
· Accept
or reject CRIs and CRUSs being proposed as Engineering Change Orders (ECOs)
· Accept
or reject CRIs and CRUSs that have been requested for product patches
· Decide
when a patch is merited, and coordinate schedule & delivery resources
What will we actually do in our weekly
meetings?
Review the list of CRI shadow artifacts from the “Ranked Customer-Reported Defects” folder which is under the “PO’s
Inbox” folder in the TeamForge Product Development project,
and make various decisions based on PIC objectives. Sometimes this will
result in pulling things into release, other times kicking things out.
Furthermore, the genesis and ultimate decision to proceed with release hotfixes
and patches will be defined, considered, scheduled, and coordinated in this
meeting.
We will also review the list of CRUS shadow artifacts
from the “PO’s Inbox” folder in the
TeamForge Product Development project.
The council is “exception-oriented”, meaning we will only
review the artifacts that have been tagged for PIC review.
What is the new PIC process?
For
the customer-reported defects:
· CERT
creates a CRI shadow artifact (CRD) and drops it to the “Shadow Customer-Reported Defects”
tracker in the TeamForge Product Development project.
· CERT/Support/Ops
drops and ranks the CRDs that they want PO to include in the active TeamForge
release in the “Ranked Customer-Reported Defects”
folder which is under the “PO’s Inbox” folder in the
TeamForge Product Development project. CERT/Support/Ops specify the
artifacts that they want to be discussed at the PIC meeting by updating the
“Tag” field with “PIC-XXX”1.
· Based
on the ranking, PO decides which CRD(s) can be completed in the active
release iteration and drops them in that iteration folder.
· Once
a CRD is taken into the active release iteration, CERT/Support/Ops updates the
original CRI artifact “Status” field to “In Next Release”.
· Once
a CRD is fixed in the active release iteration, QA completes the validation and
marks it as “Closed”. QA also updates the CRD “Fixed In Release” field
with the release number. CERT/Support/Ops updates the original CRI “Status”
field to “Fixed”.
· In
cases where a CRD is taken out of an active release iteration and it is not
moved into the next iteration (this could happen if the effort required is too
much to be accommodated in the release or it is the last iteration already), PO
moves the CRD back into the “Ranked Customer-Reported Defects”
folder and updates the “Tag” field with “PIC-XXX”1 for discussion at
the PIC meeting. If the group jointly decides to take the CRD out of the
release, then CERT/Support/Ops updates the original CRI artifact “Status” field
to “Open” and removes the “PIC-XXX”1 marker in the “Tag” field.
For
the tactical customer-driven change requests (mini- CRUSs):
· PO
creates a shadow CRUS and drops it to the “PO’s
Inbox” folder in the “TeamForge Product Development”
project.
· Once
a shadow CRUS is taken into the active release iteration, PO updates the
original CRUS “PM Status” field to “PRO - Productized” and the “Status” field
to “In Next Release”.
· In
cases where a shadow CRUS is taken out of an active release iteration and it is
not moved into the next iteration (this could happen if the effort required is
too much to be accommodated in the release or it is the last iteration
already), PO moves the CRUS back into the “PO’s
Inbox” folder. PO specifies the artifacts that
he/she wants to be discussed at the PIC meeting by updating the “Tag” field
with “PIC-XXX”1. If the group jointly decides to take the
shadow CRUS out of the release, then PO updates the original CRUS “PM Status”
field to its original value (e.g., “ITP – In the Plan”) and “Status” field to
“Open” and removes the “PIC-XXX”1 marker in the “Tag” field.
1PIC-XXX: The Tag field will be changed
to a pull-down menu, with the following initial values and will be updated as
needed:
· PIC-DEFER
=> To nominate deferring the artifact to the next release
· PIC-INCLUDE
=> To nominate including the artifact to the current release
· PIC-ESCALATE
=> To indicate the artifact needs to be addressed urgently
|
