Product Owner Place In Scrum Team

You will inevitably get advice from others on this forum about roles and responsibilities. I'd like to get in first and advise you to keep the Scrum Values in mind.

If the entire team (you included) embraces the values (commitment, courage, focus, openness, and respect), this problem will be a lot easier to resolve.

I'm also curious about why it seemingly occurred to you to raise it in a retrospective, rather than first discuss it with the Scrum Master. To be clear: I'm not suggesting that either option is better than the other.

this team member disagreed with it being brought in as they saw another thing as more important

More important to whom?

As the Product Owner, how do you believe stakeholder value should be determined and maximized?

I'm also curious about why it seemingly occurred to you to raise it in a retrospective, rather than first discuss it with the Scrum Master. 

Because the person in question was the Scrum Master, they are in a dual role.

Hi Jade, I will try to help you by stating what I am missing in your post, instead of going into details about the content...

If I summarize you correctly, the PO has a hard time convincing about importance and/or the Dev team overrules it.

1. The PO decides what brings most Value. Importance is not necessarily the same thing as Value though. it might help to get a clear perspective on these concepts yourself, and try to explain this to the team.

Next to that, given the concept of Value, there is only one person who knows best: the PO. Since the PO talks to (all) the stakeholders, no one else has a better picture of the land. And don't forget, the Dev team can be seen as a stakeholder on its own. When it comes to technical dept, bugs, infra etc. If you involve them as such, and sit with them as you hopefully do with your other stakeholders, you can way better determine what has most Value.

2. You talk about work of the Dev team, but I hear nothing about Sprint Goals. Keep in mind that in the end, it is the Dev team who forcasts the work, not the PO. This is not about Value though, but about work needed to be done to deliver the Sprint Goal. Once the Sprint Goal (and why it brings Value), it is up to the Devs to plan the work needed to be done. That gives them autonomy, and freedom within the boundaries of the Sprint Goal. If work is planned without a clear correlation to the Sprint Goal, it is up to the PO to ask questions why it is planned. Since you seem to have a debate about importance (let alone Value), could this be because Sprint Goals are not clear, or not there at all?

So, having clear Sprint Goals and explaining Value could help out a lot here, next to paying attention to what the Devs want and more importantly why. Collaborate with each other, preferably before Sprint Planning starts, to make sure you have all the information you need to explain Value during Sprint Planning.

Last one, don't know if applicable, if you feel there is a Role challenge, a challenge in your "authority" as a PO, and if you feel you lack the knowledge or skills to address this on a personal level, you can always explain your concerns to the Scrum Master, and ask for help to coach you as a PO, and coach the team on roles and responsibilities

To understand what the disagreements are actually about, can you elaborate on what kind of suggestions you do, and what kind of objections the developers express?

I've seen this situation before.

I'm trying to learn from Ian so I'm addressing a question first: If you leave to a developer (or to the entire development team for that matter) the ultimate decision of selecting work for a sprint, how would they know what's of value to the business?

And an answer ...

Imposing work on the team would be unwise. Equally unwise would be to let the DT choose their work disregarding the business needs.

While it is of course great to see the development team (or individuals) proactive, the product owner (business representative) has the ultimate say in terms of business value. On many (most?) occasions business value cannot be achieved exactly as the PO wants it, so the PO and the DT would need to negotiate to see what's possible.

But note the sprint planning should come as a surprise to you or the DT. In any given sprint, you'd want to slowly introduce the team to the work/tickets that are of highest importance to the business (based on your determination) - these would undergo understanding/refinement/estimation so the team is well aware of the intentions - and I say intentions because that's what they are. They aren't guaranteed, but forecasted. 

PS: Needless to say, the team should be aware of the backlog itself so every other day (if not daily), a quick review of the status of the top of the backlog goes a long way towards transparency.

should come as a surprise > shouldn't come as a surprise

Since you seem to have a debate about importance (let alone Value), could this be because Sprint Goals are not clear, or not there at all?

It's not that it wasn't there, the goal was very clear. It's that there was a particular item within the sprint that could compromise us meeting the goal which was a bug that had been discovered the previous sprint. The team member didn't want to bring in the work because the bug would block the testing of it if we couldn't resolve the bug.

Imposing work on the team would be unwise. Equally unwise would be to let the DT choose their work disregarding the business needs.

While it is of course great to see the development team (or individuals) proactive, the product owner (business representative) has the ultimate say in terms of business value. On many (most?) occasions business value cannot be achieved exactly as the PO wants it, so the PO and the DT would need to negotiate to see what's possible.

When I refer to 'Team' I am referring to the 'Scrum Team' not the 'Development Team' and what you have described is exactly what I'm asking to be correct? 

But note the sprint planning should come as a surprise to you or the DT. In any given sprint, you'd want to slowly introduce the team to the work/tickets that are of highest importance to the business (based on your determination) - these would undergo understanding/refinement/estimation so the team is well aware of the intentions - and I say intentions because that's what they are. They aren't guaranteed, but forecasted. 

Wasn't a surprise to them, the work I wanted to bring in was initially supported by the team member and the goal was clear however a bug was discovered during testing for the previous sprint that would block the testing for the work until resolved so the team member didn't want to bring the work in if they couldn't commit to finishing it.

