What’s one thing YOU could do as a ScrumMaster to improve your team’s reliability, quality, and productivity? Read on and find out…
One of the most effective tools that can be employed to improve product quality is the creation of a “Definition of DONE” or DoD. The DoD can be used by the team to get everyone on the team on the same page in terms of what has to be done in order to call a product backlog item DONE. The DoD is much more than just, “it works” or “it’s finished” and should include all of the regulatory, administrative, and logistical elements required by the product. For example, for a software product, your team’s DoD might include the following:
- All specifications have been updated, reviewed, and approved.
- All code has been reviewed.
- The software is in an integration environment and completely tested.
Let’s say your team builds marketing materials instead of software (yep, you can use Scrum for that), your team’s DoD might include the following:
- All brand elements (color, font, etc) has been verified.
- Legal department has approved all content.
See how it works?
USING THE DEFINITION OF DONE
During the Sprint, the Definition of DONE should be considered by the developers on the team while the solution is built, while estimating the backlog item, and particularly when saying to the Product Owner, “Hey, this product backlog item is done.” Developers are responsible for ensuring that the DoD is achieved before they say that a product backlog item is complete. Likewise, the Product Owner is encouraged to verify Doneness should there be any doubt.
BUILDING THE DEFINITION OF DONE
When building the DONEness Definition, I can offer you three tips:
- Start with what’s already required by your organization’s standards of coding, documentation, database construction, etc. Then add anything required by the product that you’re building. Then sit down with your team and see what they want to add to the definition to finish it.
- It won’t be complete. Ever. Things change all the time. Don’t go for perfect, go for good enough and improve it as you go.
- Always remember that the DoD is OWNED by your team…not you. Creating or modifying a DoD is something that your team should be driving.
By using the DoD properly, you can almost immediately improve product quality. Should you continue to experience new defect detection after the Sprint, you should try to figure out what might be missing from the Definition of DONE. Remember, the definition isn’t written in stone — check it every three months or so and see if it needs to be updated.
AN EXAMPLE OF DONENESS
- The Product Owner likes it.
- It has been integrated with the rest of the product and nothing else broke.
- All tests (unit, functional, integration, performance, security) ran successfully.
- All artifacts are properly checked-in.
- All coding standards have been followed.
- All design standards have been followed.
- All documents and specifications have been updated.
- All naming standards for all artifacts (code, tests, documents, etc.) have been followed.
- All regulatory requirements have been followed (i.e., requirements specifications, requirements traceability matrices, etc.)
Click here for DONENESS on a Page.