I have a new found respect for Product Owners after playing the role for ScrumWorks over the last several sprints. It’s a very difficult role that seems underemphasized in Scrum/Agile literature.
Here are a couple of pointers that I’ve learned:
- Prior to planning meetings, always meet with the team (or at least the ScrumMaster) and have them (re)explain the technical backlog items on the backlog.
- Spend some time pre-prioritizing the backlog before the actual planning meeting. Doing things in small batches is more efficient, and it reduces the frustration of having to do it all at once in front of an audience during sprint planning. You can combine this with (1) above, just have representatives from the team on hand.
- Before prioritizing on your own though, ask the team to re-estimate items on the backlog. Scrum says each team should spend a percentage of their time re-estimating the backlog, but in my experience this is one of those things that slips between the cracks. Insist that your team does this before you even start prioritizing for a planning meeitng.
- Focus on the end state, and insist on actionable goals. Your job is solely to set the criteria for an acceptable “end state” by helping to define clearly actionable goals. Avoid vague goals like “Work on XYZ feature”. Instead ask the team to list binary goals like, “Feature XYZ is ready for production deployment”.
- Don’t worry about task detail. It’s tempting to get down into the details to understand why the team is doing the things they are. If you’ve defined the end states clearly this will not be necessary and it’s more effective to let experts handle the details en route to your end state.
- For a fantastic book on managing by end states, see Corps Business : The 30 Management Principles of the U.S. Marines. Buy and read this book.