Imagine this: You have finally decided to start using Scrum at your company. You’ve got everything figured out, a team is committed to wholeheartedly accept this new approach and everything seems clear, except for one thing… you are still to figure out what makes a great Product Owner to lead this team. If you’re coming from a traditional waterfall or simply non-Agile, specifically Scrum, background, you have plenty of great Project Managers, but do they necessarily make great Product Owners?
Project Manager role has been split into two roles in Scrum: Product Owner and Scrum Master. Admittedly, Scrum Master is closer to what Project Manager used to be and do, but what makes for a good Product Owner then? Well, here are the 4 key characteristics of a successful Scrum Product Owner.
1. A project encyclopedia
In short, Scrum Product Owner is a project knowledge base. She/he is the most knowledgeable person of Business logic on the team. Aside from knowing the project inside-out, it’s crucial that this person can see and envision the project as a product, on the market, from a user perspective, looking for the best user experience possible.
During the Sprint planning, Product Owner is a person being cross-examined by the team. A good PO needs to be able to answer any and all questions a team could have about the functionality and present them in such a story telling way that no doubts will be left inside team’s heads after the meeting.
2. Differentiator between the need to have vs wish to have
As mentioned in a point above, a huge part of what Product owners do is trying to identify what actual users need. A great PO will try to use this information to help solve problems users might have, provide them with tools to better do their jobs or fulfill their needs. What this means is that PO’s role is not focusing on the technical solution of the problem, but the need of the market and its users.
Unfortunately, this is where the problem occurs. Most users very rarely know what they really need. Often, however, they know very well what they want, and what they want is more often subjective and a result of the circumstances the users are in. The moment those circumstances change, their wishes change and they move onto the next thing.
In order to satisfy this great pool of circumstances and, as a result, user wishes, a great Product Owner must be able to differentiate the needs that will benefit the larger audience of users, versus wishes that temporarily benefit a group under specific circumstances.
A poor Product owner always tries to satisfy user wishes, while a successful Product owner provides the users with what they need, without them ever realizing they needed that functionality in the first place, that is until they start using it.
To succeed at this, Product owners must follow an old Chinese proverb: “When the winds of change blow, some people build walls and others build windmills.”
3. Value optimizer
You might have noticed by now that each of these points, nicely flows from the previous one. This one won’t be the exception. When you have the complete knowledge of the application, followed by a thorough understanding of user’s wishes versus user’s needs, the next thing you must possess in order to be a successful Product owner is the ability to optimize the value of each functionality.
Let’s face it, changing the color of that login button makes little sense if the login functionality itself is not working.
In order to make this process easier on themselves in terms of organization and sanity, most product owners follow the MOSCOW method.
MOSCOW is an acronym that describes the bracketing system of organisation of features:
M stands for MUST HAVE – These are the crucial project features. Without these the product should not be delivered.
S stands for SHOULD HAVE – These features will not delay the delivery, however they are important for the overall vision of the product
C stands for COULD HAVE – These features would enrich the product, but they should be completed when time allows.
W stands for WOULD HAVE – These features would enrich the product, but they aren’t game breaking and can thus wait a future release.
Following these 4 letters ensures your project moves in the right direction, at a steady pace.
4. Enthusiastic groomer
To complete the circle, a successful Product owner must groom often and groom well. Product backlog is a living artefact, made of hundreds of story titles waiting for their stories to be written. Writing all these stories and keeping them up to date is close to an impossible task, but if we use our project knowledge, differentiate the need vs wish and apply the MOSCOW method, then our task becomes much more manageable.
The goal is to have the highest priority features as detailed as possible. Write their story well and make sure your acceptance criteria are on point. Every minute a PO spends on grooming the backlog if a minute saved on planning, and consequentially on development and testing.
Backlog grooming might be our last but is most certainly not the least point of this article. On the contrary, I feel backlog grooming might be one of the most important things a Product Owner should focus on. It is hands down the best reward vs investment gain for the project, the team and the company.
Heading out into the world
Imagine this: You have finally decided to start using Scrum at your company. You’ve got everything figured out, a team is committed to wholeheartedly accept this new approach and everything seems clearer now that you’ve got your successful Product Owner on board.
Venture into the world of Scrum using the tips above. Apply these to your projects and measure the results. I am sure you will be amazed by the results and if so, I’ve made my work worthwhile and I am happy there’s another successful Product owner out there, leading her/his team into new ventures using the best of Scrum.
This article was originally published at International Scrum Assembly, home of affordable Scrum training and certification. Reposted with permission.