Becoming a Better Product Owner

Let's talk quickly and summarize some things you might do to become a better Product Owner in a Scrum situation.

My apologies, but we must start with basics. These should all be common sense. Or at least some of them should just be common sense.

But common sense is not very common.

• Get enough time to do a professional job.

With a Team of 7 people with decent through-put, this is a full-time job, or nearly full-time. OK, maybe this depends a bit on who else is helping the PO.

Commonly, you have not been allocated enough time.

• Define the job.

Or at least start to. Almost always it is notably different than your former job (that you were very good at). And your ScrumMaster, you (the PO), and your manager are not yet in agreement about what the job is.

Then, see the first bullet again.

• Get training.

Take the CSPO course.

It is incredibly silly to try to do the job without training. And arguably two days (16 hours) is not enough.

Let's repeat the obvious. To quote Yogi Berra: "You have to be very careful if you don't know where you're going, because you might not get there." In other words, a PO or a better PO can make a big difference.

• Answer the Questions faster.

The Team will always have questions about the "unclear requirements." You must figure out how to answer those questions faster. Truly makes a difference in their productivity.

• Answer all the Questions before the Sprint starts

That is, for the 8 or more stories about to go into the next Sprint, you must work with people and get all the needed information before each story goes in the Sprint.

This means you must work with other people. I call those people, for fun, the Minions. (See Despicable Me 2. Or other movies.) [Note: "Minions" will probably not work in your organization, as some people have an insufficient sense of humor, and may become offended. Call them something else then.]

These "minions" are the people who will help you pull together all the details. Might be someone inside the Team. Usually (also) includes part-timers outside the Team. It varies a lot, from situation to situation.

This is the Definition of Ready idea or the Enabling Spec pattern (see A Scrum Book by Sutherland, Coplien et al or see ScrumPLOP.org).

• Use Business Value Points

Work with the Business Stakeholders in voting the relative BVPs for each story. Fairly quickly at first. Mike Cohn asks that we call this Priority Poker. A game, for more purposes than just fun.

This is wide-band Delphi expert estimation, and very similar to story pointing (Planning Poker). They are relative BV points.

They will help a lot. Maybe most in helping your group prioritize your stupidity. By which I mean: what knowledge should we seek out first? To make the BVPs more accurate sooner.

• Identify a Minimum Viable Product

Your own opinion, which soon will be better than any other opinion.

Try to deliver sooner. Try to listen to all the other opinions. No two people will agree. You will never know everything. Now decide. At least decide for now. And keep building, and along the way you will make a better decision.

At some point, you have a final decision on this MVP, and you "release" it.

• Define a Product Strategy for now

I mean: This is Release One, then we'll add these features for R2. Then these features for R3.

It should be an approach that will help you learn, that works for the customers, and that helps you deal with (if not defeat) your competition.

Again, get help from many people, but you must decide, with imperfect information. And decide again later, when you are smarter.

• Learn more about the Customers, and what is changing

You must be the Futurologist. You must get to know the customers better. Their problem, their hopes and needs, and how their marketplace (situation) is changing. And separate their real needs and wants from what they say they want us to give them. And you must predict the Future, as best you can, in all its relevant dimensions. The customers don't use the product in the past or the present. Only the extended Future.

If you learn faster about the customers and the Future, you will order the Product Backlog better.

Conclusion

Did we give you enough ideas of things you can work on to become better? Did we miss any big ones for you? (Surely we did for some people.)

You must prioritize them, and work on one at a time. (But probably more than one per Sprint.)

Work hard. Have fun!