Differences

This shows you the differences between two versions of the page.

--- how_do_we_initially_setup_our_definition_of_done [2020/04/13 10:40] – [How Do We Ensure Done is Actually Done?] Changed to reflect more modern testing approach hpsamios
+++ how_do_we_initially_setup_our_definition_of_done [2020/04/13 11:01] – Added references hpsamios
@@ Line 34: / Line 34: @@
 Once complete, this is your Definition of Done. Document it and make sure its part of every planning session you have.
+====== Sample Definition of Done ======
+There is no such thing as one Definition of Done that applies everywhere. Your environment, the maturity of your practice, the product you are working, your customer's viewpoint, and the tools you use will all play a signficant potential part in your definition. But to give you an idea, here are some items that you might have if you were developing a product:
+  * Code produced (all ‘to do’ items in code completed)
+  * Code commented, checked in and run against trunk in source control
+  * Peer reviewed (or produced with pair programming) and meeting development standards
+  * Builds without errors
+  * Unit tests written and passing
+  * Deployed to system test environment and passed system tests
+  * Passed UAT (User Acceptance Testing) and signed off by Product Owner as meeting requirements
+  * Any build, deployment, or configuration changes are implemented, documented, and communicated
+  * Relevant documentation/diagrams produced and/or updated
+  * Remaining hours for task set to zero and task closed
+  * No known remaining work because we simply did not track it
+  * For each user story no additional bugs added to list of defects
+  * Code checked-out of source control is checked-in in better shape
 ====== How Do We Ensure Done is Actually Done? ======
@@ Line 40: / Line 58: @@
 What this effectively means is that you treat your Definition of Done as a checklist. For each item of work that comes in you are "does this DoD item make sense for this story?" If yes, then using this example, you add a task to the board. If not, continue. And so on.
+You might be thinking "Wow, checklists. That sounds pretty process heavy." I've found that checklists are useful to make sure you don't forget the simple stuff, while concentrating on all the complexity of the problem we are working. For more on this thinking see [[https://www.amazon.com/Checklist-Manifesto-How-Things-Right/dp/0805091742|The Checklist Manifesto - How to Get Things Right]] by Atul Gawande
 ====== Evolution of the Definition of Done ======
@@ Line 47: / Line 67: @@
 Sometimes you will encounter the situation where you would like to improve the Definition of Done, but as yet you cannot as you don't have the capability. For example, perhaps your Team has never done automated testing before and now would like to do it. In this case your could create a Feature or Story that defined the work to figure our how to do work (automated testing in this case), and the acceptance criteria might include something like "Must become part of our Definition of Done".
-{{tag>Consultant Tools DefinitionOfDone DoD FirstSprint FAQ}}
+====== Want to Know More? ======
+  * [[https://www.agilealliance.org/glossary/definition-of-done|Agile Alliance Definition of Done]]
+  * [[https://www.scrum.org/resources/blog/walking-through-definition-done|Scrum.org Blog Post Walking Through a Definition of Done]]
+  * [[https://www.amazon.com/Checklist-Manifesto-How-Things-Right/dp/0805091742|The Checklist Manifesto - How to Get Things Right]] by Atul Gawande
+{{tag>Consultant Tools DefinitionOfDone DoD FirstSprint FAQ Facilitation}}