Everything about Definition of Done (DoD)

Definition of Done (DoD) is the declaration and commitment of the team to Quality. It is a set of criteria that each unit of work must pass to be considered as DONE. Definition of Done varies from team to team, organization to organization, however when multiple teams are working on the same product, they should agree on a mutual definition of DoD. All stakeholders must know and understand what DONE means. It is a shared understanding of what it means to be finished.

What is Definition of Done and its benefits?

  • Avoid misunderstanding: Common and shared understanding of completed work to both the development team and stakeholders
  • Promote transparency: The development team and other stakeholders know what is expected on each work, there are no surprises.
  • Promote visibility: The development and stakeholders are aware of the current state of User Stories against DoD
  • Guide in Forecasting: Development team can select product backlog items that can be DONE in a Sprint using the latest agreed upon Definition of Done.
  • Commit to Quality: DoD is the team’s declaration of Quality Standards. More rigorous Definition of Done is associated with higher quality software
  • Avoid accumulation of Technical Debts: Technical debts are incurred when team cut corners to release functionality. Stories that do not pass DoD are not included in the increment.
  • Act as a checklist: Clear and concise list of requirements that software must adhere to for the team to call it complete. It is audit-able.
  • Act as a contract between the Development Team and The Product Owner

What are the common Pitfalls of Definition of Done?

When teams start out their Agile Journey, they may encounter some issues below related to Definition of Done

  1. Unrealistic DoD at the start that nothing is actually DONE per sprint
  2. When DoD is weak (incomplete) – it will result to technical Debts
  3. Too much time is spent on meeting some DoD items without adding much value on the product
  4. Too many sets of Definition of Done: per deliverable type, per user story, per Sprint, Per Stage (Alpha, Beta, and FC). It will create confusion.
  5. DoD is changed in the middle of the Sprint
  6. DoD is often confused with Acceptance Criteria. Acceptance criteria apply to a specific User Story. It defines the boundary of the user story. Acceptance criteria changes as the User Story is further refined.  While for DoD, it remains constant for the Sprint and set prior to the start of the Sprint.
  7. DoD is not known/visible
  8. The Team does not have the skill set to satisfy the DoD
  9. The Team does not have the right set of tools to satisfy the DoD

How do you Develop a DoD?

Before the start of any sprint, the team will need (1) Product Backlog with highest priority items (doable within 1 to 3 sprints) are decomposed to implementable level, and (2) Definition of Done. This is part of the initiation activities before start of Sprinting. Below are some points to consider in developing and evolving your team’s DoD

  • DoD is defined by the Development Team, but it is owned by the whole Scrum Team
  • As a MINIMUM, the Development Team should get it from conventions, standards or guidelines of the development organization
  • Development team defines the Definition of Done appropriate for the product
    • What activities are required to SHIP the product to the end customer?
      • When there are intermediate products, the team should verify with appropriate stakeholders whether these outputs are really needed. (Example: is 90% coverage by tool really needed?)
      • DoD should be a simple list of VALUABLE deliverables
  • When multiple Scrum Teams are working on a Single Product/Platform, they should have mutually agreed DoD.
  • There are different levels of DoD; these are stages as Story travels from Product Backlog to deployed increment. For Scrum, ideally DoD should only be 1 as the goal of Scrum is to produce potentially shippable product every Sprint. Below are possible levels of DoD.
    • DoD for User Story (Product Backlog Item): Passed Acceptance Criteria +
      • Code builds without warning
      • Static code review (testing) passed
      • Unit tests are coded and passed
      • Code comments are documented
      • Demo conducted and accepted by the Product Owner
    • DoD for Sprint : Passed DoD for User Story +
      • Performance testing
      • Architecture Diagrams Updated
      • Velocity Histogram updated
      • Tested on Staging Environment
    • DoD for Production : Passed DoD for Sprint +
      • Installer packages are created
      • Security Audit and validation conducted
      • Operations and troubleshooting guide are available
      • Stress testing performed
      • Data backed-up and migrated
    • For Products/Projects with Phases (transitioning from Waterfall->Agile), Different levels of DoD depending on Quality-Level: Alpha, Beta, FC
  • DoD evolves to be more stringent as the project advances. DoD is reviewed every retrospect. It is expanded to raise the quality bar.
  • The Development Team can prepare FULL/IDEAL Set of DoD. Put all the task/criteria to be met in order to deliver the User Story into production. Then define a CURRENT Set of DoD that will be applied to the CURRENT Sprint that is doable given the current team capacity. Every retrospective, work on getting more criteria from the IDEAL DoD every Sprint into the CURRENT Sprint DoD.

How to make your DoD Effective?

  • VISIBLE: DoD should be published where everyone can see. It can be placed in the Task Board, placed in each ticket as checklist, or accessible in your Main Project page.
  • EMBEDDED: Should be automated and part of the development workflow. Some tools that can be used – JIRA  workflow, Jenkins, Redmine Checklist plugin
  • EVOLVING: should raise the quality bar over time, the DoD increases as the team matures.
  • FOLLOWED: Stories that do not meet DoD should not be demoed or shown during Sprint Review. It should not be released. This will reinforce the team (esp. Product Owner) to commit to quality.

Agile begins with an end in mind. Define your “DONE” before you DO IT.

Agile Pinoy

Published by agilepinoy

We are Agile Pinoy. We believe that Filipinos can build globally competitive Products, one team at a time.

One thought on “Everything about Definition of Done (DoD)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: