I was asked this question today and I think there is a clear answer, however it may change depending on the context of the question.
“During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.”
-Scrum guide
[Question] Can the Definition of Done change per Sprint?
Yes; you can and are expected to make improvements to the Definition of Done at the Sprint Review. Your Development Team should always be asking themselves:
- Do we have the quality level that we need to release?
- Is our quality improving?
- What can we add to the Definition of Done to improve quality.
Every bug found in work that was done in a previous Sprint is a possible quality issue that should result in a stronger Definition of Done to make sure it never happens again. However I am a little concerned that the brevity of the question could result in enabling activity in a way that can be used to suborn the process. There is a distinct lack of context to this question that could change my answer from a yes, to a no.
[Question] Can the Definition of Done change per Sprint so that we can reduce quality and deliver more features?
The resounding answer here is no. You should never reduce quality as its not within the authority of a Scrum Team to reduce quality. The quality of the product equates to the value added to that product through capital investment. If one chooses to reduce quality then that change in the ROI of the capital investment needs to be reflected in your financial statements. If you are a private company, then I would think that your Shareholders would be unhappy if the value of an organisational asset is misrepresented! What about if its a public company? Now we are in the realm of fraud!It is a board-level responsibility to actively reduce quality and the ramifications of that reduction should be presented to your board. A Development Team does not have the authority to lower quality, the Product Owner likely does not have that authority, and your IT Management definitely does not. When I am approached with this question by teams, I always say: “Let’s go have a chat with the CFO and make sure he understands the ramifications of a deduction of quality on his capital investments.”I’ve never had anyone take me up on that offer.
[Question] Can the Definition of Done change per Sprint because we have different DoD for each backlog item?
No, you should have a consistent DoD that is applied to all of the work that you do, and that represents a usable increment. Sometimes I see some confusion between DoD and Acceptance Criteria. DoD is about how we do things and covers engineering practices, Development Team standards, coding standards, architectural standards, and other Development Team standards. It should reflect both product and engineering qualities. Acceptance Criteria is about the notes that we have to take when we are discussing what we are going to deliver. This is the bit that is different for every Backlog Item.
[Question] Can the Definition of Done change per Sprint because we just like mixing it up?
No; The purpose of the Defenition of Done is to maintain transparency of the past by allowing everyone to understand what a “usable increment” means.
If we keep changing the goal posts how can:
- Does the development team determine if a Backlog Item fits in a Sprint if we don’t know what we will do for it?
- Does the development team create a Sprint Backlog that contains the about of work that they believe that they can reasonably achieve?
- How does the Product Owner or the Stakeholders understand what they are looking at at the Sprint Review?
- Do your stakeholders understand their return on investment?
On a brownfield project that moves to Scrum, I would expect your DoD to start week, and not reflect releasable. Each Sprint Retrospective, your Scrum Team, should review your DoD and get it closer to releasable. As you make the changes, you will discover more technical debt, and it may take some time to pay it off. Keep improving until your definition of Done mirrors shippable. On a Greenfield project, you should always start with a definition of Done that mirrors shippable and have shippable product every Sprint, including the first one.
There are no right answers, only things that you try to discover if they are right for your Team.
