Contemporary product development teams build products which are ‘potentially shippable’ from early in the lifecycle and aim to maintain this condition throughout production. The notion of potentially shippable often causes confusion however, usually as people interpret this to mean ‘ready to ship’, inferring that you would actually release.
Instead, potentially shippable is a statement regarding the quality and completeness of the product, meaning that a level of confidence exists whereby if you absolutely had to ship, you could. Keeping a product in this state is therefore important, clearly, as risk of being able to deliver value to users, and therefore the business, is significantly reduced without meeting this criteria. What if funding is suddenly pulled? If the product isn’t potentially shippable, that’s the end of the line.
So how do we help to ensure that a product starts and stays in a potentially shippable state? One tool that could be used is the ‘Definition of Done’ (DoD). The DoD is a checklist that each and every piece of new functionality must satisfy before it can be considered ‘done’. An example of an extremely simple DoD might only have one point: no known bugs. But this DoD doesn’t ensure that a feature is merged, integrated, refactored, code reviewed, accepted by the product owner - the list could go on. The more robust the DoD, the better chance of ensuring that the product is potentially shippable.
If a team forms a weak DoD, it could result in the acquisition of ‘unfinished work’, which in this context can be defined as any work left outstanding that has the potential to prevent the delivery of value. Although a single piece of unfinished work may only have limited impact, accumulating unfinished work can have far greater consequences. Accumulation is dangerous as the pile of unfinished work is likely to be of an ever increasing unknown quantity and therefore means that in addition to increased risk, predictability is substantially diminished. Imagine a scenario where a team neglects conducting any regression testing for a given period of time - if the business suddenly needs to ship, there’s a good chance they can’t until undertaking a period of testing and bug fixing, and the effort required for such an activity is virtually impossible to predict. If the team had testing as part of their DoD, and therefore integral to their process, they might have been able to avoid that situation. ‘Technical debt’ is a well understood notion in the tech community and another example of unfinished work, in a limited capacity the impact might be minimal, but with time debt builds on debt which has consequences such as increased fragility of the codebase and could lead to substantial rewrites.
When it comes to forming a DoD, this is down to each and every team to decide what ‘done’ means to them in their given context. Some teams need to satisfy legal requirements, some don’t. Some teams care about keeping the codebase clean, others don’t. One key question that teams should ask themselves if there is any uncertainty regarding the inclusion or exclusion of certain criteria is “could we ship without it?”. If you can’t ship without error handling, then it should be in the DoD. If you can’t ship without satisfying compliance criteria, then it should be in the DoD. There are other potential benefits to a DoD too, such as helping to embed good practices, so another important question might be “should we ship without it?”. A simple way to start with building a DoD is to A) surface what’s both required and desired to ship, B) agree on DoD checkpoints as a team, C) put it into action and review it regularly. Here’s a simple template that might help facilitate discussion for points A and B:
- Functionality criteria has been satisfied.
- Releasable build available for demo.
- Project documentation updated.
- Integrated with backend.
- Code documented, tested and merged with main codebase.
- Code has been peer reviewed (or pair programmed).
- Build manually tested with no new known bugs (unless accepted).
- Team satisfied with the design quality.
- Analytics implemented (if applicable).
It’s important to remember that a DoD is just a tool and whether that tool is right or wrong for you or your team depends on context. If you do decide to have a DoD however, then make it as robust as required to give the best possible chance of maintaining the product in a potentially shippable state. If you find that a DoD is surfacing the things which are hindering your progress, then embrace this useful knowledge to adapt the organisation to a position which better supports delivery.