BT

Can Product Owner and Scrum Master be Combined?

by Mark Levison on Dec 11, 2008 |

Many short staffed teams or small organizations consider combining the role of Scrum Master (SM) and Product Owner (PO) into one person. Is it advisable? Have other people done it? What are the options?

According to Mike Cohn, author of Agile Estimating and Planning, the Scrum Master is:

...responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster protects the team by making sure they do not overcommit themselves to what they can achieve during a sprint. The ScrumMaster facilitates the daily scrum and becomes responsible for removing any obstacles that are brought up by the team during those meetings. The ScrumMaster role is typically filled by a project manager or a technical team leader but can be anyone.

In addition, the Scrum Master owns quality on behalf of the team.

Whereas the Product Owner is:

... (typically someone from a Marketing role or a key user in internal development) prioritizes the Product Backlog. The Scrum Team looks at the prioritized Product Backlog and slices off the top priority items and commits to completing them during a sprint. These items become the Sprint Backlog. In return for their commitment to completing the selected tasks (which, by definition, are the most important to the product owner), the product owner commits that he or she will not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.

As Matt Gelbwaks pointed out, the Product owner is responsible for concepts and ideas (i.e. the backlog), while Scrum Master is responsible for execution and quality, so the Product Owner wants more features while Scrum Master is focusing on getting it done. Tomek Wlodarek explains that the different points of view are only half the problem. The other half is the time commitment: "In a corporate environment what I learnt is that a SM is a full time job for a team as big as 5-6 people. ... the PO role for that team turned out to be 60% - 100% job."

Dan Rawsthorne, Coach with Danube Technologies, wrote:

I've done it, back in the day before I knew any better. ... I combined the PO, SM, and Lead Designer roles. In order to keep my team self-organized, I used to have skits in front of them: "on this hand... on the other hand... what should I do?" It worked out, but was very difficult, and I never want to do it again, and I don't want anybody else to try it either.

Tom Mellor has also seen it work once, noting that it took a rather unique individual who is coaching full time now.

Steve Eichert, had the most optimistic answer saying "Assuming a single person is able to fill both of these roles by not mixing and matching it seems feasible that they could be done by a single person if absolutely required.". However, even he recommends keeping them separate.

Finally Ken Schwaber noted (in a CSM class) that experienced Scrum Master could pinch hit for the Product Owner until a proper one has been identified and trained.

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Can Versus Should by Lukas Bradley

Just because you can do something doesn't mean you should. I strongly feel these two roles should be separated. Too often in my experience these roles are combined (whether in an Agile process or not), and one or both functions suffers.

Furthermore, I feel as if the two ideals presented (quality and concept) do clash at times, and it takes two representative positions to champion each.

If a small team can't afford both, I can understand the need to combine the roles. It should be noted this action creates great risk to the project as a whole, in my humble opinion.

PO's by the dozen by Will Read

Coming from an organization of 25 and a development team of 6 we had one person who played both parts of SM and PO. He was SM first and PO only because we had a half dozen people from sales, to customer support, to marketing, to technology with strong opinions about what was high priority, and so our SM because the defacto PO as well.

It worked better than those six people trying to go directly to a team of 6, but I would also agree that something was lost. As Dan Rawsthorne points out, the two positions are designed to oppose each other. The struggle between the two, assuming it remains a productive struggle, results in the right features being done on a schedule that is realistic for the team. Combining the two roles into one person seems like it would create enough internal struggle that it becomes easy to resort to apathy or just burn out.

in certain situations, yes by Jason Little

Obviously it's best to have a dedicated product owner as there is much more to product management as a whole than what the scope of the product owner is by definition.

In smaller organizations you might not have much of a choice but to have them as one role or at least have some PO duties fall into the SM's lap. I think it is possible with smaller teams but I do agree a PO role should be 100% of 1 person's time.

Unless your Steve Jobs... by Mike Bria

Sure, in the rarest corners of the earth exist a human in a situation who can effectively set the strategy & creative direction whilst still having active, tangible involvement in driving the day-to-day execution activities...but good luck finding that.

In all but the rarest situations, having a single person fill both these roles is as destined for problems as having your offensive coordinator be your quarterback.

Hell, even if ya got a Steve Jobs situation, both roles simply take too much hands-on time (to do well) to be handled by a single chap, as Wlodarek astutely notes.

Devil's Advocate... by Kevin E. Schlabach

I think they should be separate roles... but...

