Queue-it Developer perspective: One definition of done won’t cut it
Like many other agile development teams, the definition of done (DoD) is an important piece in our development process. It is basically a checklist of tasks to be completed before a story can be released to production, which includes unit tests, code review, and automated integration testing, among other things.
DoD comes from Scrum, and like many Scrum principles and practices, they tend to be a bit oversimplified so that the many consultants can sell a clear message. In practice, I argue that you will need multiple DoDs, which ensure different levels of quality.
Definition of done & the process
At Queue-it, we do not assume that we know the requirements of our customers. Our product is one-of-a-kind, so our customers are often not aware of what their requirements are. In many cases, all we have are some rough ideas originating from our team or customers. Going from a rough idea to a one-of-a-kind product comes with a high risk of developing a product that nobody wants.
This is why we use the build, measure, learn cycle from the Lean Startup Methodology. The main purpose of this process is to gain as much validated learning about your product with the least effort. The path from idea to product may include pretotypes released to internal users, prototypes released to a couple of customers, minimal viable products released to a larger subgroup of customers, and, finally, general availability.
In this process, the product will be modified and rewritten, and parts of it may be dropped entirely. If the same DoD is applied to all stages in this process, it would be wasteful, and learning would not have been gained with the least effort. Adding an automated UI test to a feature that you do not know if users want will provide very limited value, and you will learn nothing from it.
This is supported by the Design Stamina Hypothesis. It claims that the cumulative functionality is richer if you do not design upfront. In other words, you will be able to learn more about your product earlier if you skip certain activities in the initial phases where they only provide little value. The hypothesis also states that as your product evolves, there will be technical debt. This debt must be paid by adjusting the DoD to the appropriate and sufficient level throughout the process to both new and existing code.
Definition of done & business value
Not all code is equal. Some parts of a product are business-critical, while other parts are nice to have. So why would we treat them the same in terms of DoD? If the business value of mobile payment is higher than the value of the newsletter signup, then the DoD should be defined in a way that the quality, service level, and availability of the mobile payments is equally higher compared to the newsletter signup.
If the DoD fails to ensure this, the development efforts are not optimized to yield the ideal business value. The DoD has a cost – not so much in terms of the time it takes to apply it, but in the business value that is lost.
Appropriate & sufficient
In most teams, the individual developers will use their own judgment and only apply the steps in the DoD they find relevant for a particular task. The team members will have different interpretations, and the product owner may expect a quality that was different from the result.
Instead, the level of DoD must be made explicitly by the product owner before the feature, story, or task is initiated. Once you have features explicitly assigned DoD levels, you can do reviews on the quality of your product and continuously change the quality of features as the business value changes.
Written by: Martin Larsen, Queue-it Director of Product