Difference between revisions of "Definition of done"
(Added example {{dod}}.) |
(Goal.) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Oyster | {{Oyster | ||
|goal=know when you are done with an item, ready to be pulled into the next step | |||
|stage=Sparkle | |stage=Sparkle | ||
|theme=Agile, Scrum | |theme=Agile, Scrum | ||
|context=construction of {{pbi}}s. | |context=construction of {{pbi}}s. | ||
|wish=You want to know when items are done, ready for the next step. | |wish=You want to know when items are done, ready for the next step. | ||
|so=Create and evolve a clear list of criteria that demonstrate an item's readiness for the next step. | |||
|wish full=You want to know when items are done, ready for the next step. You cannot [[planning poker|estimate]] when you don’t know what done means. | |||
|background=The {{po}}'s conditions of satisfaction for a {{pbi}} are the high-level and {{p|crystal clear acceptance criteria}} that he or she likes to see applied to a {{pbi}} before considering it is finished. A {{pbi}} is finished when it can be '''demonstrated''' to meet all conditions of satisfaction identified by the {{po}}. | |background=The {{po}}'s conditions of satisfaction for a {{pbi}} are the high-level and {{p|crystal clear acceptance criteria}} that he or she likes to see applied to a {{pbi}} before considering it is finished. A {{pbi}} is finished when it can be '''demonstrated''' to meet all conditions of satisfaction identified by the {{po}}. | ||
| Line 30: | Line 31: | ||
***document surprises and workarounds | ***document surprises and workarounds | ||
***make every comment count | ***make every comment count | ||
*the item is deployed on the acceptance test environment | *the item is deployed on the acceptance test environment | ||
*technical debt is equal to or less than end of previous {{p|sprint}} | |||
Although the list above is quite elaborate, {{dod}}, like any checklist, should be an {{p|elegant checklist}}. | Although the list above is quite elaborate, {{dod}}, like any checklist, should be an {{p|elegant checklist}}. | ||
| Line 36: | Line 38: | ||
During the {{sprint}}, make sure you {{p|track done}}. | During the {{sprint}}, make sure you {{p|track done}}. | ||
|therefore full=Create and evolve a clear list of criteria that demonstrate an item's readiness for the next step. | |||
|therefore=Create and evolve a clear list of criteria that demonstrate an item's readiness for the next step. | |new={{po}} signs off on {{dod}}. Just one state transition in the {{p|babushka of value}}. | ||
|new={{po}} signs off on {{dod}}. | |||
}} | }} | ||
Sources: | Sources: | ||
**[https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/track-done ScrumPloP » | **[https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/track-done ScrumPloP » Track Done]. | ||
**[http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod Scrum Alliance » What is Definition of Done] | **[http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod Scrum Alliance » What is Definition of Done] | ||
{{Source | {{Source | ||
|author={{mvs}} | |author={{mvs}} | ||
|coder={{mvs}} | |coder={{mvs}} | ||
}} | }} | ||
Latest revision as of 13:35, 26 May 2013
…construction of product backlog items.
✣ ✣ ✣
You want to know when items are done, ready for the next step. You cannot estimate when you don’t know what done means.
The product owner's conditions of satisfaction for a product backlog item are the high-level and crystal clear acceptance criteria that he or she likes to see applied to a product backlog item before considering it is finished. A product backlog item is finished when it can be demonstrated to meet all conditions of satisfaction identified by the product owner.
The definition of done is informed by reality where it captures activities that can be realistically committed by the development team to be completed at each level (feature, sprint, release). The definition of done meets the criteria from the party receiving the product backlog item as well as those from the product owner.
In a sprint, a product backlog item is “done” when:
- the item can be demonstrated;
- crystal clear acceptance criteria are met;
- all tests pass:
- User Acceptance Tests;
- unit tests;
- regression tests;
- integration tests; this implies that the code is checked in, preferably in a trunk only environment;
- non-functional requirements are met;
- code criteria are met:
- code is peer reviewed;
- objective code quality is met;
- documented appropriately:
- design decisions are documented;
- release notes are updated accordingly;
- code is documented and commented with care:
- don't document bad code – rewrite it
- don't repeat the code – clarify its intent
- document surprises and workarounds
- make every comment count
- code is documented and commented with care:
- the item is deployed on the acceptance test environment
- technical debt is equal to or less than end of previous sprint
Although the list above is quite elaborate, definition of done, like any checklist, should be an elegant checklist. There are different definition of dones for a sprint and release.
During the sprint, make sure you track done.
Therefore:
Create and evolve a clear list of criteria that demonstrate an item's readiness for the next step.
✣ ✣ ✣
product owner signs off on definition of done. Just one state transition in the babushka of value.
✣ ✣ ✣
Sources: