Definition of Done vs Sprint Goal

> ...Definition of Done cannot be changed per Sprint.

The Definition of Done asserts the quality of the increment. Why don't you think that this quality can be improved during the Sprint? Shouldn't a Development Team be able to improve their DoD once a Sprint has started and replan their work accordingly?

@ Ian

Perhaps this is my "lean" perspective again, but while it is allowable for a team to modify their DoD during their sprint, I would caution against it, since it introduces variability into the sprint (waste).

Activities such as re-planning work, new tasks to meet the added DoD criteria, and determining if the sprint goal can be reached under the new DoD, are all "extra" activities introduced into the sprint because of the mid-sprint change to the DoD.

I think another consideration is the timing of the suggested DoD change. Is it occurring at the beginning of the sprint, in the middle, or towards the end? Certainly a late-sprint DoD change is unwise as it increases the risk of the sprint goal being missed.

My preference would be to enact any DoD changes at the start of a sprint, and to allow the team during Sprint Planning 2 to evaluate the impact of those changes against both the offer and the sprint goal. This way, expectations are set both internally and externally around sprint work, and there should not be any "revisiting" of forecasted work or tasks needed to meet the DoD.

Any effort expended on the replanning of a Sprint Backlog can be seen as waste, whether it be due to improved quality (e.g. DoD), an improved forecast of the deliverables (e.g. product backlog items), or an improved understanding of the work (e.g. tasks) involved.

Teams must weigh the cost of replanning against the waste incurred by deferring such improvements until after the Sprint (e.g. rework, lost opportunity etc).

The Scrum Guide stipulates that quality should not decrease during a Sprint. Increasing quality however is not proscribed, and this should be viewed in the context of inspection and adaptation of the Sprint Plan. There is certainly a cost to this replanning but only the team can decide if it is worth paying.

As per Scrum Guide the best time for refining the DoD is Sprint Retrospective

> As per Scrum Guide the best time for refining
> the DoD is Sprint Retrospective

The Guide correctly states that the Sprint Retrospective is a formal opportunity to do so. That does not imply that it is the best one.

"Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation."

In Scrum, the best opportunity to inspect-and-adapt is determined by the team, and not by the framework, which is minimally prescriptive.

Though it is an old thread but from PSM perspective-

can we alter DoD in running sprint to include quality improvement criteria? Yes/No/Yes only if Dev team is ok with additional tasks which have been added to digest new DoD and altered DoD does not change sprint goal.

Scrum Guide states: If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Yes, the DoD could be altered during the Sprint to improve quality, and a conversation about the impact to the forecast and Sprint Goal would be wise.

Yes, the DoD could be altered during the Sprint to improve quality, and a conversation about the impact to the forecast and Sprint Goal would be wise.

@Chris Belknap, A follow-up question to this; I guess it makes sense to change the DoD during the Sprint if it improves quality, but in certain cases, especially after several Sprints, if the team realizes that they may have to stop being so strict with their DoD, and they may need to downgrade their DoD (essentially reducing quality), would you advise that they do this at the Retrospective or could this be also done mid Sprint? The short version of the question perhaps is, once we upgrade our DoD, can we then downgrade our DoD based on empiricism?

@Steve Vb

To answer it straight. NO. As per scrum guide, quality goals don't decrease in running sprint. 

And I fail to understand why a team would like to decrease the quality anytime?

To answer it straight. NO. As per scrum guide, quality goals don't decrease in running sprint. 

And I fail to understand why a team would like to decrease the quality anytime?

@Love Gupta, I don't disagree with you regarding the fact that quality goals shouldn't decrease. However, if your team was in a situation where they ambitiously set a Definition of Done which they can't meet Sprint after Sprint, would you then consider changing the DoD even if it meant you have to decrease the "Documented" quality goals? or would you push the team to consistently deliver undone work, because the quality goals aren't supposed to be decreased? How would you get out of that Catch-22 situation?

Inspect and adapt. In my opinion, while improvement should normally be the goal, adapt does not mean improve. If the whole Scrum Team agrees that the DoD was set too ambitiously and not realistic yet (after inspection), you can decide as a team to change your DoD so that at the end of each sprint the team can deliver a working piece of software that is of value. 

You do have to keep in mind that the original DoD was set for a reason, so this is probably a level that your team should strive for in the future. Sit with each other and talk about how you can achieve this level of DoD in the future.