Without this collective and transparent agreement, teams may struggle to get product backlog items 100% truly ‘Done’ within a Sprint.
This is explained further by the Scrum Guide;
“When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.” The Scrum Guide (p.16)
The below example of ‘Done’ is fairly typical for a team early on in its adoption of Scrum within a corporate environment.
|Activity (Example)||Criteria (Example)|
|Detailed Analysis||Acceptance Tests approved by Product Owner. Wiki updated.|
|Detailed Design||Consistent with approved design patterns and UI standards. Design approved by Architect. Overall Design Doc updated.|
|Build & Unit Test||Consistent with coding standards. Peer Reviewed. 90% automated unit test coverage. All unit tests passing.|
|Low-level Integration||Integrated with team’s branch. Mocking/stubs used as needed.|
|Full Integration and System Test||Tests automated wherever possible, specified where not. Testing standards adhered to. All system tests passing.|
|Acceptance Test and Documentation||Acceptance tests executed and automated wherever possible. All acceptance tests passing. Documentation approved by PO.|
|Pre-Production Deployment||Deployed through standard production process onto shadow live environment behind firewall. Approved by Ops for release.|
Constraints of this team’s existing way of working mean that they are unable to get Product Backlog Items 100% truly Done within a Sprint.
- Full system testing is impossible every Sprint, perhaps because it requires integration with the work of other teams or systems which are not set up for it.
- Acceptance testing by customers is not possible in every Sprint, perhaps because the customers are not willing or able to do it on a Sprint-by-Sprint basis.
- Finally, deployment by the team of their work into a production ready environment is not possible, perhaps because of a centralised release process that needs the involvement of a separate group.
This work can only be done at a later date, perhaps in a large batch, and sometimes even by another team. This increases the length of the overall feedback loop and increases the risk of late problems being discovered.
This team should change the way that it works in order to gradually move the first dark blue line (“Done”) down until it coincides with the second (“Done-Done”). This can take many months or even years to achieve in some organisations.
If you’re looking to develop you’re understanding of ‘Done’ further, then agil8 offer a number of courses that will explore this in more detail: