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.