Do you have a Definition of Done? Or does your team say things like: “It’s done, but I just need to push it to production”, or “It’s done, but there are a few little bugs we will need to get to later”, OR “It’s done, but when you cut into it, it goes Moo!”
Does Done mean Done for your team? Successful Agile methodologies demand that teams work hard to speak a consistent language at all levels of your project. We spend much time in refinement, planning, review, and retrospectives trying to ensure we effectively communicate with everyone involved in a product. Few things are as crucial to the success of a project as everyone understanding and articulating what Done actually means.
In Scrum, we use the “Definition of Done” to ensure that everyone involved with a team has a clear understanding of what Done is. In Scrum, we also never use the word Done until something is, in fact, 100%, actually DONE! The Definition of Done is a standard list of acceptance criteria we can use across all product backlog items to ensure to everyone involved that when we say something is done, it is actually done. A strong Definition of Done helps teams in forecasting, communications, and, of course, getting things to done.
Here are a few things to consider when creating your Definition of Done.
What level of testing should be done?
Does your team use TDD? How many acceptance tests should you expect? What is your team’s standards for testing and how do you know that that work has been completed? A clear, consistent expectation of the level of testing is an essential component of writing stable systems. Be sure to include statements of target performance levels and what browsers/devices the code should run on.
Where should the code exist?
Does your team use Continuous Integration / Continuous Delivery? Where will your Product Owner go to use Potentially Shippable Release? Knowing the level of testing helps the Product Owner know if a release is likely, but knowing where to get their hands on it is critical. Be sure everyone knows where to deploy the code and how to get access to that. Adding this to your Definition of Done will ensure a consistent process when it comes to testing.
How should the work be documented?
There is a broad range of documentation needs for code. Some companies rely on in-code documentation while others want full SDKs with complex documentation. Both are fine, but make sure your team knows expectations. Moreover, if documentation is part of the expected work product, you should work to get that done during a sprint AND include that in your Definition of Done.
How has your Definition of Done changed?
Have you reviewed your Definition of Done lately? Are you talking about it in your Retrospectives? These aren’t a one and done thing. As with everything in Agile, we are continually inspecting, adapting, and improving. Make sure your team is regularly looking at the quality of your product, the happiness of your Product Owner/Customers, and the maintainability of your system and integrating new understanding and insight into your Definition.