Clarification of the Product Owner responsibility

The interpretation should be:

The Product Owner is responsible for maximizing the value (of the product and the work of the Development Team).

i.e. the PO is responsible for maximizing the value of both the product and the team's ability to create product increments. This can include, for example, helping the team to find efficiency savings that may reduce the cost per increment.

I agree that the language is confusing as I've never liked it myself. I've submitted an improvement suggestion for the Scrum Guide here:
http://scrumguide.uservoice.com/forums/241958-general/suggestions/66065…

Please create a login and vote for it!

Ian, we could really use your voice on many of the suggested ideas on that site(i.e. not just this one). Get to it!

Ah, so both my interpretations were wrong and there's a third one that I missed altogether. That's one tricky sentence. :) Thanks Ian for clarifying it.

Alan

Well , my 5 cents would be:

"The Product Owner is responsible for maximizing the value of the product and **accepting / rejecting** the work of the Development Team."

Regards to all.

Can anyone point me to the place where the PO is given the authority to "reject/accept" work of Dev Team? I'm not seeing it in the Scrum Guide, so I'm wondering where that is coming from?

Hi all.

I agree with Christiaan that the PO has the mandate to accept/reject all work done within a sprint. But having read the Scrum Guide i can not find it in there, so now I'm wondering where I have gotten this from. I have been a PO for several big projects the last 8 years, and have always (or at least so far back i can remember) been in charge of accepting/rejecting all the work done in the sprints.

The way we have done the Sprint Review is that the SM and Dev Team presents all the work done, although I have seen most of if already in PO QA sessions. I usually bring stakeholders to the review so that the dev team can get the credit they deserve.

But if something is not finished (all the acceptance criteria are not met), then i reject the work and the dev team gets credit for none of the story points for that user story.

In the past i have actually rejected all the work done in a sprint, the team had started and almost finished all the stories in the sprint, but none was completely finished. So the team got credit for 0 of 43 story points

In my point of view, this is a common interpretation of this sentence in the Sprint Review section :
"The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;"

The PO can choose to release (or not to release) the increment in which he or she is a stakeholder. This could be interpreted as "accepting" or "rejecting" the work of the Scrum Team if a release was in fact anticipated.

If that decision amounts to accepting or rejecting the work of the Development Team only, then the PO may have been remiss in his or her duty to maximize the value of the Development Team's work. In other words collaboration might not be what it should be, and the implementation of Scrum may be sub-optimal.

On page 15 the Scrum Guide mentions Definition of Done.
Without defining it, for it is obviously different for all organizations / departments / products.

As a product owner, I have the authority to abort a complete sprint when I conclude the sprint goal is not adding the expected value to the organization.

I would also reject a work item if I concluded that the Dev team has a different understanding of DoD as I, representing the stakeholders / clients. I would do so, if I conclude it jeopardize total cost of ownership.

I'm not saying the Dev team failed. I would say I failed in communicating DoD.

I would suggest that the PO accepting/rejecting work is not part of Scrum. However, if the entire Scrum Team chooses to make that their "complementary practice" to Scrum, that is ok with me and probably doesn't violate Scrum on its face.

In terms of stating what is "Done" and what is "not Done", the PO is simply reporting what items have been deemed to meet the DoD. This state of "met the DoD" is not judged by the PO, but by the Scrum team as a whole. It should be noted that the DoD doesn't necessarily include any input or signoff from the PO at all. The DoD simply means that the increment(completed PBI's) is releasable.

Some on this thread have described the DoD as being different for each story/PBI, where I would suggest that what they are describing might be considered "acceptance crtieria" for an individual PBI, which is also not part of Scrum. Acceptance Criteria are a good practice, don't get me wrong, but they are not part of Scrum innately.

Having said all of that, when I coach Shu level teams, I suggest (but do not require) that they include the following two elements on their DoD(of course they should add more elements):
1. The PO has accepted the PBI (during the sprint, not at end of sprint) as being what they wanted. (I suggest an informal "over the shoulder" check)
2. The PBI meets all of the acceptance criteria for that PBI.

