This is the transcription of the interview done by Adolfo Foronda a few weeks ago about how a Product Owner can effectively prioritise a product backlog. I hope you enjoy and find it useful.
ADOLFO: I’m your host Adolfo Foronda at nerd stalker on Twitter.
Today I am with a very special guest Erich Bühler. He is a senior Agile consultant, he regularly pairs with Certified Scrum Trainers (CSP’s) and he’s an expert in agile business Agility and organizational transformations.
He’s also the author of the first book in .NET in Spanish back in 2002. Speaker in many international events and he recently run a Web in Enterprise Social Systems (ESS) for Scrum Alliance, organized the first ScrumDay in Chile and Valencia, and Erich has served as a trusted adviser over the past 22 years for the following leading companies… there’s a ton of them here… LATAM Airlines, Chile, Microsoft Iberica, Ministry of Defense Spain, British Telecom UK, London Stock Exchange, INDRA Spain, MasterCard Uruguay, AXA insurance Mediterranean Spain, and many more companies in Malta and New Zealand….
Erich welcome to the show.
Erich: Thank you.
ADOLFO: Erich what are the things you need to consider in order to prioritize the backlog and its connection to the releases and how do you explain why it is so to stakeholders?
Erich: In order to produce a backlog you need to have a unique definition of business value all around the company and a roadmap. So in Agile, most Roadmaps are based on goals; we don’t use specific features for them in general…
A good roadmap helps you translate strategic decisions into actionable plans and align the customer expectation with the outcomes.
So in order to have a roadmap, which is the first step, you need to have a shared vision and a valid strategy.
Basically, your Roadmap has to inform people how your product is going to grow and the different releases… so we want to connect these goals with the releases.
But the important thing here is that you have a coherent story between those releases. This is a very very important part!.
Don’t even think of doing anything else until you come up with a coherent story between your releases.
You’re going to use this story to align stakeholders and ensure that everyone is on the same page. You also need to define plus/minus what you are going to have in each release (apart from the story) and then analyze the cost and the impact you are trying to achieve.
You also need to have the right relationship between roadmap and product Backlog. When you got a great Roadmap then you can think of prioritising your backlog.
Remember that your Roadmap is your strategy or strategic plan and describes how the product is likely to grow through the several releases
The backlog instead is the tactical tool. So it’s more detailed, in there you can find the epics, user stories etcetera.
My recommendation is that you keep both separated but connected at the same time with a very good story that explains why we are doing it, so people can understand it.
Once you understand all these things, you are ready to prioritise your backlog.
Some companies generally do refinements… and I generally recommend doing three or four refinements sessions a week.
ADOLFO: You’ve touched on some of those what are the techniques and tools. Let’s get down to it… what should be used or you recommend using. Earlier you said you threw out e-mail…
Erich: ha ha ha… I know it sounds a little bit crazy, right? But it worked very well
In my experience, what I’ve seen in some companies is that’s the ways or the techniques they use are very old fashioned or very complicated to prioritise their backlogs.
The first thing we need to check is something very simple… we want a visible backlog.
I generally ask people to write some index cards and place them on the wall… especially with new teams and Product Owners. And then I teach them around 10 different techniques to prioritise a backlog. We can use business value, we can use sense of urgency, cost of delay, Skeletton, … we have approximately 10 or 12 techniques. We can probably be talking about these for hours…
The Important thing here is that everyone on the team and outside the team understands the techniques and why decisions are made. I generally recommend running a refinement session three times a week, as I mentioned before, each one 45 minutes long with the whole team.
I know some companies have tried to do it including just one part of the team. Refinements are all about creating alignment and everyone should understand why we are doing something.
The outcome for this refinement session has to be some shared understanding of the coming user stories, all of them with clear acceptant criteria.
As I said, you also need to make sure that everyone understands the techniques. There is nothing wrong for team members to understand Cost of Delay and why they are using it.
We don’t really want to produce documents but shared understanding as shared documents are not shared understanding. This is a common issue I have seen in companies.
We need to have a clear and visible backlog with great accepting criteria; then you have some techniques… we can talk about cost of delay or business value during the prioritisation session.
And then we need to make sure that everyone understands how the techniques work and have a very clear definition of done (DOD) for the items in the backlog.
ADOLFO: it sounds like you’re proposing paper like you’re talking about and I hear you are not talking about Jira or Trello or you know… the whole thing
Erich: Well… especially with new Product Owners, we want to make sure that everyone can see what is happening.
I also understand that some companies have some teams that are remote. Teams that are probably split between different geographic locations/different places. As much as you can… try to make sure that everyone can see what’s happening. In fact, one of the companies I helped with, was split in two different locations and we placed cameras all around the company and they had a map/blueprint where you were able to click on the different rooms and see who was in there.
And then we “kind of broke” this barrier between who was remotely and who was in the office. And this is a very important thing especially with new people. We need to reinforce these kinds of behaviours where everyone can see what is happenning and we have high visibility.
ADOLFO: It sounds like you’ve touched on then how do you help stakeholders to come to the common understanding of the priorities and what is a good way to link the priorities to business of the company, I mean, that’s a huge point right there… linking the priority to the business of the company. But it sounds like these three times a week meeting really help to establish a shared understanding?
Erich: Yes, especially if the company is coming from the traditional world.
We need to make sure we increase visibility. The important thing here is also about understanding estimation and business value.
I’ve seen that many companies that have different definitions of business value even when they are producing the same piece of software.
What I generally do is to try to organize a meeting or workshop… sometimes is one or two sessions with everyone there.
During the first session, we just write the goals that will be transformed into a Roadmap. And then what we do is to start creating the user stories or epics. We finish the session with a common understanding of business value and goals.
During the second session, what we do is to try to review what we’ve reached before and we start focusing on creating the releases… what’s going to be inclued in each release approximately, etc.
So that probably implies dozens of trade offs. Everyone has to be there… stakeholders, Dev Team and also the Product Owner.
This is all about creating a shared understanding of the priorities.
My expectations after this kind of sessions is for everyone to be aligned and understand what the first priority is.
ADOLFO: All right thank you Erich.
Erich: Thank you!
And remember… if you want to know more about the ways to boost Scrum and Agile teams within your company, please visit our website.