This post was written by John Clapham.
Look around your team board, is it there? Perhaps there’s a scruffy, and curled post-it to one side, maybe by now it has fallen face down and joined the dust, old avatars and used markers on floor. Perhaps though your definition of done is in better shape; what does it say? “All unit tests passed”, “PO sign off”? I believe there is much more value to a good definition of done than we give credit for. In fact, like many other simple agile concepts, what you have with the definition of done is a powerful collaboration and change tool.
The ‘definition of done’ is a list of criteria a story must pass before it is considered fit for purpose, fit for passing on to the next team or environment. The list is agreed by the team and key stakeholders. It doesn’t include everything a team does; it typically comprises a mix of items that are easily forgotten (run a code style check) and the items the team aspires to. Frequently the later are added as the result of a retrospective. Regular change to the definition of done is often an indication of healthy experimentation and a team challenging itself to do better.
So the definition of done should most definitely include the basics that keep the team’s output high quality, and suitable of ongoing maintenance:
- Code has been paired on – to encourage learning and shared ownership.
- Automated tests present and passed – in order to spot regression and support refactoring
- Documentation updated – Where required, and absolutely only what is necessary
- Zero Defects – Often present, although I would hope a matter of pride.
In addition there are often reviews and sign-offs from both a technical (architecture, operations) and business (User Experience, Product) perspective.
You’ll note that, if taken literally, these reviews take place when it is ‘too late’, the code is already written, and only then do we ask if it is useable? This gated approach generally encourages desirable behaviour. After a few failed reviews the team soon learns that an iterative, collaborative approach to stories will lead to successful, surprise-free sign off.
All the points above focus on the team’s remit, basically describing a job well done by that group. As such they are useful places to start, especially for a newly formed team. There is a level beyond this, where consideration is given to the life of the component outside the team; the definition of done is used to blur team boundaries, to prevent us becoming ‘jobsworth’.
The DevOps conundrum
Consider the DevOps conundrum: developers write some code, test it locally and then pass it to operations as ‘done’. Operations are expected to support that component twenty four hours a day until it retires, with scant information on its behaviour and configuration. Instead of passing this ticking time bomb down stream, what if operation’s concerns and needs were addressed at development time, in the team doing the making?
The kind of questions a team might ask when creating a more lifecycle aware definition of done are:
- What does it take for the story to be done, and stay done?
- What work should be done for the benefit of other teams?
- What can we provide to reduce work for other teams?
- If we had to maintain/sell/secure this, what would we want?
This leads to additional items such as:
- Monitoring and alerting hooks provided
- Deployable in various environments
- Configuration versioned and documented
- Customer documentation provided (or a basis for it)
I’m sometimes asked what the ideal definition of done is, the glib answer is ‘Done means in production’. I’ve worked in teams that use this definition to great effect, however it demands an acute awareness of just what ‘in production’ means, and in particular the business of running, monitoring, securing and maintaining software. This makes ‘in production’ a great goal, and the challenge becomes “Just how close can we get to production?” The definition of done then covers various points to make the component suitable for the highest accessible environment.
Inevitably, adhering to a more comprehensive definition of done leads to more work for the originating team. It is crucial to recognise that it doesn’t lead to more work for the organisation; if anything overall work is reduced. By trying to get the majority of the work done close to the source we avoid handovers, unpleasant surprises, miscommunications and scheduling conflicts.
The focus is putting responsibility in the right place, as opposed to deferring work for other teams and roles. This is why the definition of done provokes such great conversations; suddenly the team needs to involve operations or user documentation experts at the beginning, and specialist teams need to change their approach to enable early involvement and input.
This is why the definition of done is something of a change tool, it promotes collaboration both in and between teams. By capturing the criteria, and making them a gate we have a consistent, visible working document ready for discussion and evolution. While this article has focused on the team writing it’s own definition, it is desirable for teams to suggest items for each other’s definitions.
So, why not review your definition of done, and ask yourself, “Does this really encourage my team to do it’s best?”
Skelton Thatcher 