Some professions and positions are amazingly clear: The dentist fixes teeth, the architect plans houses, the journalist reports what happened. Being a scrum product owner is different – not because it’s more difficult than writing a great story, but because what is takes for a PO to succeed depends on so many different factors: the company culture, the type of project, the management style of the CEO, and last but not least the dynamics of the team that develops the product. Nevertheless, there are some mistakes that can jeopardize about any project, no matter how unique the circumstances. In the following paragraphs, we would like to share five of them that can make your project fail – or thrive, if you make sure to get this right from the beginning.
1 – “We’ll figure this out later” (Lack of product goal and vision)
Sometimes a project starts, but not every detail is clear. That’s okay – the beauty of Scrum is its adaptability to uncertainties. However, as time progresses and core structures are being built, the lack of a clear vision becomes more and more of a problem. It’s not the problem of the team – it’s the problem of the product owner, whose responsibility is to define the product goal and vision in cooperation with the client and communicate it to the team. This can be a tedious process, especially if the client is unclear about his goals or has difficulty articulating them. A good product owner is able to assist the client and take the lead when necessary to come up with a product vision that is comprehensive, thought-through and makes clear to the team where the project is heading.
2 – “Everything is important!” (Lack of product priorities)
If product vision is lacking, prioritizing the product- and sprint-backlog becomes very tricky. If the product vision is clear, but there’s no agreement on which factors determine the business value for the client, prioritization is almost impossible. Priorities should be based on product vision and business value – if either is unknown, the product owner has not worked hard enough to sort this out. The consequence are backlog priorities based on what “feels right” rather than solid arguments, difficulties explaining backlog priorities to the team, as well as difficulties defending the backlog against questionable changes requested by the client. If client and PO agree on what the project is about right at the beginning, a lot of questions and conflicts that may arise later can be settled quickly by reiterating the goal and vision of the product.
3 – “I don’t care how you get there, just do it!” (Lack of clarity on development path)
Another consequence of lacking product goal, vision and/or priorities is that deciding on the best way of how to structure the development of a project becomes unnecessarily difficult. In other words: If the WHY and the WHERE are not clear, the HOW won’t be clear either. Here’s an example: There are three big features to be built – a forum, a chat, and a calendar widget. If they are seen as three separate and independent chunks of work, starting with either of them is okay. In the end, they have the same business value to the client. However, if the product vision is to create an online community that connects people with like-minded individuals around the world, the calendar should come last – because it promotes local connectes rather than global ones. In this case, a clear product vision helps prioritizing in a way that the business values might not be able to.
4 – “Who wrote this story?” (Lack of physical or intellectual presence)
Do you have your own office room? Maybe even on the top floor with a great view, far above the developer cubicles? Nice – but probably not very good for your project. Being physically and intellectually present and avaible to the team is crucial to keep product development on track throughout the sprint. If the PO is separated from the team, the risk increases that questions remain unanswered during the sprint, resulting in stories that the team considers “done”, but the PO doesn’t accept. The more availble the PO is during the sprint, the more precisely the outcome will match his and the client’s expectations. Also, by being confronted with the questions that the team has during a sprint, the PO can improve his specifications for the upcoming sprint and make sure future stories are more clear. For the same reason, the product owner must physically attend the sprint planning meeting and the review meeting – plus the retrospective and daily scrum meetings, if possible. That doesn’t mean he has to talk during all of them – but he should be there to listen, if nothing else. PO attendance at these meetings cannot be delegated to the scrum master or another team member.
5 – “Let me ask the client about this” (Lack of decision-making power)
Clients can be a pain: Some don’t know what they want and expect the PO to invent their product. Others who know what they want control every move and forget why they hired a PO in the first place. Having a product owner who is not given sufficient authority and autonomy by his client or CEO is almost as inefficient has not having a product owner at all: If the PO cannot make decisions when fundamental questions arise during the sprint, it is likely that someone within the team will start filling in and taking on the role of the product owner. The consequence is similar to what happens when a PO is not physically or intellectually present: stories are misunderstood, questions remain unclear, and results won’t match the expectations of client and PO. In another scenario, CEO or client are taking over the role of the PO and start micromanaging the project and its team. The result: The PO’s knowledge and understanding of the product remain underutilized, and his ability to relay the product vision to the team is corrupted. Furthermore, the quality of product management decreases, because neither CEO nor client are able to be as present as a PO should and could be.
Conclusion
Obviously, there’s a lot more that can go wrong. However, starting with the PO when it comes to improving scrum performance is not a bad idea. In fact, I believe that most problems in a scrum project are symptoms of bad management and leadership rather than a lack of skills or discipline within the team. Therefore, doing whatever it takes to prevent or correct these five issues is worth the effort either way.
Note: This essay was inspired by Monica Yap’s presentation “Product Owner Anti Patterns” given at the Scrum Gathering Shanghai on April 19-20, 2010.