Wrt #1, I say... if the PO looks at the item and still wants changes, those changes fall into one of two categories:
(small, unlikely to jeopardize sprint goal) - follow the "Nike rule" and "Just Do It"
(more than small and/or likely to jeopardize sprint goal) - Put it on the PBL for a future sprint as ordered by the PO.
["small" is defined by the Dev Team since they have the last say on estimates]

Also wrt#1, if you find that your PO is asking for a lot of bigger(more than small) changes when they review completed PBI's, then that usually means your PO is not spending enough time with the team and/or there is a hole somewhere in how the PO communicates and collaborates wrt PBI's. Time to do a root cause analysis at the Retro to see what is going on.

Regarding accepting/rejecting the work, there IS a mention of it in the Scrum Guide under Transparency:

"Those performing the work and those accepting the work product must share a common definition of 'Done'"

It doesn't say specifically here that it's the PO's responsibility, but it's not the Scrum Master's nor the Dev team's, so the PO is the only one left?

The fact that it's the PO's responsibility is made clear in "Software in 30 days" (written by Ken and Jeff):

"At the end of a Sprint, you have an increment of one or more requirements, done and ready to use. Beat it up and make sure it doesn’t fall apart. Make sure its quality is good enough for real-world use. Try the increment with it in combination with all previous increments. A done, completed increment is something you can use. If the increment ever doesn’t work and cannot be immediately deployed and used, don’t accept it. Tell the developers to reestimate in order to include all the work needed to actually finish it. Then put it back in the Product Backlog."

This makes it clear that AT THE END OF A SPRINT, the PO should test the PBIs reported as done by the Dev Team and make sure their quality is good enough. And accept or reject them depending on what he or she finds. This happens before Sprint Review.

Here's another quote about accepting the work from "Software in 30 days":

"If you, like David, ever start accepting incomplete increments, it will come back to haunt you."

So it seems to me like it's pretty clear that it's the PO's responsibility to double-check the PBIs to make sure they meet the definition of "Done" before presenting them as "Done" to the stakeholders during Sprint Review.

I'm pretty new to all this, so please correct me if I'm wrong.

> This makes it clear that AT THE END OF A SPRINT, the PO should test the PBIs 

No, it doesn't quite say that. I

t says that an increment is available by the end of a sprint. That increment should be subject to inspection throughout the time-box...if the PO does not participate in this process then he or she may allow waste to be incurred, and the value of the work done will not be maximized.

However, I think your analysis of the major point about a PO's "acceptance" responsibilities is a fair one.

Alan,

That is a very compelling case. I'm going to think that one over a bit.

I should mention that there might be a subtle distinction here in that Scrum is defined by the Scrum Guide, while whatever Ken/Jeff suggest in their books might just be "generally good practice" (aka "complementary practice") that is not required explicitly by Scrum.

See more about "complementary practice" here:
http://ScrumCrazy.com/newPO

So who is responsible for making sure something is actually done!?
I can't see where this is directly stated or even inferred.


• The Development Team defines the DoD and they are responsible for executing the work.

• The PO is responsible for the value of the product.

• But since it does directly say who is responsible, rather it should just meet the DoD, then is it the Scrum Master, as it seems like it is a rule to be followed by the whole Scrum Team?

• Or does that mean it is the Scrum Team that is responsible?


Considering the importance of such a decision I am not sure why the Scrum Guide does not clearly state this.
If I have missed something then please let me know.

This is quite suggestive but still does not directly refer to the DoD:

"If part of the work is potentially releasable, the Product Owner typically accepts it."
- Cancelling a Sprint

> So who is responsible for making sure something is actually done!?

The Development Team are responsible for making sure that things are done. They are the ones doing the development work and so no-one else is in a position to ensure that work is actioned.

However they will perform this work to a standard agreed with the Product Owner...i.e. the Definition of Done. The PO has a duty to wider stakeholders to make sure that the agreed DoD has been met and that the work is of potentially releasable quality.

