Scribd
Upload
57 views7 pages

Definition of Done

This document discusses the importance of defining a "Definition of Done" (DOD) for Scrum projects. It explains that a DOD provides clarity on when work is considered complete by establishing checklists for user stories, sprints, and releases. This reduces uncertainty and helps ensure work is fully tested and meets requirements before being delivered. Examples of DOD criteria are also provided.

Uploaded by

jm.doumont
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
57 views7 pages

Definition of Done

This document discusses the importance of defining a "Definition of Done" (DOD) for Scrum projects. It explains that a DOD provides clarity on when work is considered complete by establishing checklists for user stories, sprints, and releases. This reduces uncertainty and helps ensure work is fully tested and meets requirements before being delivered. Examples of DOD criteria are also provided.

Uploaded by

jm.doumont
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 7

DOD - Definition Of Done

September 30, 2014


Typical scenario

Sprint review
 Demo of user story
 Feature X works exactly as described , in the user story, before & during the
sprint, based on Acceptance Criteria
 However, when Product Owner sees feature X in action, please add some
tweaks or take into account this & that

Accept or Reject
 Do we consider the original user story done and create a new user story for
next sprint(s)?
 Do we consider the original user story unfinished, put it back into the Product
Backlog with more detailed requirements for the next sprint?

2 Credoc Deed Preparation Team © 2014


Solution

 Define a Definition Of Done (DOD)


 evolve every sprint
 simple checklist that belongs to the team
 used as a filter when deciding what is ready to be
delivered
 the rules of the game

 The Team defines


 DOD for User Story
 DOD for Sprint
 DOD for Release

3 Credoc Deed Preparation Team © 2014


Importance

 Team has clearer, common idea about if anything is


ready to be delivered
 It is easier to be focused on what to do, and on building
value
 It provides a point of reference for estimations and
planning
 Stakeholders know what to expect when they receive a
new version
 It reduces the risk of accumulating partially finished
things

4 Credoc Deed Preparation Team © 2014


What happens if no DOD ?

 It is difficult to estimate our velocity/date of delivery


 Stakeholders can get confused about what they are
receiving
 Undone work/technical debt can accumulate
dramatically without even noticing; uncertainty grows

5 Credoc Deed Preparation Team © 2014


Examples

DOD USER STORY


 Quality checks
 Unit test passed
 testing complete on all target environments
DOD SPRINT
 Quality checks
 is the performance tested
 Software practice checks
 have all the integration tests run and passed without
 Code review or pair programming for code
errors
 code is committed in subversion

 Software practice checks


 Business need checks
 was the code continuously integrated during
 UAT tests pass development
 user story done meets all the acceptance criteria  user story status updated as required
 all requirements related to the user story are
completed
 Business need checks
 is the goal of the sprint met
 did product owner accept all user stories

DOD Release
 did customer accept all user stories in the release plan
 is the release documentation complete
 has the new product passed the compliance
requirements tests & approved
 does the product owner feel confident about the product

6 Credoc Deed Preparation Team © 2014


Thank
you!

7 Credoc Deed Preparation Team © 2014

You might also like