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 revisionBoth sides next revision
how_do_we_initially_setup_our_definition_of_done [2020/06/02 14:21] – external edit 127.0.0.1how_do_we_initially_setup_our_definition_of_done [2021/04/28 12:38] – Removed duplicate text with "what does it mean to be done" hans
Line 1: Line 1:
 ====== How Do We Initially Setup Our Definition of Done? ====== ====== How Do We Initially Setup Our Definition of Done? ======
- 
-====== Premise ====== 
- 
-Often Teams have trouble establishing their initial Definition of Done. Firstly, each person on the Team has a different perspective and all are correct. But the reality is that "if the customer does not get the deliverable then we really have not finished and we have not delivered value to the customer". What this means is that we need a way to collect all these different views of what it means to be done. And secondly, we need to establish the discipline that before we have demonstrated or delivered something to the customer, that we have in fact done everything required to say this is a quality deliverable. If we don't have a common understanding of what it means to be done, we set false expectations and create Technical Debt. 
- 
-Many people think that because you are doing all this work you are slowing delivery down. Reality is that re-work takes a lot more time than completing work correctly in the first place, but the work is often hidden and so it really just seems this way. Bottom line is that the Lean discussion has taught us that if you focus on quality you will increase how much you deliver over time. This is a classic example of "go slower to go faster." 
- 
-> "A stronger 'definition of done' will always increase velocity and improve quality" - Jeff Sutherland at Agile 2008 
- 
-====== Background ====== 
- 
-Purpose of Definition of Done is that in every increment (iteration, program increment, etc. with different definitions at different levels) the system is __potentially shippable__ to the customer, that there is __no known remaining ____work __to be done. The idea is that we want the decision to release the product / solution to be a business decision that can be made at any time, rather than an issue that is raised when one of customers say they want something ("Can I have it now"; "What! No! We haven't finished - it only works on this machine …") 
- 
-More importantly we want to release value knowing that we have completed all the work and not pretend to ourselves that we will come to back to it later. After all we all know: 
- 
-> "Later = Never" - LeBlanc's Law 
- 
- 
-====== Creating Your Definition of Done ====== 
  
 The basic idea to get your initial Definition of Done is to get everyone's perspective on what it means to do complete, quality work from their perspective. Perhaps the analyst has one view, QA another, the architect a third, and the customer another view. The basic idea to get your initial Definition of Done is to get everyone's perspective on what it means to do complete, quality work from their perspective. Perhaps the analyst has one view, QA another, the architect a third, and the customer another view.
Line 24: Line 5:
 This leads to the following facilitated event: This leads to the following facilitated event:
  
-  * Brain-write down candidate items for definition of done, with one idea per sticky-note. Make sure people consider their complete perspective first, then consider other stakeholder. Again, this is aimed at “potentially shippable” software – include work required before released into production. Note: These are not features of the product but rather aimed at “intrinsic” quality:+  * Review any organizational standards for the Definition of Done and ensure there is understanding of the implications of that standard on the work the Team does. 
 +      * Note: It's OK to say a Definition of Done item is "Not Applicable" if it truly does not make sense in apply to the work you are doing. Be transparent about these items so that there are no false expectations. 
 +  * Within the Team have the whole Team brain-write down candidate items for Definition of Done, with one idea per sticky-note. Have people consider their own view of what it means to be done first (e.g. the QA person on a Team would have different perspective than the Developer, or the Product Owner). Then have people consider a wider prespective, including other stakeholders to the work. Again, this is aimed at “potentially shippable” (include work required before released into production) and establishing your quality standard. Note: These are not features of the product but rather aimed at “intrinsic” quality:
       * It could be a part of a process. For example, code review, security review, etc       * It could be a part of a process. For example, code review, security review, etc
       * It could be a deliverable example: For example, an automated test, end-user documentation, etc.       * It could be a deliverable example: For example, an automated test, end-user documentation, etc.
-  * Have each person read out each other their items, stick them up on a wall.+  * Have each person read out each other their items, stick them up on a (virtual) whiteboard.
   * Affinity map like items   * Affinity map like items
   * For each item review and discard those that don’t have value. Ask questions like   * For each item review and discard those that don’t have value. Ask questions like
Line 34: Line 17:
  
 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? ======
Line 61: Line 26:
 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 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 ======+====== How do We Evolute the Definition of Done? ======
  
 The Definition of Done does not remain static. The Team is always looking at ways to improve how they deliver quality and, as they get better, they will adjust the Definition of Done. So it is a living definition that you will revisit on a regular basis. The Definition of Done does not remain static. The Team is always looking at ways to improve how they deliver quality and, as they get better, they will adjust the Definition of Done. So it is a living definition that you will revisit on a regular basis.
/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