In the final blog of this series on “Anti-patterns that Doom a Product Owner to Fail,” I cover the topic of planning. While it’s a common misconception that there’s no planning in Agile, it just isn’t true. Product Owners are responsible for making those plans and executing them. But here are a few things they often get wrong.
Not planning at higher levels
Problem
If you’re going somewhere you’ve never been before, I bet you wouldn’t go without a map. The same concept applies to planning in Agile. You need multiple levels of planning in Agile. It’s not enough to have a giant backlog full of “stuff” and iteration or sprint plans. You need to help your team and organization to see the big picture.
Solution
Take a step back and look at your product from a holistic perspective. Draw out a high-level Product Roadmap focused on the product’s features or capabilities. Sequence them in order of priority, based on value and risk. Outline the rough timeline you are aiming for, and remember this is a flexible plan that can (and should) change. Having a rough map directs where you’re going, but without all the details. [NOTE: You may also have a Release Plan, if necessary (although I prefer to deliver continuously, to realize the value as quickly as possible).]
Not ready with “ready” stories at Sprint Planning
Problem
Half-baked User Stories is another one of my biggest pet peeves. There’s almost nothing I hate more than going into Sprint Planning without having any stories in a ready state and suitable for development. As a consultant, I often find that this means that the organization wasn’t adequately trained in Agile and didn’t know that they’re missing an important agreement: a “Definition of Ready.”
Solution
If your team doesn’t already have a “Definition of Ready,” then it’s time to create one. You can do it collaboratively together. It should serve as the checklist for the team to know when a story has all the necessary information to pull into a Sprint. Your definition should be visible to everyone on the team so they can refer to it when doing Backlog Refinement. I also suggest using a swim lane or tag in your requirements management tool to indicate that the criteria for “ready” have been met.
Not sharing the Product Roadmap with the right stakeholders
Problem
If you do have a Product Roadmap, but you’ve never shared it with anyone – especially the right stakeholders – then what good is it? Not much at all, in my opinion. Without input from the people who care about your product, you may miss something significant or even disappoint someone. You don’t want this to happen.
Solution
It’s essential to make your roadmap visible to every relevant stakeholder, including your Scrum Team. Along with the Product Vision, this map helps guide the team in the right direction and gives them context as to why they are doing the work.
Not adjusting plans when new information is available
Problem
As we all know, the world is constantly changing around us. Product Owners who bury their heads in the sand and only focus on their product from an internal perspective may miss out on new opportunities for competitive advantage or be blind-sided when they realize their product isn’t keeping up with the competition.
Solution
Product Owners should be keenly aware of what’s going on with their product, such as industry disruptions, knowing what your market share is, knowing what the competition’s doing, etc. The only way to do this is to stay involved. Do market research. Try out your competitors’ products to see how they compare. Read industry publications. Go to conferences or seminars. These are all critical aspects of being a Product Owner – don’t neglect them.
Final Thoughts
There is planning in Agile – a lot of it. But the Product Owner is responsible for the higher-level plans and making them visible to all relevant stakeholders. It’s also vital that stories are “ready” before development; otherwise, you will have issues. Finally, don’t be rigid about your plans; they should be flexible so you can pivot when you need to.
That concludes this blog series! I hope that you enjoyed learning about the myriad of ways a Product Owner can negatively impact a Scrum Team, along with solutions to solving these problems. Now, it’s your turn. Is there anything I missed? What other issues or patterns have you noticed in Product Owners? Let me know in the comments below!