Sprint Progression
| Gliffy | ||||
|---|---|---|---|---|
|
This isn't a precisely linear process because it involves feedback (see above diagram), but it represents the general order.
Status | Activity | Description | Duration |
|---|---|---|---|
() | Submit change request | Open a build/test change request in https://yale.service-now.com/, assign to | minutes |
() | Schedule code review | this should happen after initial handover and before release | minutes |
() | Build | Begin work in dev | days |
() | Developer tests | Ensure all pushed to and unit tested in test | hours |
() | Push to Test | Hand over initial requirements list for functional & QA validation | minutes |
() | Testing | UAT & product testing (testing instance) | days |
() | Conduct code review | Shouldn't take long, just basic validation of approach and docs | hours |
() | Defect fixes | Iterative follow-up work in dev, test for defect resolution | days |
() | Code Freeze | Identify changes & updates that have passed both testing regimes. Push to preproduction. | hours |
() | Regression Testing | QA group conducts regression testing in preproduction | minutes |
() | Go/no-go | Decide to push to production. | minutes |
() | Production deployment | Push to prd. | hours |
() | Production rollback | If applicable; follow ServiceNow Rollback Procedure. | hours |
() | Clone | clone from prd to: pre, trn, and tst for after release | hours |
() | Push to Test | re-push outstanding, ready work back to test | hours |
() | Notify stakeholders | send out email w/ summary status & link to release documentation, close out RFC and cancel clone requests, if rollback or no-go. | minutes |
() | Target/Actuals | Deliver target/actuals using estimator spreadsheet or equivalent | hours |
...