How Product Owners Prevent Value Delivery

Why would Product Owners prevent value delivery, you ask? They shouldn’t, and don’t want to, but yet I see them do it every day. And usually, it’s without them even knowing they’re doing it. Here’s four observations of how Product Owners prevent value delivery, and suggestions to improve.
1. The Sprint Backlog is the Development Team’s plan
One of the biggest mistake you could make as a Product Owner is to focus too much on what’s on the Sprint Backlog.
Imagine you’ve hired a chauffeur with years of experience. You tell him you want him to take you from Boston to New York. Are you going to give him detailed directions, monitoring him all the way there? Or are you going to sit back, relax and enjoy the ride, trusting you’ll end up in New York?
As a Product Owner, you are likely way too concerned with what’s on the Sprint Backlog and way too little concerned with the Sprint Goal, which is actually what your primary focus should be on. As a Product Owner you want your team to deliver value. You want to get to New York, it shouldn’t matter much how you get there. Focus on having a clear Sprint Goal for the team so they know where they’re going. How you get there, should be of little concern. Trust your team to do their jobs and if they hit traffic, they’ll find a way around it by making small changes to the Sprint Backlog to ensure they will still get where they’re going.
Let their plan be their plan.
2. Four things are not one Sprint Goal
I guess you could argue that this goes both ways, but Product Owners have quite some authority in giving direction to a Sprint Goal. Even more so, they should set the right example for the Development Team in providing a clear business objective to work on. Having a single Sprint Goal to focus on will improve value delivery and ensure focus for the Development Team.
Imagine you’re trying to drive from New York to Boston, Washington, Pittsburgh and Rochester all at the same time. You’d be getting nowhere. Common sense would take you to one city first, then on to the next one.
However, most Product Owners don’t think this way about Sprint Goals, believing that Development Teams can deliver more value if they are doing multiple things at the same time (at least they’ll look busy…). All you get in that case is half-finished bits of hopeful value. Not a lot of people are going to pay for that.
Short, focused cycles deliver more value than longer, non-focused cycles. Help your team out, make sure there’s a single Sprint Goal to focus on and ensure it’s valuable.
3. Make important work unimportant
I guess everybody knows them. These “high priority”, “can’t wait” issues that pop up during the Sprint have “have” to be finished ASAP. Yet, I see very little Product Owners challenging the actual importance of these issues, whereas in my experience, over 95% of these can wait or don’t have to be fixed at all.
Remain critical towards important issues and rigorously question whether they are actually worth interrupting your team for. Any such interruption could easily cost at least one team member a full day, likely more. Consult with the team at a right time with any such issues. Talk about them, look for smart solutions and workarounds, and at times decides that some things are simply not going to be fixed.
4. Desk hopping will not speed things up
If your Development Team is not making progress at the pace you were hoping, desk hopping is not going to speed things up. Interruptions will slow things down regardless of how well-intentioned they are. Make sure you are available and are ready to help when needed. Don’t try to rush or push things, because even if it works once, the long term results will be devastating.
If you’re worried about your team, talk to them during a Sprint Retrospective or talk to the Scrum Master.