the work I wanted to bring in was initially supported by the team member and the goal was clear however a bug was discovered during testing for the previous sprint that would block the testing for the work until resolved so the team member didn't want to bring the work in if they couldn't commit to finishing it.

Jade, this is a completely different scenario than the one you presented in your initial post.   

This sounds nothing like a Development Team overruling you and doing what they deem most important.   Instead, it sounds like a reasonable Sprint Planning negotiation between a PO and the DT.   It sounds like the DT had very valid reasons for not wanting to accept your story offer, since they had doubts about completing it without the defect being resolved.

Keep in mind, as a PO, you are no longer "pushing" work to the DT with the expectation that they will accept whatever you offer every sprint.   Instead, the DT is empowered to accept only the items they feel are achievable within the sprint time frame.   And all of this wrapped up in a healthy negotiation between the PO and DT on what makes the most sense to work on in the next iteration.

This sounds nothing like a Development Team overruling you and doing what they deem most important

Where did I say the development team was overulling me? I said I felt a team member was and I quote:

and one of the development team disagrees with me, it tends to be them (the developer in question) over ruling me rather than the team collectively deciding the best course of action.

I also said:

 I wouldn't mind if this was a team decision, but it feels like it's just my opinion vs one team members opinion.

If the whole team had agreed I would not even be asking this question.

It sounds like the DT had very valid reasons for not wanting to accept your story offer, since they had doubts about completing it without the defect being resolved.

Development Team vs Team Member is a BIG difference and has flipped everything I said to mean something completely different.

Keep in mind, as a PO, you are no longer "pushing" work to the DT with the expectation that they will accept whatever you offer every sprint. 

I wasn't going to force the work in, but I wanted the team to come to that decision rather than the one team member who was dragging the work in saying what goes.

As usual I probably have a slightly different perspective.  Notice I said "slightly".

From the Scrum Guide section on the Product Owner

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team

Also from the 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.

This from the Scrum Guide section on the Development Team

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Going to start there.  As PO you have the responsibility to focus on the value.  Development Team organizes themselves and plans Sprint Backlogs from items in the Product Backlog. In your case I see that both of these have happened.  The problem I have with everything is the lack of respect shown by the one Development Team/Scrum Master (I'll come back to this later) and you as Product Owner. 

In every high-performing Scrum Team I have worked with that has been viewed as successful, there is a high degree of trust and communication.  Trust comes when everyone realizes and recognizes that no one will intentionally do anything that causes harm.  Both of you have to trust that actions are being done for the right reason. As you said, if this had been handled differently it would most likely not have been a problem. I applaud you for that. Many POs I have worked with don't reach that level of consciousness.  In this case I don't think that everyone fully understood the importance of all of the items being discussed.  The Development Team member had a very valid point for why that item needed to be taken into the next Sprint but did it in a way I don't see as productive.  It would have been better for all of you on the Scrum Team to discuss if it would be possible to get both into the Sprint, even if it meant taking something that was already in the Sprint Backlog out in order for the Scrum Team to deliver the value that is needed. A good way to help this is to craft Sprint Goals as a Scrum Team and then the Development Team will build their Sprint Backlog to accomplish that goal. If during the planning phase it is determined that the Sprint Goal is already in jeopardy a serious conversation occurs about why and what can be done. Under normal circumstances I would suggest you discuss this with the Scrum Master and have them bring it up with the team at an appropriate time. But there in lies the rub...

A Development Team member also acting as the Scrum Master is very hard to do right. Actually having an of the Scrum Roles split across the same person is hard.  As you hear frequently "you can do everything but you can't do any of it well".  Trying to do two completely different roles is a lot of context switching and in that case human nature is to lean more towards your stronger skills and do "just enough" with the other.  If this person is a Developer first, they will not do an effective job of helping the team improve as a team and progress in the Scrum Values. 

Regardless of that last part, if you want to bring this up, I suggest doing it with just the two of you before going to the team. Be sure to approach it calmly and non-confrontational.  Accept and freely admit that neither one of you handled it well and that the two of you should be able to work out a compromise that will prevent that level of conflict.  That kind of conflict is not productive and leads to a poor working relationship.  The two of you don't have to become good friends but you can become great team members when you respect and trust each other. I work with a lot of people that I think are absolutely fabulous at their jobs but would not even consider having a social relationship. Sometimes you have to separate person feelings from respect for the other's abilities. 

It seems I must play devil's advocate now...

Maybe the dev/SM is not perfect with communicating his good intentions, maybe you failed to extract enough knowledge from him to understand the other point of view. Either way, from what you described, you wanted to do in a sprint something that most likely could not be later released, as a bug would prevent it. Maybe what he meant was that development team's DoD count never be fulfilled with the item you insisted on them doing...

I think there were good intentions everywhere, just bad communication and misunderstanding. It is good to have in a dev team someone (anyone!) who will prevent the team from breaking its own DoD. Someone, with courage, has to speak up, and he did.

I am going to stop reading/responding on this topic now because I feel like I've got the information I needed from a select few who have given good responses that I can take with me.

Yes I could have communicated the value better, and will do so in future.



It wasn't a case of me trying to force work onto them or that I didn't 'understand that person's point of view' because believe me I did. It was about me feeling my side was immediately shut down with lack of empathy/understanding and it was about how the outcome was decided by one team member, not the overall team.

Team member/I have spoken and have agreed it could have been handled better and have agreed any disagreements should be talked about as a whole team.