How does a Scrum Master "manage" an out of control Product Owner? [closed]

Question

I new to Scrum and while I understand the team concept behind the Sprints, I imagine there still needs to be a guardian for the team who minimizes the interference from Product Owners who are not conversant in software development. What are your successes, and what horror stories have you lived through?

Update:

I am looking for the balance between coding to implement business process vs creating the appropriate architecture for a client. If the product owner is from the business unit there has to be guidance as to what amount of time should be spent on data model, etc.

Definition:

By "out of control" product owner I mean typically some one from the business unit who aggressively sets time frames while having no real technical ability to create that estimate. Typically this person will say: "I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."

Great answers everyone. Thanks for the good input.

Michell

"interference from Product Owners"? Surely if they own the product it's their job to interfere to make sure developers don't go astray ? – Mcchesney

Ownership of outcome vs control of activities? – Michell

The product owner could be interfering with the activities of software development. E.g., "Why do you commit code to svn so often! Couldn't you get the code right the first time?" – Launcelot

I'm voting to close this question as off-topic because it is not a programming question. – Eutherian

Answer 1

"there has to be guidance as to what amount of time should be spent on data model, etc."

Right. That's what prioritization is all about. You define the work, you prioritize. You work according to the priorities.

What can get out of control?

1. Redefining the work before anything gets done?

2. Redefining the priorities before the work gets done?

The solution is the same. Break the work into smaller pieces so something gets done before there's an opportunity to make a change.

If you have short (2-week) sprints, it's not possible to be out of control. If you go for slightly more practical 4-week sprints, then you have a small chance of getting into trouble.

Babette

Answer 2

The responsibilities are very clearly defined in Scrum - the Product Owner defines backlog items and prioritizes them, the developers commit on how much they can do in a Sprint.

So, a Product Owner simply has no authority at all to set estimates. Of course he can still say that he needs something to a specific point in time - that simply happens. But it's still the developers who will say whether it can be done. And if it can't, they have to work out together on how to change the scope or whatever else can be done to get the needs of the PO fulfilled as best as possible.

Now, how exactly the SM should act in a situation where this doesn't work smoothly depends a lot on the specific situation. I'd rather see him facilitate a good relationship and communication culture between the PO and the team than have him shield the team from the PO, though.

Hellish

Answer 3

The product owner is supposed to be the one that shields you from ambiguous or varying customer requirements.

The product owner must not give the estimates.

Haleakala

+1 - I've been in shops where owners come from a Business Analyst or project management background and still don't trust devs to estimate! Leave 'em alone and they'll come round. – Carolinecarolingian

Answer 4

I don't think it's a question of "out of control".

"I need those screens before the next meeting with the Operating Committee next week, so prioritize those work products first. We'll tackle the database after we talk to Operations."

There is nothing inherently wrong with that statement by itself. If your app is properly abstracted, then your DB is separate anyway. The main problem with UI first is more psychological: The non-devs will assume that most of the work is done if they see screens and go bonkers when things "slow down". However, here's what I think your real problem could be:

The person you have flagged as a Product Owner is not owning the product, and so isn't taking on enough responsibility.

The product is the whole thing, not just the "functional requirements" (to borrow terminology). Your SM needs to have a sit down and be adamant that the PO needs to not try to push off understanding the scope of the behind the scenes work that needs to be accomplished. Once you're PO starts to look at the entire scope, then they can actually be your representative to the broader stakeholder community.

Ultimately, your SM is the one in charge of enforcing process. They should act like it.

Bomarc

Answer 5

I've used Agile at two different shops, both times it works well. I don't see how an out of control anything can ruin the system. Before the sprint, you plan all the tasks you will do and guesstimate how long they will take (always round up). Then you can figure out approximately how much work can be done during your sprint.

Most shops use 4 week sprints, and 6.5hrs of workable time a day. When a sprint has been set, you don't introduce new tasks and only unplanned work that creeps into a sprint is fixing bugs in the features you are adding, of course that is suppose to be included in your guesstimate time.

If you want a more specific answer, you need to define what you mean by an "out of control" product owner.

