The most important thing a Product Owner needs to do is say NO. If they don’t it results in a huge backlog with lots of items, and usually pressure to deliver more than is realistically achievable.
Many people fail to realise that Scrum is not about building the same stuff faster. The Chaos report tells us that 60% of features are never or rarely used. The point of Scrum is to identify this 60% early and to not build them in the first place. If you do this, you have doubled your productivity by doing nothing except saying no.
I drew the following PO decision tree to help new PO’s understand how often they need to say no.
If you are still not convinced that you need to say no, here is a simple exercise based on queuing theory:
Cycle time (the amount of time customers wait for a requested item) is related to the length of the queue. Think about grocery shopping or the bank. The longer the queue, the longer you have to wait right?
What happens for you when you wait in a long queue? Do you enjoy it? I usually start tweeting about how poor the service is 😉
At this point I’m hoping you agree – a short queue is a good idea.
Now consider your current queue. Either your backlog, or your ticketing system, or your bug tracker – whatever holds the list of all the work your team needs to do.
- What is the current size of that queue (open or in progress items)?
- What is the input rate. i.e. how many new items are created each month?
- What is the output rate i.e. how many items are closed each month?
- What will your queue look like in 6 months time
Let’s take an example.
Imagine your ticket system currently has 1000 items open. 100 tickets are opened per month and 50 are closed each month.
In six months time your queue will be 1000 + (100 – 50)*6 = 1300
That means customers will be waiting even longer. On average they will wait 26 months for their ticket to be solved! (queue size / output rate) Chances are they won’t be a customer anymore after that amount of time.
What if you only wanted customers to wait max 1 month?
In this example, you would need a max queue size of 50 (monthly output rate).
If you wanted your queue size to be 50 in six months time, what would you need to do? For the sake of this example you can’t just throw more people at it. (And usually that is not an answer).
You would need to say no to some requests.
How many would you have to say no to?
Currently you have 1000 requests. You will get another 600 in the next 6 months, so in total you have 1600 requests.
Your team can do 300 requests in 6 months, and you will allow 50 to be in the queue. So you can accept 350 requests.
You need to say NO to 1250 out of 1600 requests, or 78% !!!
You might think this is unrealistic, but what is unrealistic is believing that you can service 1600 requests. Don’t fool yourself or lie to your clients. Start saying no, so that you can say Yes to the 20% of the work that is essential to your customers and products.
Our online course for Product Owners will teach you how to get the most from your team by managing and grooming your backlog effectively, learning how to prioritise, understanding your stakeholders, release planning with confidence and measuring ROI.
I am glad you start with the most important part, “The most important thing a Product Owner needs to do is say NO”. We need to make sure the Product Owner is empowered to say “NO”. That is such an important part of their job. We don’t want to waste time grooming some item that will never be done. Thanks for sharing!
Wonderful. I’d like to add “is it emotionally bothering you that this is still being discussed, from the backlog?” yes -> reject
Love it, thanks!
Comments are closed.