Hans Samios' Personal Lean-Agile Knowledge Base

... absolutely #noabsolutes ...

User Tools

Site Tools

Trace:
how_do_we_initially_setup_our_definition_of_done

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
how_do_we_initially_setup_our_definition_of_done [2018/08/27 13:49] – [Background] hpsamioshow_do_we_initially_setup_our_definition_of_done [2020/04/13 10:57] – [How Do We Ensure Done is Actually Done?] Added checklist reference 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. 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? ====== ====== How Do We Ensure Done is Actually Done? ======
  
-Once we’ve defined “done”, how does it actually get done. Lets look at the Team level (similar thinking can be applied at the Train level). At the heart of this work is a Team who is going to do the work. Generally Teams will break down the work in the form of Tasks. Now some of these tasks might come from the definition of done. For example, perhaps an automated test is part of the definition of done for every Story.  Then their might be a task that says “develop automated test” in this way as you are working the board you are insuring quality every step of the way.+Once we’ve defined “done”, how does it actually get done. Lets look at the Team level (similar thinking can be applied at the Train level). At the heart of this work is a Team who is going to do the work. If a Team breaks down work to tasks some of these tasks might come from the Definition of Done. For example, perhaps an automated test is part of the Definition of Done for every Story. Assuming we are not doing Test Driven Development, then there might be a task that says “develop automated test”. In this way as you are working the board you are insuring quality every step of the way. 
 + 
 +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.
  
-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, 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 ====== ====== 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". 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}}+{{tag>Consultant Tools DefinitionOfDone DoD FirstSprint FAQ Facilitation}}
  
  
/home/hpsamios/hanssamios.com/dokuwiki/data/pages/how_do_we_initially_setup_our_definition_of_done.txt · Last modified: 2021/04/28 12:47 by hans