...
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 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 |
Bugs
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 Jira6 | Agree with the Customer the FSA especially if there are any follow-up actions needed BEFORE closing the bug | |
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 necessary documentation |
3 | Consider End2End integration test is done and completed according to CPS Ways of Working (WoW) |
4 | Agree delivery of overall epic with stakeholders 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 |
...