Difference between revisions of "Definition of done"
(Technical debt should be equal to or less than previous sprint) |
(You cannot estimate when you don't know what done means.) |
||
| Line 5: | Line 5: | ||
|wish in a single line=You want to know when items are done, ready for the next step. | |wish in a single line=You want to know when items are done, ready for the next step. | ||
|therefore in a single line=Create and evolve a clear list of criteria that demonstrate an item's readiness for the next step. | |therefore in a single line=Create and evolve a clear list of criteria that demonstrate an item's readiness for the next step. | ||
|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. 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}}. | ||
Revision as of 13:22, 5 January 2012
…construction of product backlog items.
✣ ✣ ✣
{{{wish full}}}
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:
{{{therefore full}}}
✣ ✣ ✣
product owner signs off on definition of done.
✣ ✣ ✣
[[wish::You want to know when items are done, ready for the next step. You cannot estimate when you don't know what done means.|]] Sources: