Is It Really Done?

1. Smells

• The team doesn't have a definition of Done
• Ignores the definition
• Demo's run from a developer's machine
• Done but.... there is some refactoring to do; we still have some unit tests to write
• Sprint reviews include features that are known to be incomplete.

2. Discussion

Often in the belief that they're making more progress teams will be encouraged (or they do it to themselves) to take on as much stories as possible. As a result corners get cut.

3. Causes

• External pressure
• Vague stories with no refinement from acceptance tests.
• Not knowing how to write acceptance tests for their particular environment (think rich client GUI's).
• Bad initial estimates creating internal personal pressure to finish everything the team committed to.

4. Consequences

• Untested code represents waste - the team has just put off discovering the bugs.
• Technical Debt will pile up unnoticed.
• The teams velocity will eventually slow
• Bugs shipped to customer (lost revenue, trust, or lives).
• PO cannot plan release date and scope because no one knows where we really stand.

5. Prevention

6. Example Remedies

• Get the team to agree on a Definition of Done
• Slow down and respect the Definition
• Start paying off the technical debt.
• Product Owner only allowing the things that are done to be shown at the Sprint review.
• Reduce functional scope of stories (i.e. split them vertically) even while extending

  definition of "done."

7. Case Studies

Credit: this is based on material from "10 ways to screw up with Scrum and XP" by Henrik Kniberg. Personal Experience: Mark Levison