Product Owners - Just say 'NO'!

If you're a product owner do you have trouble saying no or not now to requests that come in?

Do you just say yes to everything and tag it onto the bottom of your backlog or do you even have a separate list to put those special items on? If so look I understand but this is going to cause a huge problem for everyone so let's talk about it.

As a product owner one of your prime responsibilities is to manage the backlog now that doesn't just mean ordering it using some prioritisation technique, it also means ensuring that the backlog remains relevant, coherent and that it actually has a purpose.

When you say yes to everything it's going to make it impossible to manage effectively. Look I get it, saying no or not now is really hard, it's going to mean difficult conversations with stakeholders who are often more senior to you, possibly even your boss.

Generally speaking we all like to please people, we often shy away from situations that could lead to conflict and we might think that saying no could give us a bad reputation or be detrimental to annual reviews but actually it's quite the reverse that's true.

Being thought of as a yes man or lady is just going to lead to an ever increasing list of progressively low value work compared to your current list but this is only the beginning of the issues that saying yes to everything is going to cause.

For starters your backlog is going to increase from 50 items to 500 items in no time at all. Prioritising 50 items is itself no small task but try doing it with 500 items. You'll find that the team are spending more time prioritising than actually delivering value.

Also when you say yes to something you're making some sort of commitment some form of intent to the stakeholder that you're actually going to do something. But all these lower value items are always so far down the list that you'll never get the chance to work on them. What kind of impression do you think the stakeholders are going to have of you when the team never deliver?

You should be running regular update sessions with your stakeholders and having to continually report back that you haven't started their work is just going to result in a poor relationship with no trust and those stakeholders will eventually stop attending your networking sessions and will also stop requesting new work from you and seek out someone else instead.

Your reputation and that of the team will suffer, believe me I've seen it so many times. Now I'm not suggesting that you just say no, you have to provide a reason why, so you need a justification, and that justification needs to come from your prioritisation technique.

Whatever technique you're using it needs to provide information, data that the stakeholder can understand. Things like cost savings, revenue, business impact, market opportunity, risk, time criticality or the actual size of the work itself.

There are many prioritisation techniques out there, weighted shortest job first (WSJF) that uses cost of delay (CoD) is one of my favourites.

Check this link out for more information on WSJF https://scaledagileframework.com/wsjf/#:~:text=Weighted%20Shortest%20Job%20First%20(WSJF,by%20the%20relative%20job%20duration.

With WSJF, for each new request you calculate a score, I like to use a broken Fibonacci sequence as it adds a further waiting to the score. You assess business impact, risk, opportunity and time criticality and add them together, that is your cost of delay, and then you divide that number by the score you give to the size or complexity of the work.

We use size as a weighting because we want smaller pieces of work so that we can deliver value more quickly, this gives you your overall prioritisation score - and this has to be compared against everything else on the backlog.

You're not alone in this, get the team involved particularly those with business analyst skills, they can help elicit and analyse the data. You'll need help from the devs too as they'll be needed to help you understand the complexity and size of the work.

Don't make these decisions on your own, bring the experts in, namely the team.

You also need to clearly communicate to stakeholders what criteria you use to prioritise so that they understand the process and what supporting information and data they will need to provide to you.

They also need to understand what time period your backlog needs to reflect 6 or 12 months for example, as well as your team's capacity and this should be the determining factor on how big your backlog can be.

Once you've reached capacity on your backlog then a new item can only come in if it's relative prioritisation score beats that of what is already on the backlog. And in that case the bottom item on your backlog is going to have to drop off which is going to lead to another difficult conversation with a stakeholder.

Another problem caused by innocently saying yes to everything is that whatever tool you'll be using to manage your work, Jira for example, is going to get in a real mess. It's going to be hard to find items when juggling hundreds of tickets which causes a lack of faith in whatever tool you're using as well as making it very difficult for the team.

It's hard enough to get teams to use an agile tool without making it harder by swamping the system with garbage.

This scenario very often leads to using something outside of your agile tool to report the status to your stakeholders and leadership. Something like Excel or PowerPoint, you know what I'm talking about!

This is double the work because you’re maintaining two sources. This should be telling you that your backlog is out of control.

If you can't create a simple dashboard from your agile tool that shows the status of your backlog then you have a problem. With tools like Jira you can use eazyBI or one of the many Atlassian Marketplace dashboard plugins. For Azure DevOps you can use Power BI.

Don’t forget about all of the lost productivity hours because the team is wasting time prioritising low value items that will ultimately never get done anyway just because we didn't want to say no.

So product owners take back control of your backlog and Scrum Masters if this is a situation you find yourself in what the heck are you doing? Get involved, speak to your PO and help that is what you're there to do.