Orangeman

I guess by out of control I mean some one with no technical background who feels they have the ability to set time frames. – Michell

Answer 6

I have two things to say.

You probably have some kind of R&D manager (that is not necessarily scrum master) and that is not a product owner).

This guy can and should (I think) "protect" developers. We were in situation when we had such a guy, and it worked pretty well. He helped us with getting non-functional stuff in the backlog for instance.

Now we don't have this guy. Our manager is scrum master. And he does pretty good job protecting us as well. Though...the problem here is that generic scrum master has no official power, so he cannot say "you are not going to press them this much", but he of course can and should talk if he sees that teem needs help.

The team itself and product owner also evolve with time so that they start to care more of each other. Product owner understands when the team just does not commit to more or says "we need some time for non-functional stuff now".

But then - again - it's nice of course if there's a separate R&D manager whose main responsibility is taking care of developers...then it will be more balanced I think..

We also have support department which borrows developers for support tasks. Sometimes it is difficult to agree what is going or is not going to be done for this or that customer (because support wants it all). For this case R&D manager - a very good idea too..

Ideally, I like the idea going completely lean so that developers don't need a manager or shield...but I don't know whether and how it works...:)

Overcharge

Answer 7

I agree with S. Lott. Short sprints are better. Short user stories can help to. We try to limit our user stories to 2 - 4 days max.

1. Make sure that all your user stories are well defined and that the owner in agreement with them.

2. Once a sprint has started, insist that new tasks cannot be added to the current sprint, but they can be high priority in the next sprint. Shorter sprints make this much easier.

3. Also, in order to remove the imposition of artificial deadlines, you really shouldn't deliver items from the current sprint until the beginning of the next sprint when possible.

The hardest part about agile development is discipline. Once you have a disciplined team and scrum master, the users get used to it and things move much smoother. I'm not sure if you use any software for project management, but take a look at Rally. They have made some major improvements over the past year or so.

Pori

Answer 8

The iteration (Sprint in Scrum) scope should not be changed during the iteration. That's why only one iteration is planned at a time. As S. Lott pointed out, the shorter the iteration, the sooner the Product Owner will be able to get new things planned.

The Scrum Master role is to isolate the Team from such pressure and shall say to the Product Owner that new requests have to wait for the next iteration.

Now the Product Owner role is to maximize the value of the work the Team produces, so if there is a new top-priority item, which could not wait for the end of the current iteration, it is still possible to replace items with similar estimate and that have not been started. This should be the exception, not the rule.

Kesterson

Answer 9

Stick with the clearly defined rules of engagement then you(SM) can rather spend the time leading your team.

Crosstree

Answer 10

An agile team is Consist of Developer, Business analyst ,Tester ,DBA ,Scrum master and Product owner.All are working as one feature based team.

Agile methodology is here to help business to accelerate the faster product development. The product owner can define the priority and change the priority of it. Actually, it is a Scrum team ,who estimate it including (SME, Developer ,designer ,tester…. Everyone).Each team member brings a different perspective on the product and the work required to deliver a user story and one sprint comprises with big and small user story. If Scrum team feels that it can't be done within sprint then it needs to be a divide into the small chunk of the user story and estimate based on the stack trace involved to developed it.

i.e. If Product Owner(PO) want the specific user story need to finish first but if that story included the multiple changes (i.e. Frontend and backend including database) and it can't complete in one sprint , Scrum team can follow below key rules:

Key Elements :

• Divide into the sub-user story based on stack track
• Estimate each user story related to this
• Scrum master should Informed the Product Owner about the timeline to finish this user story based on team current team velocity
• Product owner should be mature enough to understand the timeline as it can't be completed within the sprint.

• If Still PO has the problem for priority ,He/she can consult the Scrum Master/Coach.

  At a glance, Agile is more for helping business but need to take care that it won't overload scrum team . As it is a regular process for iterative development.

Andrews

What's with the Necro? – Armor

Necroing isn't a problem, per se, but in this case it's brought attention to this old thread that's now off-topic, ensuring that it will be closed. – Lead