Ask a Product Owner #2 - Product Backlog

Please let me know in the comments what topic should I address in a future session of 'Ask a Product Owner'!

On LinkedIn, all my connections and followers had the opportunity to ask any burning question they might have related to the Product Backlog.

I’ve packaged all the questions anonymously here together with my answers. I also sometimes bundled together variations on the same question (or because my answer to them is related).

Let's start with the questions!

How much work should we refine ahead for future Sprints?

"How much work should we try to keep ready for future sprints in the backlog? This means work that is planned, debated, refined, sized etc and ready to work on."

My personal preference is to refine it just in time, as much as you can get away with. There are many benefits to doing this:

1. Based on the latest understanding and best insights.

2. Fresh in our minds

3. Smallest chance of waste or rework due to 1.

Biggest downside is you may discover obstacles that will prevent you from working on it immediately. The worst that happens is that you spend some time in Sprint Planning refining things for the current Sprint.

Many people view that as a bad thing. I don't, as it actually can be effective and means less meetings. Which everyone likes. I don't see any reason to refine more than 2 or 3 Sprints ahead.

I believe when you have a safe environment, and people are aware estimates will always be off, then refinement becomes more fluid and flexible. Instead of trying to prevent the punishment of having wrong estimates.

If we know what we need to do and why it matters, and we feel confident we can figure it out during the Sprint, then it's clear enough to work on.

Discovering obstacles or problems will always happen. It's better to cultivate flexibility and responsiveness to incorporate changes. Emergence is key for complex work.

Should a Product Owner clean-up the Product Backlog regularly?

"Should a PO spend time regularly ploughing through the product backlog items and delete items that have not been touched/updated or are obsolete?"

?I believe you should first of all prevent getting in that situation by keeping your Product Backlog short and fresh.

The Product Backlog should not be treated as a wish list. You can have rough, big items on there (Epics) that need to be refined. But even then not too many.

The PBL becomes stale over time and keeping it long will mean rework to make everything fresh again. And very often that is unnecessary rework, because when items are never picked up, then you are fooling yourself by refining them.

Refine these items just in time before you will work on them.

Urgent and important things will come back, even if you would remove them from the Product Backlog.

Don't use your Product Backlog as a junk belt for things we will never be doing. A final resting place where you move items to perish, basically a way of giving your stakeholders a soft no.

If I arrive at such a PBL as a new PO, I would delete as much as possible from PBL. I don't need to uphold promises made by others. Unless they are made to customers. I would also engage in a dialogue with stakeholders to explain this before taking any action.

What does a good Product Backlog Item look like?

"I would appreciate to see how a good product backlog item is written and its description. A real life example. :)"

I'm not a big fan of using templates. I only use templates for two kinds of issues:

1. Bug

2. Improvement

Bug: Reproduction Path, Expected Results, Observed Results, if I have a hunch about what's going on maybe I add a possible cause section.

Small improvement: Current situation, Desired Situation

I want to stress, depending on context and the situation, I might even add more information. How I write a Product Backlog Item is highly situational.

For the rest, if I discuss something on the PBL in general I try to answer the following questions:

1. Why are we doing this? Why does it matter?

2. What do we hope to achieve?

3. Is there any relevant context we need to be aware of?

This information ensures that people can ask the right questions because they understand why what we're doing matters, what we expect to achieve together with any context that matters.

If you simply provide what they need to do, then all they can do is follow the original plan or agreement.

For the rest, I PBL items should have a clear and short title. Clarity matters most. I never use User Stories as a title, as they are difficult to grasp/understand in a quick glance.

Sharing concrete examples is difficult, as they don't belong to me.

How much time should a Product Owner on average spend working on the PBL or refinement?

"How much time would you say a PO on average spends working in the PBL - would that be considered as his main task? Does the Agile Coach / Scrum Master have a role in working in/with the backlog?"

Refinement and working on Product Backlog, like adjusting ordering, absolutely not should be your main task. It also depends what you consider working on the PBL.

I think giving an average time is difficult as it highly depends on context, however what I can say is that many Product Owners spend far too much time on the mechanics of delivery.

Figuring out the most valuable thing we could be doing is where most of your time should go. Talking to customers, understanding the market, doing discovery, those kind of things. Also, stakeholder inclusion, making sure the roadmap is understood etc. Those things will make a far bigger difference in value delivery, than talking about how to deliver something.

