Story of a Product Owner who was not available to the Scrum Team

In my previous blogpost about the Product Owner Role, I shared the three things that are important for a Product Owner’s Role:

  1. Authority – to make decisions about the product
  2. Availability- within reason so the PO can maximize the ROI of the product
  3. Domain Knowledge– understands the business and what the customer wants

This blogpost is about a Product Owner who was not available to the team. The Product Owner had the right intentions but was spending more time with stakeholders and customers, than the Scrum Team. The Product Owner not being available to the team affected the Development Team’s performance.

How did it affect the Team?

  • Team was confused about the priorities of the product they were developing. Since the Product Owner was not available during product backlog refinement, the team had disagreements over priorities. It affected critical decision-making about the product development.
  • The quality of the product suffered because there was not enough information about what was being built. The product backlog had priorities like High, Medium but was not rank ordered.
  • Product backlog items were created by the Product Owner but he was not there to answer any clarifying questions that the team had. The team was working in a vacuum and making their own judgment over what to build.
  • Sprint Planning became ineffective because the team was spending more time refining the product backlog.
  • During the Sprint Review meeting, the stakeholders and customers were frustrated because they felt this is not what they wanted to build. This resulted in a blame game and lack of mutual trust.

How did they rectify this problem?

  • I suggested that the Scrum Team take a deeper look at these issues and facilitated a Sprint Retrospective. They reflected on areas of improvement and created a plan for improvements in the next Sprint.
  • The Product Owner understood the gravity of the situation and was willing to spend more time with the Scrum Team. Essentially, he was splitting his time spending half of the time with the stakeholders and customers, and the rest of the time with the Team.
  • The Scrum Team made a conscious decision not to cancel any product backlog refinement activities going forward.
  • In the next few Sprints, they worked to ensure the product backlog was ready with clear priorities and enough detail. The Product Owner clarified the questions from the Development Team early on during product backlog refinement.
  • The Product Owner worked closely with the stakeholders on getting the appropriate information. He was well prepared to present this information to the Development Team.

In summary, the solution was as simple as the Product Owner being available to the team. It took a few Sprints for the team to gain each other’s trust. The Sprint Retrospective provided them the opportunity to inspect themselves and identify areas of improvements. The Scrum Team was able to discuss these benefits during the Sprint Retrospective and motivate themselves for further success. It was a happy ending to a simple problem or should I say a happy continuation of their Scrum journey? Or both?

Leave a Reply

Your email address will not be published. Required fields are marked *