Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

The Definition of Done (DoD) applies for all user stories that the team is working on. In contrast to this, Acceptance Criteria are defined specifically per User Story as required by the Definition of Ready (DoR).

This should clarify how DoR, Acceptance Criteria and DoD relate to each other.



Salesforce team existing stuff

Barbara's propositions

SAFe 6.0 (and more)

DOR (Ready for Sprint Planning)

  1. US has acceptance criteria?
  2. US Who, What and Why are clear? (+info)
  3. US Does it have clear business value?
  4. US is Understood by the squad?
  5. US is feasible? 
  6. US impacts identified?
  7. US security addressed and validated?
  8. US has dependencies Identified ? (Eg. someone from an external will be available to work on it during the sprint)same as dependencies
  9. US blockers are finished or can be done at same time (sprint)?same as dependencies
  10. US is estimated?
  11. US is small enough?
  12. US will require non regression testing?
  13. Blockers are completed or to be completed on time before sprint ends? same as dependencies

Definition of Ready 

Ensures that a user story is fully prepared for development, minimizing the risk of rework or delays. A user story is considered "ready §§" when it meets the following criteria:

  • Clear and Concise: The user story is well-written, with a clear description of what needs to be done, including the desired outcome.
  • Acceptance Criteria Defined: Acceptance criteria are specific, measurable, and testable conditions that must be met:
  • Prioritized: The story is prioritized in the backlog, and its priority is understood by the team.
  • Dependencies Identified: All external dependencies (on other teams, systems, or stories) are identified:
  • Sufficiently Sized: The story is small enough to be completed within a single sprint and is estimated by the team. If it is too large, it should be split into smaller, more manageable stories.
  • Team Understanding: The development team fully understands the story and what is required to complete it. Any questions or ambiguities have been addressed:
  • Technical Aspects Considered: Any technical requirements, architectural considerations, or constraints have been identified and discussed.
  • Ready for Testing: The story includes all necessary test cases, and the testing strategy is clear.

(nothing clear from SAFe 6.0, but from PO trainings & experience)

Definition and why it's important:

Helps prevent problems from the start.

Need to find a balance between list of items to be prepared/ready in advance and space for team members to work in an agile way.

  • Item is estimated
  • Item can be finished in 1 interation
  • Acceptance criteria provided and understood
  • Item follows the INVEST principle (1 Independent / 2 Negotiable / 3 Valuable / 4 Estimable / 5 Small / 6 Testable )

DOD (close the sprint)

  1. US has DA approval? (should be part of Technical aspects in DoR )
  2. Dependent ‘has to be finish together’ stories completed
  3. Code Review was done?
  4. Unit Tests passed?
  5. Test class coverage >85% (if code needed)
  6. Development/Configuration deployed into Proj_INT? (local env)
  7. PDS identified and Written into Jira? (but may be too local to CRM teams)
  8. Functional Test scripts written by US?
  9. NRT and Sanity Test scripts identified, if needed created and linked with US. 
  10. All acceptance criteria are passed?
  11. Functional Documentation written
  12. Technical Documentation written
  13. A demo of US was done to the PO?
  14. Product Owner reviewed and accepted?

Definition of Done 

Is a shared understanding within the team of what it means for a user story or task to be complete. A user story is considered "done" when it meets the following criteria:

  • All Acceptance Criteria Met: The user story fulfills all the acceptance criteria outlined in the Definition of Ready.
  • Code Complete: The code has been written, reviewed, and meets the team's coding standards. 
  • Code Reviewed: The code has been peer-reviewed, and all identified issues have been resolved.
  • Tested All unit tests, integration tests, and any other relevant tests have been written, executed, and passed. The code should be free of critical bugs.
  • Deployed to ???? : The story has been deployed to a staging environment and verified as functioning as expected
  • Documentation Updated: Any necessary documentation, including user documentation, technical documentation, or inline code comments, has been updated.
  • User Acceptance: If applicable, the feature has been demonstrated to stakeholders, and feedback has been incorporated.
  • No Open Defects: There are no open defects or bugs related to the user story. Any minor issues are documented and agreed upon to be handled separately.


Team Increment (sprint)

  • Stories satisfy Acceptance Criteria
  • Acceptance tests passed (automated where practical)
  • Unit tests
  • Cumulative unit tests passed
  • Assets are under version control
  • Engineering standards followed
  • NFRs met
  • No must-fix defects
  • Stories accepted by PO

DODD (release train)

  1. Final release updated?
  2. Development/Configuration deployed into INT?
  3. No blocking defects in INT?
  4. Deployed to UAT?
  5. US accepted by the Business?
  6. Non-regression tests completed in UAT?
  7. No blocking defects in UAT?


Release level

  • All capabilities done and meet Acceptance Criteria
  • End-to-end integration and solutions V&V (Verification & Validation) done
  • Regression testing done
  • NFRs met
  • No must-fix defects
  • Release documentation complete
  • All standards met
  • Approved by Solution & Release Management
  • No labels