Difference between revisions of "Definition of done"

From Pearl Language
Jump to navigation Jump to search
(You cannot estimate when you don't know what done means.)
m (Typo.)
Line 41: Line 41:
}}
}}
Sources:
Sources:
**[https://sites.google.com/a/scrumplop.org/published-patterns/value-stream-pattern-language/product-backlog/track-done ScrumPloP » Trach Done].
**[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

Revision as of 12:18, 10 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
  • 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: