Product Backlog Refinement: Who's Involved? (And Why!)

Who should be involved in backlog refinement? Imagine you're building a Dynamics 365 or a Power Platform application, and using an agile approach like Scrum, where the requirements emerge in an artifact called the product backlog, who should be involved in the backlog refinement activity? 

Does the product owner have to be there? What about the scrum master? And do all the developers really need to be there? Let's find out. 

Hi, I'm Neil Benson, your host for Amazing Applications 106. You can find show notes and the transcript for this episode at AmazingApps.Show/106. 

How's it going? It's the start of the summer holidays here in Australia. My kids finished school today and tomorrow we're off up the coast to Noosa with a couple of other families for some sea and sand and hopefully some sun too, but we're having a wet start to the summer. 

Before I go, I wanted to share my thoughts with you on the topic of backlog refinement.

I've been involved in lots of requirements elaboration recently and getting the right people in the backlog refinement workshops isn't always straightforward. 

First let's define what we mean by backlog refinement. In agile product development, a product backlog is an ordered list of all the work that we need to do to turn our business aspirations into business applications.

The product backlog items are ordered by the product owner based on characteristics such as a business value estimated effort and the technical risk. The items at the top of the backlog should be smaller, better understood, [00:02:00] and more accurately estimated than items at the bottom of the product backlog. Backlog refinement is the process of making the items smaller, ensuring they're understood and estimating them.

You don't need to refine the items at the very top of the backlog because they should already be refined and ready for your scrum team to start development on in the next sprint or a couple of sprints. And you don't need to refine the items at the bottom of your product backlog, because it could be months before those items rise to the top. We want to defer our requirements analysis for as long as possible. This means that our backlog refinement activity should focus on items near the top of the backlog, but not at the very top. These are the items that our product owner thinks are likely to be needed and our developers think they're likely to get to within the next couple of sprints. 

These items might not be well understood by the developers and maybe not even by the product owner. These items might also feel quite big, probably bigger than we would want to try delivering in a single sprint, but they haven't been estimated yet. 

Wait. What? Is it possible that the product owner doesn't understand some of the product backlog items? Well, let's start with the product owner's backlog refinement responsibility. 

In my Dynamics 365 and Power Platform projects, the product owner has always been a senior leader from my customer's organization. They represent all my customer's users and the application's stakeholders. It's their mission to maximize the application's value for the organization. 

The product owner's prime responsibility is to order the items in the backlog. No one else should be messing with the order of the items in that backlog. The product owner has the final say that's a rule from the Scrum Guide and has been a rule on all my projects too. We haven't always succeeded in having a single product owner on all my projects, like the Scrum Guide says, but that's a topic for another podcast.

In most of my projects, the product owner also has [00:04:00] sufficient business expertise to be able to help the developers understand the details of the requirements. Maybe they're a senior leader from the department we're implementing Dynamics 365 for in marketing, sales, service, operations, finance, or HR. Or maybe they are a senior manager from the team we're building a Power App or Power BI application for in health and safety, supply chain, public relations or wherever else.

If they've got recent, hands-on, operational experience, then they've probably got enough knowledge of what users and stakeholders need so that they can express those requirements to the developers. But this is not always the case. On my projects, often the product owner is not an expert in all the business processes. They can't know all the requirements and don't know all the features of the legacy application we're replacing. 

And in enterprise projects, spanning multiple departments or teams, they can't possibly know everything. No one does. It's not like we have the wrong person as our product owner. It's just that there isn't one person who knows that much about the organization to that level of detail.

Your product owner probably does have sufficient knowledge when you're building an application within a small company or with a small team that's inside a large organization, but on enterprise projects, your product owner is going to need some help. 

In my projects, the help has come from two places.

The first source of help for the product owner is a role that we call subject matter experts. Now, these are not in the Scrum Guide, but all my projects have had them. Subject matter experts are those people in the organization with deep knowledge about a business process, about a legacy application or the existing data or some other topic that our scrum team needs to learn about, but our product owner doesn't know in sufficient detail. 

In my enterprise projects where we've built apps for hundreds or thousands of users, we'll have somewhere between 10 and 50, maybe more, subject [00:06:00] matter experts. They could be spending a significant amount of time contributing to our project. It could be 10 or 20 hours a week, maybe even full-time. Others, well, we just need to validate the details with, for an hour or two, and we're done. 

On my current project, we've got Matt from operations who is nearly full-time on the project and a significant subject matter expert. We've got Jessica, Susan and Belle from various policy, safety and regulatory teams who provide their expertise for several hours a week.

These significant SMEs are involved in most of our project, and they get invited to our product backlog refinement workshops and our sprint reviews. 

And we've got experts like Allan from risk and compliance, who we met with this week to validate our auditing requirements. He was happy with the requirements that the other subject matter experts had expressed. And we were done within an hour. 

We've got dozens of other SMEs, like Allan, who our project sometimes engages with. We meet with them briefly, perhaps invite them to one or two backlog refinement workshops, and we move on. They don't have a meaningful role where it's worth inviting them to sprint reviews, but there's no reason why we couldn't, if we wanted their feedback or their input.

Let's take a quick break and we'll be right back to find out who the other source of backlog refinement assistance is for the product owner.

 G'day business apps builders. I wanted to share with you an important insight and share something I made just for you. After spending thousands of hours coaching teams from all over the globe, I've learned one big lesson: everyone who wants to use an agile approach to build business applications has a different definition of what Agile is. 

