Is Your Definition of Done Static?

Having a Definition of Done (DoD) is not a guarantee that the Team will produce a potentially shippable increment by the end of the Sprint.

The Scrum Team identifies a Definition of Done at the start of the project. It makes it visible. And it starts working in Sprints. But it doesn’t get to Done at the end of its Sprints. In many instances, it doesn’t even realize that until its Product Owner wishes to release the work to production. Only then the Scrum Team discovers even though it has a Definition of Done, but that hasn’t helped the Team in producing Done increments.

Static Definition of Done

The Scrum Team has created a Definition of Done (DoD) initially. But its DoD hasn’t changed over time. It hasn’t inspected, adapted and updated its Definition of Done as it has learnt more. Its DoD is static.
Over time, the Team members has not accounted for the following changes in their DoD

• Changes in the scope and the way these change affect their Done Defintion
• Their technology, build and deployment infrastructure changes
• Changes in the external systems they are dependant on
• Changes in testing infrastructure
• Changes in the Team composition

Some other changes might have occurred as well.
Of course, the Team has ignored the biggest indicators of all, that it was not getting to Done every Sprint.

Not Getting to Done

The Scrum Team has come up with a Definition of Done. And it adheres to it. However, it struggles to get Done Sprint after Sprint. Some kind of house cleaning is needed before the increment is usable by the customers i.e. the increment is Done.

By the end of the Sprint the Team ends up with half baked work which is not production ready. It either ignores end to end testing altogether or relies on testing on ‘developer machines’ only. This is the ‘it works on my machine’ syndrome. Or the Team misses out other piece of work that needs to be carried out before the increment is shippable.

Planned and Long Stabilization

The Scrum Team has planned not to get Done, even though it might have a Definition of Done. The Team or the Product Owner has come up with a release plan. The release plan calls for several Sprints towards the end of the release cycle that are named as ‘stabilization Sprints’. Some call it ‘integration’, others use more innovative names.

The Scrum Team has planned to conduct several Sprints worth of undone work right from the word go. As it get closer to the ‘stabilization Sprints’, of course, the stabilization work has increased many-fold. And it is surprised at this, again.

Meaningless Estimates And Plans

The Definition of Done is a critical agreement. The Team is unable to estimate effectively without it. It doesn’t know the complete set of requirements either functional or non functional, the set of activities that it needs to carry out before the product goes into production. It does not know how much work it should carry out during the Sprints for the items it has selected. Estimations and plans based on those estimations are misleading. These don’t mean much.

The Product Owner doesn’t not know what activities the Team is not completing. She does not know what’s the degree on ‘doneness‘ of the items delivered by the Team i.e. whether the Product Owner can go ahead and implement those items or not. This causes lots of confusion and frustration. The projections and estimations Team is coming up with are based on incomplete information. The release schedule created by the Product Owner with the help of the Team is misleading.

Long Release Cycles

The Team accumulates significant amount of technical debt in absence of a good Definition of Done. It misses out pieces of work which should have been completed every Sprint. This undone work accumulates exponentially. If the Team keeps ignoring undone work for a few Sprints it is very likely that it would need several Sprints at the end just to finish what it has already ‘built’. It will be able to release only after long, painful and costly stabilization.

Team Members should continuously ask themselves the question, ‘is our Product Owner, if she wishes to, able to implement the increments we produce without ever asking us again?’. In case the Team is not getting at that level every Sprint, it is missing some items on their Definition of Done.

Definition of Done is not a static document. The Team must inspect and adapt it on continuous basis. It must identify the gaps. It must identify the items it is missing and add those items on its Definition of Done.