Difference between revisions of "Definition of done"

From Pearl Language
Jump to navigation Jump to search
(Zeroth version.)
 
(Added example {{dod}}.)
Line 6: Line 6:
|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.
|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.
|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}}.
 
The {{dod}} is informed by reality where it captures activities that can be realistically committed by the {{dt}} to be completed at each level (feature, sprint, release). The {{dod}} meets the criteria from the party receiving the {{pbi}} as well as those from the {{po}}.
 
In a {{p|sprint}}, a {{pbi}} is “done” when:
*the item can be demonstrated;
*{{p|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 {{p|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
*the item is deployed on the acceptance test environment.
 
Although the list above is quite elaborate, {{dod}}, like any checklist, should be an {{p|elegant checklist}}.
There are different {{dod}}s for a {{sprint}} and release.
 
During the {{sprint}}, make sure you {{p|track done}}.


A {{pbi}} is finished when it can be '''demonstrated''' to meet all conditions of satisfaction identified by the {{po}}.
|therefore=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}}.
}}
}}
Sources:
**[https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/track-done ScrumPloP » Trach Done].
**[http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod Scrum Alliance » What is Definition of Done]


{{Source
{{Source

Revision as of 08:48, 7 November 2011

…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
  • the item is deployed on the acceptance test environment.

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.


✣  ✣  ✣

Sources:

Retrieved from "http://pearllanguage.org/index.php?title=Definition_of_done&oldid=95"