how_do_we_initially_setup_our_definition_of_done
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
how_do_we_initially_setup_our_definition_of_done [2018/08/27 13:49] – created hpsamios | how_do_we_initially_setup_our_definition_of_done [2021/04/28 12:47] (current) – Added reference to main article on DoD 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" | ||
- | |||
- | 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 ' | ||
- | |||
- | ====== 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' | ||
- | |||
- | 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 LeBlanc' | ||
- | |||
- | > Later = Never | ||
- | |||
- | ====== Creating Your Definition of Done ====== | ||
The basic idea to get your initial Definition of Done is to get everyone' | The basic idea to get your initial Definition of Done is to get everyone' | ||
Line 23: | Line 5: | ||
This leads to the following facilitated event: | This leads to the following facilitated event: | ||
- | * Brain-write down candidate items for definition | + | * 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" | ||
+ | * Within the Team have the whole Team brain-write down candidate items for Definition | ||
* 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, | * It could be a deliverable example: For example, an automated test, end-user documentation, | ||
- | * 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 36: | Line 20: | ||
====== 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 | + | 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 |
- | 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?" | + | 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?" |
- | ====== | + | You might be thinking "Wow, checklists. That sounds pretty process heavy." |
+ | |||
+ | ====== | ||
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. | ||
Line 46: | Line 32: | ||
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> | + | ====== Want to Know More? ====== |
+ | |||
+ | * [[what_does_it_mean_to_be_done|What Does It Mean To Be Done?]] | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | |||
+ | {{tag> | ||
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/how_do_we_initially_setup_our_definition_of_done.1535402968.txt.gz · Last modified: 2020/06/02 14:22 (external edit)