Scrum Roles – Product Owner

March 19, 2017

Note: This is one in a continuing series of posts re Scrum Intro.  The preceding post is here.

The Scrum Guide does not ‘require’ you to have a fully dedicated team.  I think if you read it carefully, you will see that they are urging you to have a fully dedicated team.  Certainly I strongly suggest that you do that.  And I know that Jeff Sutherland strongly encourages that.  And a stable team.

The key reason: life is simpler for everyone.  One team, one goal.  There are several other reasons.

OK.  Now let’s turn to the 3 Scrum roles.

Let’s start with the Product Owner (although one could start with any of the roles).

Product Owner

The Product Owner (PO) ultimately owns the quality of the Product Backlog.

But, before that, he is responsible for articulating the vision of what the Team is trying to accomplish.  And he (or she) must explain the vision in such a way that the Team is inspired.  Not everyone can do that.

Then the PO enables everyone to contribute to the Product Backlog.  And tries to do things (eg, talk to people in various ways) to assure it is the best possible Product Backlog and will fulfill the vision.

The PO is the final prioritizer of the Product Backlog.  This is perhaps the most essential attribute of the PO.  For example, the business stakeholder may offer their opinions. Typically they disagree with each other.  So, the PO must take the best information available, and decide.  And decide quickly.  Not everyone is decisive.  And the PB must be.

The PO should inspire the Team.  We said it above, but let’s emphasize.  The PO should explain the vision and everything else so well, that of course the others in the Team feel that this product is something that they want to do.

The PO must help  the company organize the ‘details’ that go to the Team, so that they build the right thing, and mostly build it sooner rather than later.  Getting all the right people to give all the right details in a timely manner, just enough, just in time — this is almost always something that the company is not good at doing at first.  And, to be fair, it is just hard to do.  Even the customers do not know what they want (the full solution), and do not even explain the problem very well.

The PO must work with the rest of the Team daily.  For example, every day the team members should have questions about ‘the requirements’ (at least this is very typical) and the PO must answer them all quickly.  Ideally in 10 seconds, but 10 minutes would be ok.  In 24 hours at the outside.  Well, to be fair, answering within 24 hours in a large organization can be tough.  Make it a lot faster on the turnaround.

The PO likes to work with the ‘geeks’.  (I am teasing now about the divide between ‘the suits’ and ‘the geeks’ that many firms have now. We want them to learn to collaborate.)  The PO should like to learn about Technology.  This is important for her or him to order the PB better.

The PO is working with others outside the Team on what I call ‘release plan refactoring.’  The Scrum Guide calls this product backlog refinement.  Other names of this rough type of work are backlog grooming and pre-planning.

The PO has to ‘herd the cats’ — the business stakeholders.  (I recommend 4 of them.  We will discuss them later.)  This is often hard.

The PO is a kind of leader, but the PO is not ‘the’ leader of the Team.  The PO leads, of course, in deciding how to prioritize the Product Backlog. The PO leads by inspiring, and by articulating the vision.  But the PO does not lead in any other way.

In general, we typically want the PO to come from ‘the business side.’  Several good things typically result from that. It can be ok if she (or he) comes from ‘technology’ (or whatever your firm calls it).

In general we expect the PO to understand these areas well:

  • the Customers (internal or external)
  • the Customers’ problem
  • the current Product (or Product set)
  • the competition
  • our business model
  • the business situation
  • the people on the Business side (who understand all of these things and the details well — so that the PO can, for example, help pull together the right details for the Team).

In general, we expect the PO not to know much about technology at first.  But, by working with the Team, the PO starts to understand technology better and better with time.  We want that.

How much allocation?

How much should the PO be allocated?

In general, always more.  It is a key problem.

If they have a 100% allocated Team of 7 (which I usually recommend), then the PO also should be 100% allocated to the one Team.

It makes a huge different!

As one example: One of our key problems always is ‘unclear requirements’.  It is up to the PO to address this issue well. It’s a lot of work.

In general, a 1 to 7 ratio of allocated hours is a reasonable ballpark.  (One PO hour for every 6 hours from the 5 Doers and the ScrumMaster.)

Over and over and over….one of the biggest impediments is that the business side has not allocated enough time of the person who is playing the PO role.  At first, this is near universally the biggest impediment.

You can back-fill some.  For example, you can add a Business Analyst to the Team or maybe a couple of part-time business analysts outside the team, and that can make things somewhat better for a while.  You really need (also) more of the PO, that person — almost always.

A good PO highly allocated can improve the productivity of the Team enormously.  Well worth the expense.

It is probably better to have an A product owner part-time than a D product owner full-time.  Still, it pays to have the A product owner allocated full-time… if the Team is working on an important project. (Well, they are working on one of the top projects in the company, right?)

Related: New product owners are never very good.  The person is often very good at the old job.  But the PO role is notably different.  The new person needs help in riding quickly up the learning curve….as I say it, to try to emulate the Wayne Gretzky of product owners.  This is hard to do if your company has no ‘Wayne Gretzky’.  In any case, get the new POs some more training and coaching and other help to become better.  It is trouble.  It is very much worth it.

***

Next we will discuss the Implementer (or Team) role.

That post is here.

 

« « Connecting Agile Planning to Agile Action – 1 || Pictures I draw in the course » »

Posted in: Better Agile, Scrum Intro
Tagged:

One thought on “Scrum Roles – Product Owner”

  1. school grants

    I’m impressed, I have to admit. Rarely do I encounter a blog that’s equally educative and engaging, and without a doubt, you’ve hit the nail on the head.
    The problem is an issue that not enough folks are speaking intelligently about.
    I am very happy that I found this during my search for
    something regarding this.

    ↓

Leave a Reply