Tips for Starting Product Ownership Journey

I was recently approached by a friend whose wife is looking to make the leap from Project Management to Product Ownership. He wanted some advice how she can get her ‘foot in the door’ with some local companies. This isn’t the first time I get this inquiry. In fact, Richard Khor and I will be releasing a short video answering the same question for Scrum Masters in a few weeks. Because this is another common question I get, I want to share my recommendations. Feel free to add further recommendations in the comments section:

 

Thank you for reaching out! I have some recommendations to better position her experience and knowledge for when these PO positions arise. First, she has to keep in mind that Project Management doesn’t translate 1:1 with Product Ownership. Project Management is more focused on process, governance, resourcing, etc. Product Ownership is very focused on creating the right product for the right customer. She should definitely read:

These are highly recommended. If she knows these well, it will give her some recognition on her resume and interview:
Aside from reading, getting involved with local Meetups helps build her network. She’ll hear about specific openings before they hit the market, and she’ll get to meet other practitioners in the community. Community involvement is a big factor when hiring Product Owners, Scrum Masters, and Agile Coaches. Here is a link to the local Agile Leadership Network (ALN). There is a sub group run by our very own Andrew Blue- The Product Owner Focus Group.
If she wants to get certified, she could go the route of getting her Certified Scrum Product Owner (CSPO) through Scrum Alliance. Its pricey, so I wouldn’t do this right away. Instead, she can look at Scrum.org and their Profession Scrum Product Owner certification materials. Honestly, Scrum.org has a more comprehensive test she can use to measure her progression. IC-Agile is another organization that I’ve seen lots of folks checking out for certifications and learning material. Here’s their Product Ownership page.
~Charles~

The Backlog Refinement Sweetspot

Foreword

I published this almost two years in a separate blog. I just started with a new company, and I have been working with several folks who are not too familiar with Scrum and some of the finer details around the events. I’m republishing this article with a few edits here and there. I hope it helps some teams that might be struggling with their Refinement sessions.

Setting the Stage

If there’s one ceremony that is very susceptible to ‘going off the rails’, it is backlog refinement. The very nature of the meeting invites the temptation to dive into more detail than necessary. This is expected; as a former software engineer, my inquisitive nature often gets the best of me. Drawing the line between ‘valuable refinement discussion’ and ‘getting lost in the weeds’ is a common challenge. There are a number of techniques a team can use to refocus including: time boxing, strict facilitation, limiting non-essential participants, etc. A few months ago, my colleague introduced me to a teaching point that we felt would help our teams take control of their Backlog Refinement sessions. Rather than tell the team that they’re going into too much detail, we offered them a technique to help them self-diagnose. My preferred moment to coach this strategy is at the beginning of the refinement session. At the beginning of the session, I like to remind the team the true intent behind backlog refinement: ‘To acquire just enough information on a story to size, so that the Product Owner can clearly review and prioritize it compared to other backlog items’. The emphasis is strongly placed on ‘just enough’. Development Teams may insist that they have to cover all the details in refinement; remind them that the implementation details should be left for Sprint Planning or story kickoff sessions. The Scrum Master should do his/her best Aaron Rogers impression (sans mustache):

After setting the tone for the session, the graph below is introduced. It represents the qualitative journey a team takes when discussing stories:

Graph Walkthrough

Approaching Point A (Brand New Story)

As a team discusses a new story, they know very little about the business value and/or the technical details. The story serves as the spark for the discussion; the team and Product Owner start to dive into the narrative to identify what value the story is attempting to deliver.

Point A (The Aha Moment)

By this point, the Product Owner has described the business value of the story and why he/she is considering this for prioritization. Now, the team is starting to jump into the conversation and the Product Owner is simply facilitating. As an observer, you can almost ‘feel’ the electricity in the room.

Between A and B (Enjoy the Ride)

Welcome to the Backlog Refinement sweet spot! The story that was hard to discern in the fog, has emerged. The solution to the problem isn’t fully outlined, but enough is known where all members have an idea how much effort it will take. Now, the team is expanding the acceptance criteria, considering system dependencies, or maybe covering very high level design. But when does the team know when it is covered ‘just enough’?

Point B and Beyond (Diminishing Returns)

How do we know when our session has turned from productive fact finding to detail driven design? As a non-technical observer, it is difficult to ascertain when the conversations move away from important story refinement. Beyond this point, the team can still acquire valuable information, but it is not as impactful. When I’m observing or facilitating, I don’t want to interrupt a potentially groundbreaking discussion, but I also don’t want to get too far ahead of ourselves. This where I like to tie the illustration to a simple question.

“So, Where are We?”

With teams that traditionally venture beyond the sweet spot, I like to introduce the graph prior to a refinement session and explain why I’d like them to consider it. The emphasis for the session is to land somewhere between A and B- where we have just enough information. I encourage the team to be cognizant of where they are in the discussion.

  • Are we still learning about the story?
  • Are team members coming up with pertinent ideas that are furthering the understanding?
  • Are the acceptance criteria being updated?

OR

  • Has the discussion started to die down?
  • Are we discussing corner case scenarios?
  • Has the conversation started to dive into full blown technical design?

If a team member feels that they’ve ventured into the latter, I’ve proposed one simple tactic: Refer back to the graph and ask, “Where are we on the refinement curve?” This quick question gives the team an opportunity to reflect on where they are in the conversation. If it is still valuable, then they’ll call it out and continue. If they feel they’ve ventured too far, they’re now aware. Anyone can make this check- beware of stepping on any ongoing conversations though. The goal is to improve the team’s self-awareness. They should be able to get a feel when they’ve strayed.

My Experience

I’ve tried this with a variety of teams with reasonable success. It is definitely not a magic bullet if your refinement sessions are sputtering. However, it is a solid non-traditional strategy. I enjoy giving teams these tools to solve their own challenges rather than telling them they’re doing it wrong. There’s much more potential for improvement when a team can self-correct, rather than relying on someone to make the corrections for them.