Product Owner Effectiveness Contributes to Agile Effectiveness

May 22, 2013

Scrum is the predominant agile framework in use – with 72% of the respondents in VersionOne’s State of Agile Development Survey for 2012 reporting that they use Scrum, a Scrum/XP hybrid or Scrumban. Since Scrum doesn’t prescribe technical practices, it’s good to see that Scrum/XP hybrids are in use and that the use of various technical practices is continuing to grow.

It is equally comforting to see that those who know most about agile are in the ScrumMaster role, since the ScrumMaster is responsible for guiding the team in agile practices. However, those closest to the work of the team – from a software development perspective – were ranked as most knowledgeable about agile. Those closer to the business such as executives and Product Owners were ranked as least knowledgeable.

This is a concern. A Product Owner should be interacting with the team on a daily basis; and it seems to me that if a Product Owner is in fact engaged with the team that some knowledge about agile practices and behaviors should be rubbing off. At the very least, Product Owners should have an understanding of and be supporting the values and principles of the Agile Manifesto.

Whenever I’ve worked with struggling teams, one of the first areas I look at relates to the Product Owner and the product backlog:
  • Does the Product Owner understand the principles of crafting good user stories (e.g., INVEST in good stories)?
  • Is the Product Owner collaborating with the team about the intent of the user stories and defining the actual solution? This is in support of one of the principles of the Agile Manifesto: “The most efficient and effective method of communicating to and within a development team is face-to-face conversation.”
  • Is the Product Owner attending the daily standup and readily available to the team to answer questions? This is in support of another principle of the Agile Manifesto: “Business people and developers must work together daily throughout the project.”
  • Is there a prioritized, groomed product backlog?
  • Does the Product Owner understand that the daily standups and sprint demos are essential feedback mechanisms (feedback loops)?
I’ve often seen poorly-performing teams struggling with issues such as:
  • Comprehending the backlog (the work is ambiguous or poorly articulated), leading to disengagement.
  • An unavailable Product Owner – the team is either delayed in getting timely answers that impacts velocity, or they are forced to make their own calls that need to be reversed later, creating unnecessary rework.
I’ve worked with disengaged teams that became very engaged once we cleared up the expression of user stories in the Product Backlog, usually done by going back to the usual template:

AS A [type of user] I NEED (OR WANT) TO [perform some task] SO THAT [benefit]

Once the team understands what the user wants to perform and anticipated benefit of performing that task – free of implementation details – the team typically becomes very engaged about crafting a solution. The challenge in an agile context is that teams should be striving to meet the need as simply as possible, as articulated by another one of the principles of the Agile Manifesto: “Simplicity – the art of maximizing the work not done – is essential.”

Even if Product Owners get the need for clear articulation of the work, those used to a more traditional software development approach fail to realize that user stories are not full requirements, but expressions of intent that should be elaborated on just-in-time basis. And even when the user stories are elaborated via a conversation with the team, there will be a need to respond to questions as the team works through the details during a sprint because small adjustments will need to be made.

Sometimes the need for bigger adaptations will arise. Consider the following scenario: A user story is discovered to be much larger than planned as the team works on the story in mid-sprint.

This is an opportunity to make an important call because the cost/benefit ratio has shifted. Perhaps this user story is no longer valuable to do and should be jettisoned in favor of starting work on other user stories, reducing the Cost of Delay of these stories. Another call might be to pull this user story from the current sprint and add a spike to a future sprint to determine if is there is another approach can be taken. (Discussing the situation with the customer should also occur.)

In order for teams to be productive, they need real-time responses to their questions. With just one day of wait time in a two-week sprint that is imposed by a lack of Product Owner availability, the team takes a 10% hit. Short cycles are an intrinsic part of agile delivery, as expressed by two other principles of the Agile Manifesto:
  • “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
  • “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
And agile teams need to be focused on delivering working software, as yet another principle of the Agile Manifesto clearly states: “Working software is the primary measure of progress.”

As you can no doubt gather from the points above, Product Owners should be supporting all 4 values of the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


John said...

Thanks a lot for your information

March 17, 2016 at 12:55 PM

Post a Comment