Can the Definition of Done be overriden or changed?

Question

Does the Definition of Done come before everything else, almost like a programming interface? And can it be changed if later on, once it’s realized that it was designed poorly?

By overriden, I mean can individual rules be nullified by more specific protocols like Acceptance Criteria or Acceptance Tests?

If the Definition of Done requires the team to use a specific coding standard, and the acceptance criteria explicitly states something else, which would take precedence? Would it be the explicit acceptance criteria, or would the variance simply not allowed?

Would the Scrum Master be able to change the Definition of Done, if the stated requirements are structured poorly?

Answer 1

The direct answer to your question is that yes, on very rare occasion, there may be something about a story or the acceptance criteria that causes the Scrum team to override some aspect of the definition of done for that case. However, it is a dangerous thing to do. This is sort of like saying that there are cases where jumping out of a second-story window is the best decision you can make, but it doesn't mean it's something you really want to do or that it is safe.

That said, the examples you give are very problematic. First, the user story and, therefor, the acceptance criteria, should never be specifying implementation, and therefor shouldn't set coding standards. Also, the definition of done is primarily an agreement between the development team and the PO. Any change or one-time exclusion should be agreed between them, not unilaterally by the Scrum Master.

Some cases where I have seen DoD items ignored for a particular case might include ignoring UI style guide because a particular UI is being themed for a special event or excusing a performance requirement in order to gain some other business value (ex, the page doesn't need to load as quickly because it is generating a complex report and has warned the user that it will take longer to load). The cases where we might do this are very few and far between.

Answer 2

TL;DR

The Definition of Done (DoD) is a living document that supports collaboration. As such, it’s primarily a communications tool that provides process transparency.

A good Definition of Done defines a minimum baseline for quality. It doesn’t define a maximum for quality or create an immutable rule set. Teams can and do adjust the DoD for specific work items; they just need to ensure that they communicate variations or deviations from the standard effectively within the team and to their stakeholders.

It’s up to the team and the stakeholders whether the Definition of Done should be a fine-grained procedure document, or if a broader policy document makes more sense. In short, it’s a negotiable agreement, and should be treated as such.

Because it’s a living document, an agile team should inspect-and-adapt the Definition of Done periodically. The document should be updated whenever working agreements or the “rules of engagement” change. This shouldn’t be a frequent occurrence, but can be done as often as necessary.

More Ways to Think of the Definition of Done

Some useful and pragmatic ways to think of the Definition of Done are:

1. As the agreement the Scrum Team has made internally regarding what constitutes a complete increment of work.

   This will generally include basic elements of TDD, BDD, linting, style-checking, documentation, and so forth. It only needs to be as detailed as “done” really is.

2. As the contract between the Scrum Team and the organization regarding the minimum guarantees for each increment of work.

   For example, if your Definition of Done includes successful acceptance testing, then a story or task doesn’t have to be written for acceptance testing because the DoD is an explicit checklist that is implicitly part of every Product Backlog Item delivered. If a user story is delivered, stakeholders can feel confident that they story has met the Definition of Done.

3. As a quality baseline that can be added to, amended, or modified as needed.

   A documentation story wouldn’t necessarily require unit tests or have to meet test-coverage targets. A database story probably wouldn’t require linting. A well-written DoD covers the general use cases that define “done” to a specific level of quality. You don’t have to apply rules that don’t make sense for that story, nor are you precluded from adding to the DoD for a specific work item.

   Additionally, if you treat the DoD as a baseline, then you will have cases where there needs to be additional criteria for “done.” You might have a story to embiggen a widget where the story won’t be considered as done until the widget soaks in the anti-ensmallening bath for an hour. That is part of the Definition of Done for that story, but is probably too specific for the baseline DoD.

These facets of the Definition of Done are not orthogonal. You can combine them, as well as other interpretations, in any number of ways. The trick is to ensure the Definition of Done is sufficiently complete to describe “done” without being overly prescriptive. As always, the devil is in the details.

Specificity vs. Generalization

The Definition of Done should be general enough to set expectations of quality and doneness for the majority of Product Backlog Items. There will be exceptions, and it is not intended to be a straitjacket. However, there are some practical guidelines.

1. If the team is frequently eliding elements of the Definition of Done, it’s probably too specific, too granular, or poorly written.

2. If the team is frequently adding criteria for doneness to individual stories, the Definition of Done probably needs to be written more broadly, or to capture the essence of increment quality in a less granular way.

In the same way that finding the optimal granularity of user stories is an art form, so is finding the right level of detail for the Definition of Done. The DoD should provide confidence in the quality of deliverables, but it should never take on a life of its own. The goal is to reliably deliver working product increments, not to check off boxes on a list.

When the Definition of Done stops being a mechanism to improve collaboration, and becomes an end unto itself, then it’s probably time to review it in a team retrospective and with the stakeholders. Agile frameworks value collaboration and working agreements, not detailed specifications. Treat your DoD as a living document that captures key elements of collaboration and you’ll be on the right track.