1

The primary duties of a product owner is to collect requirements from the client, manage the product backlog, writing and prioritizing the user stories and performing user acceptance testing. Considering this duties, the PO spend more time in requirement analysis and research about the new features. I feels difficult to measure the productivity of a PO in a daily basis. For example, the QA's daily work is counted as test cases and developer's work is counted as partially completed codes. But the work of PO is not counted on a daily basis. I mean that outcome is not available always.

So my questions are

  1. How to measure the productivity of a product owner in the scrum development framework?
  2. How to be more productive in product owner role?
  • Are you asking as someone who is a PO? Are you new to the PO role, & if so what were you doing before? – Vicki Laidler May 31 at 0:08
  • Yes i am new to the PO role. Actually i was working as a business analysis in waterfall methodology. I am trying to understand the transition from a BA to product owner. – Jithin Antony May 31 at 5:03
6

Measuring Individual Performance is an Agile Anti-Pattern

Your metrics are inherently not-Scrum. With agile frameworks in general, and Scrum in particular, you measure the success of the team as a whole. You don't measure individual performance, because that actively prevents the level of collaboration and whole-team orientation that agile frameworks require. Don't do that!

What to Measure Instead

Instead of trying to measure individual performance, you want to measure team performance against self-defined Sprint Goals. In other words, when the Scrum Team defines a Sprint Goal each Sprint (which is required by the framework), can the Scrum Team as whole meet that goal more often than not? Perfection isn't the objective, but a team that can't meet reasonable goals it sets for itself around 80% of the time has a process problem that merits close inspection.

The Scrum Team should be measuring its own efficiencies routinely, and especially during the Sprint Retrospectives. In general, teams should be measuring and improving their process. That requires a certain amount of team and individual maturity, which is why Scrum is not a silver bullet for mediocre hires or poor team-formation choices.

If you find yourself in a situation where the organization needs to measure individual performance because the Scrum Team is not performing, and the organization is looking to affix blame:

  1. The Scrum Master must step up individual and team training.
  2. The Product Owner must include training and process-optimization work on the Product Backlog.
  3. The Scrum Team must fully embrace agile practices that optimize flow and collaboration over individual success.
  4. The senior management of the organization must take responsibility for their choices in hiring, budgeting, fiat schedule-setting, organizational processes, and other management choices that impact team and project performance.

Senior management is always responsible for project outcomes. If they have failed to hire self-actualizing teams or failed to provide sufficient training and empowerment to properly adopt agile frameworks, then they have no one to blame but themselves for an underperforming agile implementation or a poorly-performing project. They can't wish this responsibility away, hand-wave it, or micromanage it out of existence. If they break the project, they get to keep both halves.

Responsibility Checklists

Okay, with all that out of the way, the Product Owner still has some core responsibilities that are either done or not-done. The Scrum Guide provides a partial list that includes:

  1. Clearly expressing Product Backlog items;
  2. Ordering the items in the Product Backlog to best achieve goals and missions;
  3. Optimizing the value of the work the Development Team performs;
  4. Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  5. Ensuring the Development Team understands items in the Product Backlog to the level needed.

These aren't the sort of metrics that are useful for measuring individual performance in the usual command-and-control way, but they are certainly key dimensions on which a Product Owner's individual performance can be assessed within the structure of the Scrum Team.

Does the Scrum Team feel like Product Backlog Items are clear, and can be readily used for communication or Sprint Planning purposes? Do the stakeholders feel like the Product Backlog provides a roadmap that will deliver the value they're seeking? Does the organization feel like the Scrum Team is optimizing value through the potentially-shippable increments it's delivering? Does the Development Team feel like the Product Owner communicates effectively and remains accessible throughout the Sprint?

These are, for the most part, qualitative metrics rather than quantitative ones. Nevertheless, other than functioning as an integral part of the Scrum Team, these are the sorts of things that can set a mediocre Product Owner apart from an exceptional one.

In the end, though, the assessment of a Product Owner comes down to how well that person fulfills the role and supports the Scrum Team. The whole Scrum Team succeeds or fails as a unit. The Product Owner can't succeed while the Development Team fails, nor can the Development Team succeed without a successful Product Owner. They must support one another. They each have unique roles within the Scrum framework, but the Scrum Team can only be properly measured as a single, unified team.

  • This is really helpful. Thank you so much for this valuable information – Jithin Antony May 30 at 19:18
  • Using the sprint goal as a metric invites gaming. It is more of an internally focused metric that helps the team to focus their delivery. – Barnaby Golden May 31 at 9:00
  • @BarnabyGolden Any metric can be gamed. In the end, the question is always a subjective one: "As a stakeholder, am I satisfied with the outcome of the current Sprint?" You can't please all the people all the time, but if you ever find a more meaningful metric than that one you'll change the industry. – Todd A. Jacobs May 31 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.