The Definition of Done (DoD) is a common understanding within the Scrum team on what it takes to make your software ready to be released. In their book “Managing the Unmanageable”, Mickey Mantle and Ron Lichty propose an extensive list of what a Definition of Done should include. You could use do these elements to create your own DoD for your Agile team.
The project kickoff is often the right time to get agreement around the question “When is a feature, task, or sprint done? What constitutes ‘done’?” Defining “done” is a joint exercise with the business, the development team, project management, QA, and sometimes others to define when each feature can be declared done. In addition to being coded, will it need
- Design review
- Peer review (or pair programming)
- Code review
- Unit testing
- Check-in to source control
- Commenting in source control
- Performance testing
- Refactoring
- Any changes required to build it communicated to the buildmeister
- Online help written and integrated
- Built out of source control
- Unit tests passed on the source control build
- Automated regression tests for the integrated application passed on the new source control build
- Bugs fixed
- Installation scripts written
- Tested on multiple platforms, browsers, configurations, etc.
- Story or use case test plan updated
- Documentation written
- Product managers’, product owner’s, and/or customers’ acceptance that it meets expectations
- Task hours recorded
- Tasks closed out
It’s important for the team to agree to the elements of “done” and agree to deliver them. It’s infrequent that two teams agree on the same definition of done. The definition might even change (with team agreement) from iteration to iteration, from task to task, from sprint to sprint.
Reference: “Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams”, Mickey Mantle, Ron Lichty, Addison-Wesley