Then once you know what you wanna do, expressing it in the Product Backlog should take 10-20% of your time, in my experience. Notable exceptions could be highly regulatory contexts, or extremely complicated and risky products where the stakes are high and mistakes are costly.

The problem is many POs spend most of their time polishing the Product Backlog, and that doesn't add a ton of value. If you work on the wrong things, nailing those won't make a big difference. What goes in the Product Backlog (and what doesn't), has a far bigger impact on value delivery.

Your time should mostly be spent figuring out what's going to make a difference for your Product. If you get sucked in refinement and the sprint bubble as a Product Owner and you spend 80% of your time there, then you are doomed to work as a Feature Factory churning out features.

What should be in your Product Backlog?

"What type of items should a product backlog contains ?

Should it be a specified todo ?

A collection of problems ?

A list of resources (user interview, market research...) ?

Something else ?"

Whatever you deem necessary to deliver value. That may sound like a cheap answer, like 'it depends', but I don't believe you should feel restricted. How the Product Backlog is defined is intentionally vague.

As a general guideline, whatever you do, should contain the following:

1. Why are we doing this? Why does it matter?

2. What do we hope to achieve?

3. Is there any relevant context we need to be aware of?

Depending on what you're doing, answers to these questions can be long or short.

I would be more inclined to link resources to a PBL, as opposed to making it part of the Product Backlog, as then you keep a single source of truth for that.

What is the right level of documentation?

"How can we decide the right level of details for the documentation?"

I've never seen documentation done well. When there's too much, people can't find it or it is outdated. Then we actually wasted a lot of time producing documents that are rarely useful. When there's too little, then people complain there should be more. And then we start documenting more, and then people can't find it or it is outdated... and so the cycle continues.

Reading code is harder than writing it. Reading documentation is easier than reading code. However, the code is how it works, the documentation can be misleading as it is a snapshot made in time and an interpretation of how it is supposed to work.

I haven't found the solution. I think you should document high level things like architecture and how things are connected, but if you go down to feature level then those things seem to become obsolete quickly.

Basically, anything which useful for on-boarding, that means whenever someone is on-boarded, it will be revised and checked for accuracy.

How do you deal with regulatory requirements on the Product Backlog?

"This is the scenario " As part of regulatory or audit or governance requirements, scrum team has been asked to give more details in user story. Though team and product owner is comfortable and convinced that current process is enough and they don't have to treat user story as a detailed requirement. But Governance asks for more. Have you faced similar kind of request and how do you handle it."

Build a good relationship with them and try to understand where their worry is coming from. Also ask questions like, what happens if we get audited and this is not there? Will we have time to make it right or immediately get fined? Etc.

The better you understand their world, the better you can influence them. As well, try to bring them to your world.

These conversations are never easy. I've had great outcomes and also disappointing results.

How do you handle dependencies between work items or reliance on experts?

"How do you handle dependency mitigation for your teams while refining your product backlog?

Considering the nature of backlog we have in our teams we slowly moved from controlling (SoS) to supporting(invite guest team member/s) stages and now looking into options in the enabling(cross training) stage. This is also the way forward explained in the Scrum guide, but the reality is way more for organizations newly evolving in Agile. At times we still face challenges be it due limited permissions or architectural complexity of the system.

What steps one can take as a Product Owner to manage this situation?"

At the core, Scrum is about empowered teams who are flexible and respond to changes. What you see very often, is that at best, this flexibility only exists within the team.

When one team needs another team, then suddenly we start talking about 'dependency management'.

Dependency management often becomes necessary for various reasons:

1. Teams are not cross-functional

2. Teams are component teams

3. There is no overall priority across teams, hence teams prioritize their own work

4. Teams plan at 100% capacity, thus cannot help each other.

However, even if you address these 4 issues, then you will still have dependencies.

When the priority is clear, the teams should be able to help each other OR decide that one thing is more important than another thing. They should be empowered to manage these dependencies themselves, without any scaling mechanism. Why can't they walk to each other and ask for help? And then just help each other?

I don't believe having a SoS fixes the underlying problem. Teams should see these issues coming, without a Product Owner who has to manage the situation. That's why we have empowered teams!

Get your teams to collaborate, prevent from having to coordinate their collaboration as a Product Owner, as then they depend on you and you become the bottleneck. It's not desirable nor feasible, as Scrum dictates one Product Owner per Product.

How are Product Backlogs different for new products and established products?

"How are backlogs different for new products (no customers yet) and established products?"

That's a good one! Here are some things I'd expect to be seeing. Did I miss anything? :)

