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 that is the Product Owner. In literature, you will likely find the happy scenario, where the Product Owner and team are ...
Franz Ivancsich
I am a true believer in agile, lean and yoga. Sometimes a prophet, sometimes a pirat.
- On
- 10 October 2011
- In
- Scrum, agile
- Tags
- Owner, Product
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!
Discussion No comments yet. Be first to comment!