"Definition of Done" long-long list to choose from

Dim Blinov
Agile Pies
Published in
2 min readAug 20, 2018

Check out my course about Scrum on Udemy for free https://medium.com/agile-pies/scrum-fundamentals-1-5h-course-on-udemy-for-0-limited-offer-279d03e516cd

Sometimes it is useful to have a list of different criteria a team may choose from to make their initial "DoD". You will find such a list below after a piece of theory from the Scrum Guide:

…everyone must understand what “Done” means …to ensure transparency …and is used to assess when work is complete on the product Increment.

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning.

If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

Any one product or system should have a definition of “Done” that is a standard for any work done on it.

So, here are some examples of DoD criteria.

Sample criteria for Definition of "Done"

Design:

  • Ready/Complete
  • Reviewed/OK

Code:

  • Written by the author
  • Reviewed by peer
  • Checked-in
  • Merged to Main/Master
  • Compiles

There are plenty of criteria for testing, therefore I gathered them into groups by dimension. You may take any type of testing, divide it by process steps, scope and environment, e.g., “Integration is manually test by tester on UAT environment”.

Tests by process:

  • Written
  • Reviewed
  • Pass/OK

Tests made by role:

  • Manual DevTest by the author
  • Manual DevTest by a peer
  • Manual Tester/QA engineer
  • Automated
  • PO approved
  • Users/UAT

Type of testing:

  • Regression
  • UI
  • E2E
  • Functional
  • NFRs (non-functional requirements)
  • Load
  • Performance
  • Stability
  • Stress

Tests by objects/scope:

  • Unit A,B,C
  • Component C,D,E
  • Integration
  • API

Number of defects:

  • Critical, Major, High = 0
  • Mediums <10

Other aspects to apply:

  • Coverage >75%
  • Acceptance criteria pass/OK
  • Refactoring
  • Build

Documentation:

  • By type: User, Operations/support
  • By process (find above)

Deployment:

  • Deployment and rollback plans: known/written, reviewed by Ops
  • DB update scripts: written, tested
  • Environment X,Y,Z ready
  • Deployed to environment X,Y,Z

--

--