CURRENT
DoD for a typical User Story
- Code reviewed and Merged
- Release Notes updated
- Add Jira reference to relevant section ('Features'). The slogan does NOT have to be identical to the Jira, it often could/should be a better description of the change
- Highlight backward incompatible changes if applicable
- Latest Yaml files copied to /docs folder (see step2 on CPS Release Process)
- Acceptance Criteria of the User Story have been met
- New functionality Demoed to Team and Stakeholders
- Uploaded recording of demo to CPS User Story Demos
Additional checks for a Bug
- Consider cherry-pick for previous release(s)
- Add Jira reference to relevant section in read the docs (RTD) ('Bug Fixes' and possibly 'Security Notes'). The slogan does NOT have to be identical to the Jira, it often could/should be a better description of the change
Complete an Fault Slip-through Analysis (FSA) and add as a comment in Jira
Agree with Customer the FSA especially if there are any follow-up actions needed BEFORE closing the bug
PROPOSED DOD
Table of Contents |
---|
The definition of Done (DoD) represents the checklist that CPS agile team must meet before it can consider closing relevant work items such as (stories, bugs and epic).
NOTE: PO and PTL Can accept and reject perceived completed work items if any of DOD is not met
User Story
DoD for User Story | |
---|---|
1 | Code reviewed and Merged shall follow the code review process as listed in CPS Ways of Working (WoW) |
2 | Latest Yaml files copied to /docs folder (see step2 on CPS Release Process) |
3 | Consider necessary documentation |
4 | Release Notes updated
|
5 | New Consider new functionality Demoed to Team and Stakeholders
|
6 | Update Jira with comments even if it's just a 1 liner of code that was input for the story |
7 | All Acceptance Criteria of the User Story have been met |
...
Additional Checks for Bugs | |||
---|---|---|---|
1 | Add Jira reference to the relevant section in read the docs (RTD) ('Bug Fixes' and possibly 'Security Notes'). The slogan does NOT have to be identical to the Jira, it often could/should be a better description of the change | ||
2 | Move Jira to submitted when code is being reviewed by other team members | ||
3 | Ensure Jira tickets is updated at least once a day with a comment about the progress that day. | ||
4 | Consider cherry-picking for previous major release | ||
5 | Complete a Fault Slip-through Analysis (FSA) and add as a comment in Jira | ||
6 | Agree with the Customer the FSA especially if there are any follow-up actions needed BEFORE closing the bug | ||
7 | Agree with the reporter that bugs can be closed. | 6 | Complete a Fault Slip-through Analysis (FSA) and add as a comment in Jira |
Epic
DoD for Epic | |
---|---|
1 | Consider End2End Demo for the epic |
2 | Consider Doublecheck necessary documentation and release note |
3 | Consider End2End integration test is /acceptance testing must have been done and completed according to CPS Ways of Working (WoW) |
4 | Agree delivery of overall epic with stakeholders in planning meeting |
5 | PO to state overall/summary of the value each feature added during epic completion. Create a link for PO and PTL use in release note updates for external stakeholders |
Recommend having DoD handy - possibly print it out or have a sticker on your working desk
...
Expand | ||
---|---|---|
| ||
Fault Slip Through Analysis
|
...
Expand | ||
---|---|---|
| ||
|
NOTE: PO and PTL Can accept and reject perceived completed work items if any of DOD is not met