Agile Pies

Ideas and Howtos on Team management, projects and Agile, written simple and useful

Follow publication

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

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

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Agile Pies
Agile Pies

Published in Agile Pies

Ideas and Howtos on Team management, projects and Agile, written simple and useful

Dim Blinov
Dim Blinov

Written by Dim Blinov

DBlinov.com, SkillsCup.com, Agile coach, Soft skills trainer, Personal coach

No responses yet

Write a response