Alan described this as a kind of double-checking, which seems reasonable. However this infers that there may be a disjuncture between developers *claiming* something is Done and the PO *agreeing* that it is Done. Hence there is a debate, and a degree of uncertainty, about whether or not a PO is in a position to accept or reject an increment.

Excellent answer! Thank you, I feel much better about it now.

I will pass this new insight onto the team.

My opinion: I've been in the army and this reoccurring theme/idea of (superiors) checking/accepting work by it's people is useful _in that context_, but not in Scrum and software development.


Checking that work meets the Definition of Done, means that that person needs to understand both the "what" and the "how" of how to build a product. That's almost a violation of the trust between the PO and the Dev Team. Dev Team should trust the PO to make the right decisions on "what" to build, and the PO should trust the Dev Team on "how" to best build the selected "what".

The Scrum Master may ask leading questions, in order to make sure the people understands how to use Scrum - that's why the SM is called a "Master". Asking questions (checking), will help the person asked to learn or strengthen understanding of Scrum.
But, having the PO ask the DT _after the work's been carried out_ about things that should've been discussed during the work (or in Sprint Planning), doesn't help learning nor does it help bring trust to the table. Imagine the Dev Team, sprint after sprint, claiming work is Done and then continuously being questioned whether that's true or not! Talk about eroding trust!

I have come to peace with the fact that at Sprint Review, the market (representatives - ie stakeholders) may provide insight around the releasable-ness of the increment, which may lead the PO do reject the increment. A certain feature may be inapt and thus a show-stopper/blocker - work needs to be redone, the increment is thus rejected.

Not sure if the following historic thread would be of interest, but we had a good discussion on what the PO does at the end of a Sprint, when it comes to declaring things "done."

https://www.scrum.org/Forums/aft/1086#5784

Hello,

If. the PO is never available, and when I say never is that he has so much more projects in hand that is really impossible for him to be a "real" part of the Scrum Team, what should the Manager of the organization do.

By the way: The SM already spoke several times with him and explained that the Developers are struggling to accomplish their job without his know-how of what some backlog items are about.

- Should the manager ask the SM to find someone to be in the Scrum Team and be responsible to pass and clear the information with the PO?

- Should the manager work with the PO and his manager to find out what projects can he leave to get more time available to the Scrum Team?

Change the PO is difficult as the company don't have anyone with his expertise.

Letting the team work as it is is also weird as they will send all the doubts to their manager so he could bypass them to the manager of the PO.

Any comments on this?

Thanks.

I see two options here: 

1) the PO could delegate some of his responsibilities to one or more members of the Developers, after ensuring that they understand his vision for the product, because he is still accountable for the product. 

2) The SM makes the organisation aware of the situation and recommends that they hire another PO. 

The organisation needs to understand that a POs workload should never prevent them from driving business value for the products they own as that is their main accountability.  Although a PO can be the owner of more than one product, they should only take on the work they can perform without reducing the required focus for those products. 

If. the PO is never available, and when I say never is that he has so much more projects in hand that is really impossible for him to be a "real" part of the Scrum Team, what should the Manager of the organization do.

How does he know that this product is worth building at all, if there is no Product Owner to account for its value?

If the manager and the organization want Scrum Teams to be successful, then they need to ensure that the teams are self-managed, self-organized and support the 3 roles in the Scrum framework.  

In this scenario, it seems that there is some support but a bit of a fear to offend an important person who is over-extended.  I've seen this happen many times with people in different roles.  They become involved in a large number of things but they don't do any of them as well as they should.  

Managers need to be able to have difficult conversations.  In this case, the manager needs to talk to the Product Owner (or their manager) about the volume of work. If in fact all of the work is vitally important, then the company should hire one or more additional Product Owners so that all that work can be spread and have someone that can pay more attention to each thing.

If you were to talk to people involved in other projects of which the Product Owner is currently involved, I would be very surprised if you didn't hear similar complaints from them.