Skip to main content

Product Owner - responsibilities

Last post 07:23 pm October 25, 2018 by Daniel Wilhite
8 replies
08:59 am October 24, 2018

At the moment we have a discussion with the product owner about who is responsible for the content of the tickets in the sprints and their descriptions. The product owner is of the opinion that I, as client / customer, must check all tickets and descriptions to see if they are complete.

I believe that the product owner is responsible for the translation of the customer's wishes (I) so that they are clear to his team.

 

Do you agree?


03:29 pm October 24, 2018

Yes, the Product Owner is responsible. Why though, is the PO asking you to check items for completeness? What reason does he give for it in this case?


03:50 pm October 24, 2018

The PO is responsible for the content, condition, ordering, and understanding of the backlog. But there are times that the PO will request input from others to ensure it is right. 

From the Scrum Guide in the only area in which Refinement is mentioned.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items.

From Scrum Guide section on Product Owner

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

I would see the activity that your PO is requesting as an extension of the refinement activity. As the client you are major stakeholder. It makes sense to me that the PO would ask for you to validate that they have correctly understood and captured the problem that they are asking the Development Team to solve. 


09:15 pm October 24, 2018

I agree with Dan. I don't see anything wrong in the PO asking a client to validate if the description and acceptance criteria that has been captured, is correct, before it is sent to the development team to create. From the perspective of time, value and cost, when you, the client, has an opportunity to inspect the work before it is started, wouldn't it be beneficial to you? What if something was captured incorrectly and after a 2 week sprint you realized something was wrong, wouldn't it again have to be re-prioritized in the next sprint? I think the right (Lean) mindset here is to get it right the first time.


07:23 am October 25, 2018

I disagree. Asking the stakeholder to validate each and every PBI (or even Sprint Backlog Item, not sure what "Tickets in the Sprint" refers to in this case) is inherently wasteful of the stakeholder's time (which seems disrespectful to me) and also seems to me like the PO is not accepting responsibility for their work and instead trying to get the customer to do it. I can only speculate as why that would be, but prefer not to. If that is the case, this would also indicate a lack of commitment on the part of the PO.

(I'm going to shamelessly link to one of my articles here, where I've looked at the problem of people trying to delegate responsibility 'upwards': https://www.linkedin.com/pulse/delegate-responsibility-downwards-upward… )

There is nothing wrong with a long discussion/conversation between PO and stakeholders, so that the PO can make sure, they understand the stakeholder needs. It's also fine for the PO to give them an overview of what the Scrum Team is planning to do to satisfiy the needs. But using the customer as what is essentially a quality gate for tickets seems wasteful to me.


12:57 pm October 25, 2018

Having the PO verify content with the stakeholder/client is one thing, sending the tickets/stories to the client and expecting them to read through each one to validate the content is absolutely ridiculous. That is the job of a PO. I have an idea guys, Go order something that is custom made; say a guitar. You call up the sales guy, put your requests in, you discuss about the details and timeline and all. 3 days later, you get an email from the sales guy asking you to verify the order. You open the attachment and it is a 100 page document with the all of the instructions, including specific measurements for certain components, filled with luthier (developer) jargon that makes no sense to you. How would you feel as the customer? I would immediately think "what is the point of having a sales guy if I have to do his job?"

Like Is said, verifying a few things, is 1 thing, expecting the client to go through each story and approve is asinine and completely NOT agile. 


06:53 pm October 25, 2018

The product owner is of the opinion that I, as client / customer, must check all tickets and descriptions to see if they are complete.



To me, this is just a variation of the contract game, which is anathema to all things Agile.   



Julian stated it very well - this process places a refinement-based quality toll gate burden on the client/customer, when the PO needs to actually be the de-facto client/customer for the Development Team.   Any uncertainty between the PO and client/customer should be worked out before it is even introduced to the Dev Team.


07:10 pm October 25, 2018

Do not forget the sprint review and short iterations.  PO has to listen and find a common ground with stakeholders, if he never does then PO needs training in soft skills asking correct question. Backlog and things connected to it are owned by PO.

No PO is perfect but that is the point of SCRUM, short iterations and sprint review (stakeholders can be present), adjust on the way. If stakeholders is really disappointment after 2-4 sprints review, i think PO would do better job next sprint and deliver better value. We all learn by making mistakes.


07:23 pm October 25, 2018

I don't disagree with anything that anyone said.  In fact agree wholeheartedly with everything said after me.  I admit I missed the all in this statement

The product owner is of the opinion that I, as client / customer, must check all tickets and descriptions to see if they are complete.

I was assuming it was a "sometime thing". If they are asking to review and approve them all, then there is a serious problem.  The only time I might be ok with this would be if there was a language barrier.  In that case it might be prudent for you to look over things. I've been involved in development where the language barrier ended up in a complete mess. 

I apologize for missing that one word. It changes my entire opinion on this.  Asking for a review of a few tickets is ok.  Asking for all of them is so anti-agile that it hurts to think about it.

Thanks @Julian for catching that and calling me out.  I owe you one.  :-) 

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.