New Product

• Shorter Product Backlog (more uncertainty)
• More discovery work, research and spikes
• More focus
• Shorter time-to-market of features
• Less stringent Definition of Done

Established Product:

• Longer Product Backlog
• More small things you're working on simultaneously (little bugs, small feature requests). Less focus as a result.
• Usually longer time-to-market of features
• More stringent Definition of Done

DoD is actually not a property of PBL, but it does affect what you deliver.

How long should your Product Backlog be?

"How many sprints should the backlog cover at any point in time? As in, there is known stories prioritised for say 2 sprints."

As little as possible as it makes sure you work based on the latest understanding and freshest insights. When you do complex work that matters.

When refinement happens doesn't matter. Refinement usually becomes trench warfare due to lack of psychological safety. You should fix that instead of being forced to refine ahead in time as much as possible.

The knee jerk response to break a whole big project down in smallest chunks and refine everything to forecast a timeline actually means your estimate will still be inaccurate and you will deliver the project later than if you hadn't done that because your plans will be limited by the fog of beforehand and murky because of the fog of speculation.

Long story short: your plans stop being anchored in reality and when you discover that changing them will take a lot more work than having a lightweight plan that anticipates change.

How do you ensure Product Backlog is visible and transparent to different audiences?

"What can /should a PO do to ensure backlog is visible and transparent and should that be tailored for different audiences , e.g senior management vs developers:

The challenge here is that the Product Backlog serves different audiences.

Those who will build the product, care about different things than the stakeholders who care about what we will be building in the product.

Showing a refined Product Backlog to stakeholders, I don't believe that's a sensible approach because:

1. That's too much detail.

2. Not everyone cares about everything you do equally, as you will have different stakeholders interested in different things.

My approach is to share a more high-level view of the Product Backlog, which focuses on the big things you're doing. As most teams use Jira, I often create a Now, Next, Later view on Epic level. It's more like a roadmap of the things we're doing and intend to be doing on a very high level.

This is what usually interests business stakeholders more. What are the high-level things / goals we're working towards and what is our progress?

They are usually not interested in combing through every individual PBL item.

Use different views of the same PBL to cater to different audiences. This ensures transparency. A PBL with everything contains noise and is less transparent. The CEO doesn't want to know all the bugs you're fixing e.g.

How do you wrote Product Backlog Items with enough detail to keep the team on track, but loosely enough so that an empowered team can leverage their skills to solve the problem at hand?

"How do you write backlog items with enough detail to keep the team on track, but loosely enough so that an empowered team can use their skills to provide the right solution to the problem? Should you include all the relevant details in the story itself, link to other sources (confluence, figma, etc.), or something else?"

This depends on maturity of team, but usually I just start with a title and then I talk the team through the following:

1. Why are we doing this? Why does it matter?

2. What do we hope to achieve?

3. Is there any relevant context we need to be aware of?

This information ensures that people can ask the right questions because they understand why what we're doing matters, what we expect to achieve in terms of outcome together with any context that matters.

If you simply provide what they need to do with a fully formed PBI, then all they can do is follow the original plan or agreement.

I actually believe moulding it together results in the best PBI's together with common understanding. What's written down becomes less important, because everyone has it in their mind because we created it together.

If you create the ticket with all the details, then it's no longer a team working product. The team will sit back and assume it look's good, let's do it!

How do you prevent stakeholders operating with a Feature Factory mindset?

"A PO is being constantly bombarded with new feature to be delivered in production but delivered features are not yielding the expected benefits in the market. Scrum team feels that stakeholders wishlist is not inline with what customer needs. How PO can get closer to user needs. Is there any specific method or practice or technique he can try to find out the actual need than imaginary."

That's not a simple question to answer. There are two parts to solve this solution:

1. Influence stakeholders by showing them delivered features are not yielding benefits. This is tricky, as basically it may be interpreted as you're doing a poor job, so you need a delicate approach and good influencing skills to pull it off.

2. Once they are onboard, what should we be doing instead?

Your effort only shows to the extent it makes a difference for the customer. It's important to understand how you're delivering value to them. People often talk about value as if it's a single concept, but customer value is not the same as business value, though customer value can be captured in business value.

If you don't have a model for how you're delivering value to your customer, then how can you better help them to achieve what they are trying to achieve?

I believe the North Star Framework is a good place to start to conceptualize a value model. Once you create a North Star Framework, you can use it to prioritize feature requests and measure impact.

Those were all the questions and it's a wrap!