Oct. 10, 2011

Tips and Tricks for the beginning Product Owner

Only one Face to a team! It is simple as that. There should be only one Person talking to the development team about priority and things to do and ...

Only one Face to a team!

It is simple as that. There should be only one Person talking to the development team about priority and things to do and that is the Product Owner.

In literature, you will likely find the happy scenario, where the Product Owner and team are working together without the hassles of real life. The Product Owner runs the Sprint Planning meeting and asks the team to commit to certain stories. After the Sprint, the Team will present what they have achieved at the Sprint Review.

So far, so good. But what if you have more than just one Product Owner and more than one team? What happens if one of them is away on holiday or needed on another task? Is it really so important to have one dedicated product owner per team?

The short answer is: YES, it is. No matter how many Product Owners are involved in your organisation and how you elicit the requirements, prioritise them and get your User Stories together. In the end, you want one Product Owner caring for one team. If you have an experienced Product Owner, he might be able to handle more than one team, but from the perspective of the team, there must be only one Product Owner!

The best Product Owners are working in close collaboration with the team. They let the team know in advance what is coming up before the Sprint Planning and also know beforehand what the team will present at the Sprint Review meeting. Don‘t turn your meetings into surprise parties.

During the Sprint, Product Owner and team will discuss the requirements and turn the emergent information into User Stories. Remember that a User Story is only a reference for a conversation that took place. So it does need the conversation and is NOT a specification that holds all the information. When one of the previously discussed User Stories will come up in the next Sprint, it is clear to the team and the PO, but to nobody else. If you change the PO, the User Stories will fail as with the PO, a part of the essential knowledge is missing.

There is another thing that might be even more important: The trust entailed by a lasting face-to-face relationship. The team does not only learn to self-organize and how to build the best software possible over time, it also builds up trust and learns to trust. The team wants to show its achievements to the same face it committed to in the first place. If the team does not know who that person will be, how are they supposed to trust that their achievement will be fairly judged?

The three most important qualities that a product owner needs: 

  • Authority (to make decisions)
  • Availibility (for the team and stakeholders)
  • Knowledge (about the product and environment)

So don‘t change the team, but that‘s another story ;-) and don‘t change the Product Owner within the Scrum Team. Let there be one Product Owner who is responsible for the priorisation of any User Story or Requirement that the team works on. A Product Owner may be able to care for multiple teams, but a team only wants one!

Image of fivancsich

Franz Ivancsich

blog comments powered by Disqus
Image of fivancsich

Franz Ivancsich

Latest Posts

Why are organizations not seeing the benefits of doing Agile?

Due to a difference in goals and approaches, friction occurs between Agile teams and the rest of the organization - who has yet to see the benefits...

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Agility requires cultural change

Article published in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Agile in Everywhere: Sales

An experiment as a ScrumMaster and Agile coach working with a Sales team, where Agile practices are supporting new acquisition and retention targets

Image of ebru4984

Ebru Yalçınkaya

I act as a change agent where the teams, domains need to enhance agility to reach their goals, to create a shared vision if needed. I coach every kind of team , every domain, like management teams or like customer care, technology and sales groups.

Good VIBE at Scrumtisch Berlin

Scrumtisch March 2018 at SAP Berlin

Image of simsab

Simon Sablowski

Simon has spent several years working as a software developer, ScrumMaster and CTO. He is dedicated to shortening feedback loops to accelerate learning and strengthening team collaboration to maximise synergies. At agile42, Simon enjoys coaching and training teams and organisations that desire to attain higher productivity, continuous innovation and extraordinary performance.

Step up your Kanban game

In the upcoming weeks, Accredited Kanban Trainers from agile42 will facilitate certified Kanban training in locations all around the world

Image of mikefreislich

Mike Freislich

Image of rhilll

Russell Hill

Image of mgaewsj

Gaetano Mazzanti

My background includes a long experience as a manager in the Software and Machinery Industry. I worked in USA and India leading distributed teams in advanced software projects (CAD/CAM, PLM, Industrial Automation, Plant Control and Supervision). As a coach I am now trying to help organizations to change embracing Agile and Lean values and principles. I am a WIP limit addict :) and a KCP