Should Scrum teams aim to be done or to be perfect? The answer is that Done is better than Perfect. The team’s job is to ship product, not to be perfect. So don’t the let the perfect be the enemy of the MVP.
Most teams think that setting a high quality bar with Definition of Done (DOD) ensures high quality. Admittedly, this is true but only to a point. Long work to meet an overly stringent DOD can lead to less frequent delivery, i.e., less frequent feedback. Unless you are a Waterfall Nostradamus of perfect foresight, infrequent feedback guarantees building things wrong and building the wrong things.
Now let’s answer four related DOD questions and see if the answers also apply to the Definition of Ready (DOR):
How high should you set the bar for Definition of Done?
Document a DOD which is your definition of absolute perfection. Then rank the DOD quality checks from 1 to n by their quality value add. Move any infeasible checks to the bottom of the list (but note them for subsequent retrospection and possible feasibility solution. Finally, move down the list to an achievable point for the current sprint and draw a line. Everything above the line is your DOD for this sprint. The same process works for the DOR.
Should the Same Definition of Done Apply to all Stories?
Yes if your stories are similar enough to allow for it. Creating multiple DODs adds to cognitive overload and the chance of chasing the wrong definition. Conversely, the DOD for a story about a software feature should not be applied to a story about a marketing guide. The same goes for the DOR.
Should the Definition of Done Change Every Sprint?
Scrum owes its popularity in large part to its simplicity. Scrum teams quickly learn the process and agree on. the DOD and DOR in Sprint Zero. From there, they focus on working software delivery rather than on the Scrum process. Changing the DOD will add friction as the team must renegotiate the DOD and relearn old habits.
If the sprints are similar, there is little reason to change the DOD, however the sprints may not be dissimilar. For example, what if the sprint goals are radically different? What if the team must deliver to an externally imposed and unreasonable deadline? In cases where the sprints are radically different, then change the DOD. Teams should still go for less DOR change than DOD change when the sprints are different.
Should the Definition of Done Requirements Bar be Raised Every Sprint?
The more stringent the DOD, the higher your quality will be subject to the constraint that you continue to release frequently. If a Scrum team prizes quality over quantity, then it should aim to raise the DOD bar whenever velocity increases. Often new DOD requirements and velocity increases are the same thing, e.g., adding BDD requirements to the DOD may simultaneously increase velocity. The same goes for the DOR.