Control – SDLC – Pivotal – Request Tracker Matrix
Control SDLC
Change Requirements • Requestor / Stakeholder
creates a Story
Change Requirements Further Story Elaboration
User Acceptance Testing • Requestor / Stakeholder
defines Story Test Plans
Change Requirements • Estimate
Change Requirements • Feature Prioritization occurs •
during Iteration or Release
Planning and/or Schedule
Elaboration and Estimation
Meeting
• Development
User Acceptance Testing • Stakeholder / Requestor • If “Approved,” Stakeholder/Requestor hits
tests changes usually in Dev
environment, sometimes in QA
environment. • If “Reject” button is hit, the Story goes back into
1
Pivotal (& Request Tracker)
• Enters into Pivotal, where stored in “IceBox”
bucket in Pivotal.
• While in IceBox
• Acceptance Criteria (test plans) is included in
Story when it is entered into Pivotal.
• While in Ice Box – sometimes
Once meeting occurs, Stories move to “Backlog”
bucket in Pivotal, which is the official approval of
the Change Request to be worked.
• Backlog reflects current prioritization and is
controlled by the business.
• Developer hits “Start” which means work has
begun.
• Story is moved to “Current” bucket in Pivotal.
• Once development is complete – developer hits
“Finish” button, which means it is ready for
Stakeholder review/testing.
• Email is automatically sent to Requestor
indicating ready to test.
• Remains in “Current” bucket in Pivotal, with an
indication that it is “Delivered” meaning ready for
testing by Stakeholder.
“Approve” button, which is indication that it is ready
for QA team to test.
a Restart state for developer to restart. See above
under Development.
• Release Markers here or sooner to indicate which
Stories are included in a Release.
 Control – SDLC – Pivotal – Request Tracker Matrix

User Acceptance Testing • QA conducts testing – unit – • Remains in “Current” bucket through testing.
usually in Dev • If bugs are found, “Defect” Story entered into
• Regression and Integrity Pivotal, then Story is “Started,” then put back into
testing of entire Release in QA. the Release (or left in the Backlog if taken of
• Standard Critical Path Release. When testing completed, QA hits “Finish”
document for that particular button which indicates their testing sign-off for the
product is used as the QA Test Release.
Plan.
• If defects found, they are
sent back to developer to be
fixed.
• When testing is completed,
they sign off.
Implementation into • Once testing is completed, • QA creates a staging ticket in Request Tracker
Production Deployment by Infrastructure (not Pivotal) to stage the release into production.
Team can occur. Once Release is migrated to production, QA will
perform Critical Path Testing and update staging
ticket with test results. Infrastructure will then
closes ticket and email is sent to QA requestor and
appropriate management team indicating release
has been migrated.
•
Communication • Appropriate project manager Action Item: This email needs to be retained.
sends a communication to
business owners and users
(where appropriate) with
highlights of what was included
in the release.

2
 Control – SDLC – Pivotal – Request Tracker Matrix

Post Implementation • If any problems were

Reviews encountered during the
implementation, there may be a
meeting reviewing the
challenges, so the process can
continue to be improved.
• Retrospective meetings are
scheduled on occasion, but on a
case-by-case basis as needed.
• No meetings are held if all
went fairly well.