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:
- The Scrum Master must step up individual and team training.
- The Product Owner must include training and process-optimization work on the Product Backlog.
- The Scrum Team must fully embrace agile practices that optimize flow and collaboration over individual success.
- 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.
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:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- 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.