Who is responsible for Definition of Done “DoD”? PO or stakeholders?

The PO is the one who accepts the work. His criteria are expressed in the definition of done and the acceptance criteria of the PBI. If the Dev Team breaks down a PBI into tasks, they can apply the DoD accordingly to that task. Usually the PO will not be able to accept the single task, because it is too technical. He can accept the whole PBI once all tasks are done.
If stakeholders accept work as done, you have an external dependency which can be an impediment.

The PO is responsible for accepting increments that meet the agreed Sprint Goal and which are fit for potential release. Work that is not fit for potential release should not be accepted by the PO, regardless of whether or not it meets the Scrum Team's current Definition of Done.

If work meets the DoD but is not acceptable to the PO, then the DoD should be improved. The outstanding work needed to meet this revised standard of acceptability should then be added to the Product Backlog.

I see 2 questions in the original posting.

Allow me to share some thoughts on the latter…

Scrum doesn’t talk about tasks. Under Topic Two we read –
. The Product Backlog items selected for this Sprint plus the plan for delivering
them is called the Sprint Backlog.

i.e. hypothetically speaking, for some teams, the “plan” could be the task breakdown of the PBIs. For some other teams, they may not do so and have a different “plan.”

Agree with @Ludwig – the PO declares the potentially releasable increment as done, and not a committee or stakeholders.

I’m a little torn with Ian’s latter comment and have a slightly different opinion. As a PO, if the Dev Team delivered what was asked of them, within the agreed DoD, I will accept it. Yes, additional work may emerge or we realize we need to get the DoD refined more along the way.

Agreed - The choice whether to actually release or not, immediately, is up to the PO.

> As a PO, if the Dev Team delivered what was
> asked of them, within the agreed DoD, I will accept it. 

What would a PO then do with that delivery, if it met the agreed DoD but was not fit for release?

My thinking is that the Product Backlog should be revised to include the work needed to enable release as per an improved DoD. However, when the Product Backlog is re-estimated its total size may *shrink* because of work done by the team...even if nothing can be accepted by the PO this Sprint.

@Ian --

At the Sprint Review, if its not fit for release, as a PO, I don't have to release it. After all, we're talking about a "potentially releasable increment."

I just have to declare it Done.

What happens thereafter, is another story, no puns intended.
:-)

> At the Sprint Review, if its not fit for release,
> as a PO, I don't have to release it. After all,
> we're talking about "potentially releasable increment." 

If it isn't fit for release then I would say that, by definition, it is not potentially releasable and therefore should not be accepted. The decision to release should be based on immediate market conditions. These conditions can fluctuate independently of the DoD and the product quality that has been asserted.

This is admittedly a grey area, and there are many opinions on what the potential for release actually means.

If I could just focus on what is expected of the PO at the Sprint Review amongst several things....
(Not Sprint cancellation)

What do you make of the following, Ian? --

[Via SG, 2013, Pg. 15]
The purpose of each Sprint is to deliver Increments of
potentially releasable functionality that adhere to the Scrum Team’s current definition of
“Done.”

Imagine the following at Sprint Review --
A) The Dev Team has just demonstrated what was requested (no disagreement from anyone)
B) It adheres to the existing DoD (no disagreements from anyone)
C) The Dev Team asks for confirmation, but the PO hesitates
D) The Team next, looks to you for guidance as a SM

What would you do?

I hope I don't come across as being too picky and am enjoying the thread.

I'd want to establish the reason for hesitation. It could be that the current DoD, despite being satisfied, is nonetheless inadequate and the increment is thereby unfit for potential release.

That would be a valid reason for refusing to accept the increment. The Product Backlog should be revised to accommodate any new work required to meet an improved DoD, less the work actually done.

The DoD is an assertion of quality and not a warrant for enforcing delivery. So although it is correct to say that the purpose of a Sprint is to deliver increments of potentially releasable functionality that adhere to the current DoD, the PO is under no obligation to accept any of it...and should be careful not to do so if the possibility of release cannot be entertained.

> the PO is under no obligation to accept any of it.

So, what part of the Scrum Guide gives the authority to the PO to accept or reject an increment? A PBI?

Note that I'm speaking without respect to the PO's right to decide *whether* to release an increment or not. "Acceptance" and "decision to release" are separate subjects in my mind. "Decision to release" is a business decision to capture value. "Acceptance"... welll... I'm having trouble understanding how "acceptance" is supported in the Scrum Guide.

The Product Owner has the authority to accept an increment or any part thereof. "If part of the work is potentially releasable, the Product Owner typically accepts it".

> Acceptance" and "decision to release" are separate subjects in my mind.
> "Decision to release" is a business decision to capture value. 

I think that's exactly right. The PO can accept work that is potentially releasable, yet decide not to release it because of conditions at the time. Accepting work means deciding that the work *is* potentially releasable.

I personally coach my people to not accept or reject the sprint - it seems odd in a collaborative environment.

The product owner accepting or rejecting anything is really moot. If there's more work, there's more work. If the team didn't see more work before the review, they all discovered something - great - emergence.

The DOD is a collaborative effort to make the target they are shooting toward visible, not some sort of staunch contract.

