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

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

All Acceptance Criteria of the User Story have been met

3

Latest Yaml files copied to /docs folder (see step2 on CPS Release Process)

4

Consider necessary documentation

5

Consider Release Notes updates

    1. Add Jira reference to the 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
    2. Highlight backward incompatible changes if applicable
6

Consider new functionality Demoed to Team and Stakeholders

    1. Uploaded recording of the demo to CPS User Story Demos
7

Update Jira with comments even if it's just a 1 liner of code that was input for the story


Bugs

Please also note these: Bug Reporting Guidelines for CPS


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.

Epic


DoD for Epic

1

Consider End2End Demo for the epic

2

Doublecheck necessary documentation and release notes

3

End2End integration/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

Fault Slip Through Analysis

  • Bug Category: <choose option>
  • Reason for Slippage: <choose option>
  • Action needed to prevent slippage: <free text>
  • Phase it should have been found in: <choose option>
  • Category of test it should have been found in: <choose option>
  • Description of test it should have been found in: <free text>
  • Link(s) To JIRA improvement record:  <free text>
  1. Bug Category:
    1. 3PP

    2. Critical Vulnerability

    3. Documentation

    4. Functional

    5. High Availability

    6. Install

    7. Logging

    8. Performance

    9. Robustness

    10. Rollback

    11. Scalability

    12. Security

    13. Testware/CI

    14. Upgrade
  2. Reason for Slippage: 
    1. Insufficient test coverage
    2. Intermittent Fault/Timing Issue
    3. Missed impact
    4. Missed in code review
    5. Missed in design analysis
    6. Missed in document review
    7. Missing requirement
    8. Unrealistic Development timeframe
    9. Late requirement: insufficient analysis
    10. Environment
  3. Action needed to prevent slippage: <free text>
  4. Phase it should have been found in: 
    1. Design
    2. Review
    3. Automated (unit) Test
    4. Microservice CI (CIST)
    5. Release
  5. Category of test it should have been found in:
    1. Unit
    2. Integration Test
    3. Performance
  6. Description of test it should have been found in: <free text>
  7. Link(s) To JIRA improvement record: <free text>
    (ensure there are linked JIra's for any follow-up/preventive actions)

NOTE: PO and PTL Can accept and reject perceived completed work items if any of DOD is not met


  • No labels