I was happy to hear that many of you enjoyed the Product Owner tips I offered in my previous blog post so I thought I’d jot down a couple more today. If you’d like to read my previous Product Owner tips, you can find it here. So let’s get to it.
Ruthlessly Prioritize
I spent several years working in the gaming industry, and it was from a Product Owner there that I learned an odd but effective prioritization technique. At the end of sprint planning, he’d point to the sprint backlog and say, “See that story on top? That’s the only thing I’m concerned that gets done this sprint. Nothing else.” After a day or two, that story would be done, and at the next stand up, he’s point to the sprint backlog and say, “Great work! Now see that top story? That’s the only thing I’m concerned that gets done this sprint. Nothing else.”
Some might argue that this is a terrible way to support a team. After all, they’ll only be motivated to get a single story done, and there’s so many stories to complete and so many things they need to know! I wholeheartedly disagree. Doing so kept the team on task, and it helped us clearly understand our priorities. Too often, I see Product Owners who lack focus, and while they and their teams are very busy, they’re not always productive. Look at it this way:
Progress should be defined by the amount of work we finish, not the amount of work we’ve started.
A laser-focused Product Owner will lead to a laser-focused team. That’s not to say that this team focused on only a single story. Often our top story would reach saturation. A team member would then begin the next, and the Product Owner would answer questions and support team members as they worked on this new story. Still, his focus remained on the top of the sprint backlog.
Customer Empathy Isn’t Enough
Customer empathy is paramount, but it doesn’t end there. I’ll use the tip above to illustrate my point. My audience today was the Product Owner, but I could have just as easily written the tip with the Scrum Master in mind. How?
I would have talked about WIP (Work In Progress) limits. I’d mention how limiting the amount of work in flight ensures a team doesn’t finish a sprint with a lot of half-baked work having little to show at the sprint review. I might have also provided tips as to how to set this limit and how to explain to the team the value in doing so. In our world of Scrum mastery, these things matter because it’s something that resonates with us, and it’s something over which we have influence.
Because Product Owners value setting priorities and techniques for effectively communicating with teams, I approached the conversation from a different perspective. Before we can influence others, we must first understand what they value. But it doesn’t stop there. To understand what they value, we must listen to empathize, and doing so is simple:
End more sentences in a question mark than a period.
This is especially relevant to Product Owners who must be chameleons:
- They are customer proxies and must be intimately familiar with the domain and the problems within it.
- Product Owners must empathize with leadership to ensure their needs and goals are fulfilled in the spirit of a profitable product.
- They must connect with team members to understand their needs and expectations and to appreciate their skill sets and limitations.
I hope these tips were helpful. If you have any of your own, feel free to offer them up in the comments below. Thanks for stopping by.
Oh. One more thing. The folks at Knowledge Train recently published an ebook that talks about challenges the agile community face. If you’d like to hear what I and others had to say on the matter, click the image below.
Do you want to get notified when new posts are published? Leave your email below.
Really liked the Ruthlessly Prioritize tip. I’m doing this to a certain extent with the team I’m coaching, but not quite to this extreme (we have work in flight that supports a few different releases, but I stress that the most important stories are those that support the NEXT release). I like the extreme priority the PO you mentioned showed and can think of a few teams I’ve been on or coached that would have been better served with a PO that had that some mindset.
Thanks, as always, for sharing!
Glad to help, Chris. Best of luck out there!
Very important topic that you’ve articulated very well, the focus and discipline to finish out something in a Sprint is the hardest part of Scrum/Agile.
I think it’s with mentioning the ‘arc’ that runs in parallel with your approach whereby the whole team knows what the bigger picture is and sufficient time is allocated for buffering Design and Technical Spikes before development. There’s a danger of being incremental rather than iterative if we focus only on the current item in development and you could end up with a disjointed Product experience for the user.
I agree that a holistic view of the problem is necessary for the team to succeed to its fullest. Otherwise, we miss out on valuable solutions. I can’t name how many times I’ve seen team members who offer up solutions to a problem in half the time. They couldn’t have done so without understanding the entire picture. I failed to mention as much in this blog post for the sake of brevity. Great observation!
If I may, a few other thoughts about your comment:
* I discourage spikes wherever possible by way of emphasizing working software AND knowledge creation over just knowledge creation. Teams who use spikes too often can fall into a mini-waterfall mindset because they need a sprint to understand something thoroughly before executing.
* I believe we should be incremental *and* iterative simultaneously. Iterative by embracing we won’t get it right the first time, and iterative by means of delivering software frequently (ideally continuously).