What are the boundaries of the product owner in scrum?

Question

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?

Answer 1

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.

Answer 2

1.Should PO interfere the UI design, when there are designers at work in scrum team?

I think yes, the PO has the ultimate world in UI/usability issues. Of course, it is the developers' responsibility to assess possible options from the technical point of view, and even to point out potential usability or whatever kind of problems. But ultimately, if the PO is willing the pay the price (whether in cash, lost development/user time, lower productivity, or ...), it is his/her right to choose.

The developers may also try to demonstrate the infeasibility of an approach with a quick prototype, and/or using the feedback cycle of early and regular releases. And of course it is always useful to try to understand why the PO prefers a specific solution - it might be that (s)he has a good reason for it. Communication is always a prime factor in being agile.

But ultimately, there are POs who (sometimes or regularly) make stupid decisions. I don't think it is a problem of the process per se. In fact, Scrum/Agile gives a lot of possibilites to discuss the pros and cons of specific approaches, and allows the PO to change his/her mind relatively easily. This is way more than what traditional process-heavy approaches offer.

2.Should PO interfere in Design and architecture of coding?

Depends on the definition of "interfere" :-) It is the developers' responsibility to evaluate all possible architectural choices (e.g. using Oracle vs using MySQL), and uncover all potential costs, risks and benefits. After that - even though developers make suggestions/preferences, which normally should be taken seriously - ultimately it is the PO's right to choose. E.g. it may be that - even though Oracle is way more expensive than MySQL, and technically not superior for the task at hand - the PO chooses Oracle because all their existing infrastructure is Oracle based.

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.

I think this is basically a usability issue, so it is a subcase of question 1.

4.How granular could/should PO get into the analysis and design?

The example you bring is again a UI design problem, not a program design one. So again, case 1 applies. Program design, however, should be the developer's area since the PO usually has neither the expertise nor the interest to get involved in that.

Update

As a bottom line, I feel you have a people issue here: your particular PO may be micromanaging the project, which is not good indeed. I tend to agree with answers to your previous question that this seems to have created a distorted, "scrum but" process, which could be fixed, if you take the initiative and start communicating with your teammates and the PO. If the PO is not receptive to your concerns though, maybe it is better to start looking for a better project/workplace...?

Answer 3

Product owner has financial responsibility for the product.

That says everything. It means that product owner is the first person who will be blamed if:

• Product will not make money
• Product will not meet requirements
• Product will not meet expectations
• Product will not satisfy stakeholders
• Product will not satisfy end users

So what do you think now?

1. Yes product owner can interfere design. The PO should know what end user expects. Perhaps end user uses similar UI in other applications and he simply expects to have the new application with the same user experience.
2. Yes product owner can demand technology. This is called non functional requirement and it exist in Scrum as well. If customer has only Linux server application in ASP.NET MVC will be useless.
3. Yes perhaps customer doesn't want magic on behind.
4. To the level which is needed to maintain information for further discussion about user story. This usually depends on the type of project and its size. Sometimes few notes are enough and sometimes you need little bit more.

Anyway Scrum and any agile methodology is about communication. You should not be at war with your Product owner and Product owner should make only necessary interference to meet customer's criteria. He should not put his personal involvement into developers job. That is their responsibility. Who is responsible to control that team is not usurped by Product owner? The Scrum Master - it is his job to defend the team even against Product owner who transcend his role.

Answer 4

There is an excellent comment to one of the answers to the question you referred to which I think sums it up nicely. Credit to @StevenV who wrote:

Scrum (as all Agile methodologies) be heavier on conversation than direction. The PO should be describing what the end result needs to be able to accomplish, then engaging the designers and developers on ways to get there. – StevenV Aug 16 '11 at 12:17

Answer 5

The product owner should state the requirements. Requirements need to be stated precisely enough so that we can objectively decide that the requirements are met or not met. In the example given, the requirements may have a statement "there should be a drop down list with two choices yes or no", or it may have a statement "there should be an option for the user to make a choice "yes or no"". In the first case, the PO seeing the checkbox can say "not meeting requirements". In the second case, the PO seeing the checkbox can either shut up, or change the requirements (and take the blame for the delay). The PO should NOT tell the designers how to implement the requrements.

In general, the PO is supposed to know what customers want and what they are willing to pay for, and should have some idea about implementation costs (developers can surely give feedback how hard requirements are to implement, and can advice that slightly changed requirements my lead to huge cost reductions). Developers and designers are supposed to know how to develop software, and how to design user interfaces, and they are supposed to be better at it than the PO.

Answer 6

If Product Owner’s do Requirements, and Implementers deliver to Requirements… why can’t the Implementers meet, design, and see how they’ll deliver (Architecture, Design, Code) without the PO? If the Product Owner has to be present – it means he/she hasn’t describe the requirement clearly enough, for those Architects/Designers/Coders to do their job. The Product Owner also doesn’t know the pros/cons, or specifics of how code executes – they are busy talking with customers, requirements gathering.

We’ve seen the damage done by the Product Owner – assuming to know Architecture/Design/Coding… stick with what your primary job is (customers, requirements), do it well… and leave our Primary Jobs we were hired for (Architecture, Design & Coding) to our expertise – “we are a complimentary team (not at odds, or overlapped in responsibility we were hired for)”