If you're a business apps maker getting started in your agile journey, then it's worth understanding what Agile really means. 

Where did agile approaches come from? 

What are the [00:08:00] benefits for Microsoft partners and customers? 

And how can you get started and certified and the most popular agile framework of them all? 

So I put together a short, action-packed foundations course that reveals why traditional approaches to software development don't work for low code, no code business applications.

 You'll learn about the agile manifesto and the history of agile practices, the benefits of an agile approach for your applications. And you'll learn about the Scrum framework and how you achieve your Scrum certification. 

All in less time that it takes you to spin up a new Dynamics 365 trial environment.

It's been said that only a fool learns from their own mistakes, but a wise person learns from the mistakes of others. This is your opportunity to benefit from all the mistakes I've made, figuring out what doesn't work in order to identify what does. 

If you're ready to get beyond listening and to start being, consider this training your bat signal. 

To gain instant access for free, visit https://customery.com/foundations. 

 The other source of help for the product owner is the developers. 

In my scrum teams, we will have one or two developers who have a background in business analysis and who understand Power Platform or the Dynamics 365 application.

Their role is to help the product owner uncover their requirements, elaborate them, split them, merge them, expand them and whatever else it takes. Our business analysts have previous experience working in agile projects and building business applications where our product owners sometimes do not. 

In fact, most times do not. On business applications, projects, it's rare, I think, to work with a product owner who knows Scrum and has worked in a Dynamics 365 or Power Platform project before. This is most often their first time. [00:10:00] 

This means it's also their first time working with a backlog management tool like Azure DevOps. Our business analyst and other developers in the scrum team help the product owner wrestle with Azure DevOps.

Hey, look, I'm stuck on my third project using Jira. So don't laugh about the niggles you have to deal with in Azure DevOps. Hey, you ain't seen nothing. You've got it so good. 

The rest of the developers from the scrum team are also active participants in backlog refinement. We don't mandate participation from the developers, but we strongly encourage it.

Being too busy, developing new functionality is not an acceptable reason for skipping a backlog refinement workshop. We need you there because we value everyone's perspectives and their questions. 

Different developers get into different aspects of the requirements and come at things from different angles. It could be that there's a developer who's built a similar feature before, or listened to a podcast episode recently about someone who has. Or can anticipate a deployment challenge or a difficulty testing what we're about to build. We value all those perspectives in our refinement workshops, even though we're not designing the feature in detail in this workshop. We are trying to come up with a candidate design that we can estimate. If you're the only person in our team who has just heard about the new Settings solution components in Power Apps, and that would help with this requirement, we want you in the room. 

So far, we've got the product owner, a few subject matter experts, and all of the developers. 

The other person we want in our backlog refinement workshops is the scrum master. The scrum master isn't essential to backlog refinement. If I'm this scrum master and I can't make it, I insist that the backlog refinement goes on regardless.

The same is not true if the product owner can't attend. The scrum master can, however, add a lot of value during backlog refinement by facilitating the discussion. Scrum masters ought to [00:12:00] be marvellous meeting facilitators. 

Before the meeting, they can make sure the right people are invited, everyone understands the purpose of backlog refinement, and that the team is appropriately prepared. 

During the meeting, the scrum master is coaching the product owner and helping her consider the volume of the backlog items and reminding her and the developers to focus on the product goal, to stick to their definition of ready if they have one, and to estimate using the team’s agreed method.

 They are also ensuring that everybody is actively participating and is being respected. And a scrum master should have an objectivity that is watching out for the team: spotting questionable requirements or estimates that seem out of balance compared to other recent similar requirements.

There you have it. Backlog refinement is the work to ensure that the backlog items are mutually understood that they are ready for their development to start in an imminent sprint. 

Backlog refinement workshops, whenever and wherever you hold them, need to be attended by your product owner and the developers. The right subject matter experts should be invited too. And I always find that the best backlog refinement happens when it's facilitated by a good scrum master. 

I hope that helps. Let me know if you run backlog refinement in a similar way, or maybe completely differently. Some of my teams call it elaboration or have other creative names for it. What does yours look like? Get in touch and let me know. 

Thanks for listening to another episode of Amazing Applications. I always appreciate you letting me shout in your ears every week or two. I hope you're enjoying it and learn a little from the content I'm sharing in every episode. 

Sometimes, I guess that might mean you're reflecting on how you build business apps and disagreeing with everything I say, but as long as you're inspecting and adapting, that's fine by me, whatever the outcome. 

Like Lars Martin on LinkedIn, who doesn't assign stories to developers, the way I shared on episode 104. His teams find value in decomposing stories into tasks. Whereas [00:14:00] my teams don't do that anymore. Scrum is a broad framework and there's a myriad of ways to apply it successfully. 

You can add your comments about backlog refinement, wherever you see this episode posted on LinkedIn or Twitter. The Amazing Apps show has dedicated pages on both of those. 

 Thanks so much for listening to the Amazing Apps podcast, you can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly. And a notification when there's a new episode available. There are also shortcuts so you can follow the show on all major podcast players and you can follow amazing apps show on Twitter, LinkedIn, YouTube, Instagram, and Facebook.

You can send me a message or a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt visit https://AmazingApps.show. Thanks again for listening. I really appreciate. you Until next time, take care. and Keep sprinting.