Scrum Product Owner Boundaries – Roles and Responsibilities

agileproduct-ownerscrum

In another question, I asked about why I feel scrum turns active developers into passive developers, and it seems that the overall problem is not scrumy (related to scrum), and rather it's related to the bad implementation of scrum. So, here I have some questions about the scope of the responsibilities of PO (product owner) and the limitations he/she shouldn't pass.

  1. Should PO interfere the UI design, when there are designers at work in scrum team? (an example of this which has happened to us, is to replace checkboxes with a drop down list with two items, namely, yes and no; or to make some boxes larger, or to left-align some content instead of centering them on the page, or stuff like that). If yeah, to what extent? Colors? Layout?
  2. Should PO interfere in Design and architecture of coding? This hasn't happened to us yet, but I'm really curious about the boundaries. For example does PO has the right to change the platform (moving from ASP.NET MVC to PHP, or something like that), or choosing the count of servers (tier architecture), etc.
  3. Should PO interfere in validation mechanisms? For example, this field should be required, or we don't need to get this piece of information from user. Sometimes, analyzers and designers confirm that something can be handled behind the scene, like extracting the user profile info from another source, instead of asking for it in UI.
  4. How granular could/should PO get into the analysis and design? For example, a user story might be: "As a customer, I'd like to be able to buy new domains online". However, scrum team can implement this user story in a wizard of five steps, or in one single page. To which level PO should monitor, or govern, or supervise the technical analysis, design, and implementation?

I asked these questions to judge whether our implementation is right or wrong?

Best Answer

In general, the role of the PO during a sprint should be passive, i.e. provide feedback when asked for it, but not micromanage the work of the team. Any changes that result from such feedback have to be weighed against other priorities. But ultimately, the PO represents those paying for the project and thus calls the shots. As for your specific questions:

  1. If the PO has detailed expectations about the design, these should be provided as a branding / CI guide before development starts. Demanding lots of detail changes only after seeing the UI in development is not ideal, but if the PO feels these changes are very important and is willing to accept the consequences, i.e. features dropped out of an iteration because people had to implement the desired changes instead, that's OK too.
  2. Choosing specific elements of the architecture is certainly the domain of the PO, but very much something that should be done before development starts. Fundamental changes later on will cause massive delays (it's pretty much guaranteed you'll have to abort the current Sprint and use at least the next one mainly to implement those changes). Again, if the PO accepts the consequences, it's his decision. If no, it starts to look like the project lacks the main foundation of Scrum: the assumption that everyone is working on a common goal and making rational decisions on how to best get there.
  3. Again, it's ultimately the PO's decision, and this kind of thing is perfectly OK to discuss with the PO if there are open questions, since he may have domain knowledge your analysts don't have. But if he insists on doing things differently than those who have studied the problem recommend, and without providing a rationale, then that also strongly hints at someone not well fit for the job.
  4. Whether to implement something as a wizard or a single complex page is a very good example for something the team could ask the PO to make a decision on. But having him give constant feedback on details is not efficient. Basically the idea is to have the team implement a complete usecase and only occasionally get feedback on things they are not sure about or when they have completed a significant piece of work. To get back to your example: after getting the PO's decision, the Team might create a GUI mock-up for the complete wizard or page, show that to the PO to get feedback, change one or two things and implement it, then show the complete implementation in the sprint review.
Related Topic