Control – SDLC – Pivotal – Request Tracker MatrixApril 11, 2023

Control SDLC Pivotal (& Request Tracker)Change Requirements Requestor / Stakeholder creates a

Story Enters into Pivotal, where stored in “IceBox” bucket in

Pivotal.Change Requirements Further Story Elaboration While in IceBoxUser Acceptance Testing Requestor / Stakeholder defines

Story Test Plans Acceptance Criteria (test plans) is included in Story when it is

entered into Pivotal.Change Requirements Estimate While in Ice Box – sometimesChange Requirements Feature Prioritization occurs during

Iteration or Release Planning and/or Schedule Elaboration and Estimation Meeting

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.

Development 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.

User Acceptance Testing Stakeholder / Requestor tests changes usually in Dev environment, sometimes in QA environment.

If “Approved,” Stakeholder/Requestor hits “Approve” button, which is indication that it is ready for QA team to test.

If “Reject” button is hit, the Story goes back into 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.

User Acceptance Testing QA conducts testing – unit – usually in Dev

Regression and Integrity testing of entire Release in QA.

Remains in “Current” bucket through testing. If bugs are found, “Defect” Story entered into Pivotal, then

Story is “Started,” then put back into the Release (or left in the Backlog if taken of Release. When testing completed, QA

1

Control – SDLC – Pivotal – Request Tracker MatrixApril 11, 2023

Standard Critical Path document for that particular product is used as the QA Test Plan.

If defects found, they are sent back to developer to be fixed.

When testing is completed, they sign off.

hits “Finish” button which indicates their testing sign-off for the Release.

Implementation into Production Once testing is completed, Deployment by Infrastructure Team can occur.

QA creates a staging ticket in Request Tracker (not Pivotal) to stage the release into production. 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 sends

a communication to business owners and users (where appropriate) with highlights of what was included in the release.

Action Item: This email needs to be retained.

Post Implementation Reviews If any problems were 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.

2