When should the PO look at work? Immediately and not at the end. Otherwise you're building lean waste and possible work onto poor work. I often tell folks that at PBI completion the PO should review the PBI - that's looking back. The sprint review is to look at what's completed for the purpose of looking forward - how will this change the next few sprints.

> I personally coach my people to not accept or reject the sprint - it
> seems odd in a collaborative environment.

If a PO refuses to accept an increment that meets the DoD, then it is the DoD that is being challenged. While the Development Team are ultimately accountable for their DoD, the PO is still a stakeholder and so its definition should be a collaborative activity.

Recognizing that an increment doesn't cut the mustard, and that the DoD must be improved, is an important part of inspection and adaptation.

On the other hand, it is *equally* important to coach PO's to salvage as much as possible from an increment so the maximum available value is released. A PO is not a king who can turn away an entire silver platter just because one tasty morsel is bent out of shape.

I appreciate all the comments and others also joining in the conversation.

I think there's something rather fundamental I'm trying to ascertain that may be getting lost. Allow me to articulate it a little better, or perhaps start a new thread, if there's some consensus on it. I also think this will help anyone new to Scrum.

@Ian - the quote you have given is under "Sprint Cancellation" in the most current Scrum Guide. The scenario I had described, explicitly mentioned this was simply a Sprint Review. So, I don't know whether that would change your answer...
(i.e. I see a subtlety in these 2 scenarios; In one of them I agree with you.)

So the question is --
At Sprint Review (assuming its not being brought about by a sprint cancellation), if the work to the PBI's are complete AND it meets the current DoD, should the PO not declare it done?
*Yes / No sought*

This question is not addressing --
- Whether the potentially releasable increment is indeed released
- Whether the DoD needs to be updated / refined
- Whether new work will emerge
....the above (and more!) may come about. In my opinion they *should* come about! Here is everything I agree with Charles S, and like his coaching stance.

.
.
.
[Perhaps a poor comparison, but I'll try]
When my spouse calls me from work in the early morning and asks -- "Has our child had eaten, as planned, by 8:30AM so you can drop her off to daycare / school?" is a question to be answered....

She may have had a snack
She may have completed her complete breakfast as expected
She may not have had a healthy meal
She may have eaten everything expected and more!
...whether I delay taking her to the daycare / school is another scenario. Whether, I want to sit down with my spouse and check if there's something different needed in the mornings over the next 2 weeks, is a different scenario.

.
.
.


However, the fundamental yes/ no question remains, and I feel it is important to get to this answer. At this junction, that's what I'm looking for. Perhaps it already has been answered, but a yes / no would help. Thanks to anyone reading so far.

> At Sprint Review (assuming its not being brought about by a sprint
> cancellation), if the work to the PBI's are complete AND it meets
> the current DoD, should the PO not declare it done? 
> *Yes / No sought* 

Yes, the PO should declare it Done.

I think the bone of contention is whether or not that automatically constitutes an acceptance for potential release. I say it does not, as the agreed DoD could be inadequate for release purposes. In other words, during a Sprint Review a need for DoD improvement may be apparent before work can even be *potentially* released.

Yes, the PO should declare it Done.

Yes, now agree completely, and thanks for the yes/no answer.

Also agree that this doesn't have to be released.

> At Sprint Review (assuming its not being brought about by a sprint cancellation), if the work to the PBI's are complete AND it meets the current DoD, should the PO not declare it done?
*Yes / No sought*

----
Let me throw a wrinkle in.

In this situation you described, the PO really has no authority in their role to declare an increment "Done" or "not Done". The DoD is primarily driven and owned by the Dev Team. (though I don't really like the word "own" here). They *do* have the authority to decide, from a biz perspective, on whether they want to release the current increment - but that is an orthogonal issue. ("Done" vs. "Let's release this increment")

(I agree with Nitin that the sprint cancellation thing ONLY applies to Sprint cancellations)

Maybe a more interesting question is what the impacts are in Nitin's mind whether the PO, in the situation he describes, declares something as "done" or "not done". Why does it really matter (in the situation Nitin described)?

Love what Chuck said above.

I agree with Chuck & Charles.
I see too often this anti-pattern of a PO "discovering" the completed PBI at the sprint review, when it is too late for the dev team to use the PO feed-back to adapt :-(

Gee -- I would have enjoyed a Yes/No from Charles, but the wrinkle was just as welcoming.
:)

As a PO, in this scenario, I would declare the items done.


To answer, what would be in my mind on impacts at this junction --
Broadly speaking, it keeps the PO in check!
- Select Stakeholder(s) may be at this meeting intermittently and want to check in to see progress and can challenge the PO (hopefully the backlog is indeed available to all and transparent)
- The Dev Team keeps the PO in check as well
- The SM may offer to talk more at the retrospective on the DoD, or at another junction
-
.
.
.

Impact of *not* declaring done - prepare for conflict and a possibility of poor morale. i.e. if we've got everything done as expected, and with out working agreements, then there shouldn't be a reason to say not done.

This does not dismiss the notion of inspection and adjusting the backlog next to address scope creep or something emerging etc.This will be natural and here again, I like how Chuck described it.

Again, declaring done need not imply release immediately.