Multi-level definition of done

This post is part of 101 ideas for agile teams.

Context

Feedback about implemented product backlog items is given only at Sprint review. The team wishes feedback sooner and feedback about technical matters.

Action

Create a definition of done (DoD) on multiple levels (the sample below shows what my team used):

Commit — Committing code to the source code repository.
code builds, commit message

Push — Pushing code into the shared team repository.
unit tests and specs run successfully, clean code, push review (code shown to another peer)

Story Review — Sprint backlog item is considered done by the development team.
all tasks done, runs on all testing environments, basic exception handling is implemented, no tangles in source code (circular dependencies in namespaces), software architecture document is updated

Sprint Review — Sprint backlog item is done
demonstrated to stakeholders, accepted by PO, specifications reviewed by PO

Release — When a release is published to customers
version is updated (documentation, web site, …), build server runs release branch

What you gain

Early feedback.

How to strengthen

Put definition of done onto Scrum board.

Risks

Feeling of too much formality. The team decides about the definition of done and how much detail it includes.

Definition of done is used as a checklist, instead of a reminder.

Definition of done is used as rules, not as a guideline. Remind the team that they are responsible for the quality of the product and that items can be added or removed from the DoD (even for a single User Story).

More ideas at 101 ideas for agile teams

Many thanks to bbv Software Services for making this blog post possible.