Definition of Done: The Swiss Army Knife of Scrum
The Definition of Done gives a lot of signals about a project's status, but since it means so much to so many, it might be a little complex.
Join the DZone community and get the full member experience.
Join For FreeMost of the concepts in Scrum are easy to understand but extremely difficult to master. This is due to the fact that Scrum is designed for perfect, and reality never is. The same principle applies to the Definition of Done.
When we start up teams, we help them to set a Definition of Done (DoD). Teams are taught that the DoD is an instrument that will provide them transparency in two ways:
- Understanding what the effort of work is, considering all the tasks that need to be undertaken by the team before work can be marked as "done."
- Understanding what "done" means when an item is inspected at the end of the sprint.
Reality is Imperfect
Many teams do not deliver every sprint a potentially shippable increment in the hands of the customer. In most cases, their DoD does not stretch that far (yet). In many organizations, activities to bundle increments into a release are treated in a separate sprint, or even worse, by a separate department. Teams mostly do not even know who the customer actually is (although this should not be too difficult since this is unambiguously the person that needs the product so badly he/she actually is willing to pay money for it). Reality is, teams work with a Definition of Done and continuously must strive to grow their abilities to deliver a "done" product. The DoD can, therefore, best be seen as a perfection goal. Is the DoD a perfection goal? Why do many teams feel it is too ambitious to adhere to?
Knowledge
Firstly, the perfect DoD cannot be adhered to due to the absence of certain knowledge in the team, so the team works with a subset: "the imperfect" DoD. The imperfect Definition of Done therefore represents the current team's capabilities. The difference between the imperfect and the perfect DoD represents what the team will need to learn.
When multiple teams together build one product, the DoD can be used to grasp how to integrate the work of all teams into a truly shippable product. In a perfect world, all teams deliver an increment that adheres to the perfect DoD, and no additional work is required to ship the product. In reality, each team has their own imperfect DoD and causes undone work to surface when integrating. This undone work is all activities comprised in the perfect DoD, not covered by the teams' imperfect DoD's.
Organizational Constraints
Secondly, imperfection is caused by organizational constraints. In many organizations, development teams are physically not able or allowed to deliver product in the hands of the customer. For instance, IT R&D considers their work as "done" when delivered to the release train, or the marketing campaign is "done" when delivered to an external company for execution. Bringing this work into the development team is considered to be impossible, not due to limitations in the team, but due to limitations in the organization. The imperfect DoD, therefore, is an indicator of the amount of change an organization can handle.
Conclusion
The Definition of Done is a true Swiss army knife of Scrum since it is a tool that
- helps teams to plan realistically
- creates transparency about the state of the increment
- shows the current abilities of teams against "done"
- acts as a perfection goal for teams to grow towards
- shows the work required to fit together one product increment
- can be an indicator of the amount of change an organization can handle
If you enjoyed this article and want to learn more about Scrum, check out our compendium of tutorials and articles.
Published at DZone with permission of Roland Flemm, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Health Check Response Format for HTTP APIs
-
Performance Comparison — Thread Pool vs. Virtual Threads (Project Loom) In Spring Boot Applications
-
Writing a Vector Database in a Week in Rust
-
How To Approach Java, Databases, and SQL [Video]
Comments