You create a start-up... you hire 5 great agile developers. You run...

Guess what, you are probably the CEO, PO, and SCM all at once until that situation grows a bit.

My point? In small enough environments, it can be a practical solution for a short window of time (1 year).

Re: Devil's Advocate... by Mike Bria

Okay, in a company small enough with a product embryonic enough where "everyone is everyone", it may work. Still prolly a risky endeavor.

Re: Devil's Advocate... by Matt (AgileMan) Holmes

We tried the combined PO/SM role in our organization and got just about exactly the results that you'd expect:
  • - those stretched-thin individuals focused more on their PO duties than their SM ones, to the detriment of the development teams who needed coaching
  • - whenever schedule pressures were brought to bear by our executives, owners or customers, the PO/SMs would transfer those demands directly onto the teams, rather than either shielding them or working to arrive at reasonable trade-offs
  • - an "us vs them" divide opened up because the development teams felt betrayed by being told one thing (that the SM was there to help and protect them, as well as hold them accountable) and then shown something entirely different (pressure to commit to unachievable deliverables and then blame when failure ensued)

I'd certainly never agree to work in an environment like that, again... and I wouldn't recommend it for anyone else, either!

Scrum Master should not "own quality" by Lasse Koskela

I disagree with the notion that the Scrum Master "owns quality on behalf of the team." Okay, the main disagreement might be due to wording of "owning" quality - maybe the intent here was to say that the Scrum Master is responsible for pointing out if the team is cutting too many corners. In any case, I believe it should not be the Scrum Master who is responsible for the quality of the code the team produces. People should eat their own dog food, not their neighbor's.

Don't Use Scrum If You Do Not Have The People by Sebastian Kübeck

It is necessary to have a minimum number of people around to establish Scrum. I don't think that it makes any sense to combine the role of the scrum master and product owner as you do not combine the role of speaker and prime minister in any parliament. You could do that for a short initial period until the product owner is trained to do her job. In very small teams, you can implement the Tracer Bullet process (from Andy Hunt and Dave Thomas) described in "Ship It!".

Re: Scrum Master should not by Mark Levison

Ok we're in agreement, responsible would have been a better choice of words on my part. Nonetheless the key here is that there is a tension between the role of Scrum Master and Product Owner.

Re: Don't Use Scrum If You Do Not Have The People by Mark Levison

Sebastian agreed - but at the end of the day, it may not be Scrum but the issue would still rear its ugly head in agile process.

Re: Can Versus Should by Mark Levison

I think we're in agreement here. The key point is to understand the risk and compromise involved. At least if you go in with your eyes open and question yourself constantly then you will know when you've found some rocky shoals.

Re: PO's by the dozen by Mark Levison

Will - was there a medium/long term plan to separate the roles?

Re: in certain situations, yes by Mark Levison

Aside from all the other issues I would eventually expect the PO/SM to burn out. There is just too much work.

Re: Unless your Steve Jobs... by Mark Levison

Among other things you can't afford to lose that person and the workload will eventually take a toll on their health (look at Jobs).

Too Much Time, Yes, Opposed Interests, Hopefully No by Richard Lawrence

Thanks for consolidating these quotes and links in one place, Mark.

As a practical matter, both the SM and PO roles may be too time-consuming to combine. But the claim that I often hear that the SM and PO interests are opposed and that the dialectical struggle between them produces better software worries me. If the SM and PO don't have the same interests, that to me is a sign of a deeper problem, and better software would result from aligning those interests. I posted on this a few weeks ago here: www.richardlawrence.info/2008/11/26/are-the-pro....

Re: Too Much Time, Yes, Opposed Interests, Hopefully No by Mark Levison

I agree with the point, but I think the tension happens in real life. Product Owners are human and some will want more features in trade for quality. Sometimes they won't even realize that's what they're asking for.

Product Owner role trivialized by Ken Schwaber

All too often, the product managers are opting out of being Product Owner, and letting the analyst be a "proxy." Of course, since most of the descriptions of the Product Owner have him/her as an appendage to the Scrum Team. All he/she has to do is write user stories and play planning poker, with INVEST.
This delegation of product owner responsibilities continues to deep divide between development and its customers. I'm going to try to remedy it with a new product owner course that purely focuses on a Product Manager being agile. He/she can be using Scrum or any iterative incremental techniques, but the point is to be agile, value driven, and opportunistic - not to sit around and write user stories.
Ken Schwaber

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

18 Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.