An Introduction to the new PSPBM Skills training course and the importance of Product Backlog Management skills

In this episode of the Scrum.org Community podcast, PSTs Ryan Ripley and Todd Miller join host Dave West to introduce the new Professional Scrum Product Management Skills training course. They talk about the importance of having good Product Backlog Management skills in order to succeed as well as the importance of transparency, stakeholder engagement and more!

Transcript

Dave West  0:20  
Hello, and welcome to the Scrum.org community podcast. I'm your host Dave West CEO here@Scrum.org In a damp and wet, New England. today's podcast is a really it's gonna be a great one because we've got the opportunity to talk to two very interesting professional scrum trainers and active Agile community members, Todd Miller and Ryan Ripley. You may know Todd and Ryan from their very famous podcast agile for humans, a very popular podcast far more popular than this one. So, so maybe we'll also learn a little bit about running a podcast today. Hope so welcome to our podcast, Todd and Ryan.

Todd Miller  1:03  
Thanks, Dave. Thanks for having us. Good to be here.

Dave West  1:07  
It's great to have you both here. So before we get into the meat of the the topic today, I'd love to hear a little bit and our listeners would love to hear a little bit about who you are. And where are you speaking to us from

Todd Miller  1:22  
refreshment? I'm gonna see what you say so that I know what format Yeah, yeah.

Ryan Ripley  1:27  
I'll fumble through then you'll sound great. So yeah, my name is Ryan Ripley. I am in Valparaiso, Indiana. And it is gloomy here as well. Dave, it is. For those of you that don't know it's in Northwest Indiana. So we're technically like a suburb of Chicago, but in a different state. What do I do? I spend my time running kids around. And so I coach Pop Warner 10 iu football. I run my daughter to gymnastics i My oldest son plays middle school football. I am basically just running from sport to sport to sport in between trying to teach a few professional scrum courses with Todd here in there as well.

Dave West  2:11  
Great, thanks. Yes, we are Uber of our children, aren't we? Yes, that's for sure. But we don't get any tips. And and yes,

Ryan Ripley  2:20  
just a lot of just a lot of angst and smart mouths. That's my tip.

Dave West  2:28  
So Todd, where are you talking to us from?

Todd Miller  2:31  
I am speaking from York, Pennsylvania. Right now it's actually mostly cloudy, a little bit of sun peeking through in the background, which is nice. We had the rain yesterday, which is good we needed to hear. I also am a member of children. Although in six months, my daughter will have a driver's license and she just bought her first car. So she bought her car, we're gonna get it fixed up and then I will be half of an Uber then just for my son. So other than that, the professional scrum trainer now for almost eight years, they've

Dave West  3:01  
all I know, it's a long time both of you have been in this community a long time, which is which is great. So okay, let's get into the content. Today we want to talk about a new class that was recently launched called professional Scrum Product Backlog management skills class. This is a class aimed at really equipping learners with the skills necessary to better manage their product backlog. And lots of challenges there. I I know that I personally have seen a lot of organizations wrestle with creating product backlogs, often they just looked like team work backlog. So I'd really interesting to hear you too, have been heavily involved in the development working with our team@scrum.org in the community of scrum.org professional trainers. So I'd love to hear your take on why we needed this class. What's the motivation behind it? I don't know. Ryan, if you want to kick that off?

Ryan Ripley  4:07  
Sure. Yeah, it's uh, over the last few years, we've just seen a shift where we'd see teach a lot of the product owner courses and that does a great job of providing a foundation to product managers and Scrum Masters and business analysts on what professional scrum actually is, and how it can be used as an advantage from a product management product ownership perspective. Right. But then we were getting a lot of people coming back 612 18 months later saying I'm not sure what I'm doing. There is some confusion in you know, is this a good product backlog? Am I doing this right? What the heck is product backlog refinement? Why is my sprint review not getting what I know all sorts of questions started popping up from past students. You mentioned the podcast as well, where we used to take a question a day there's like 500 videos out there and a lot of the questions We're starting to converge into the skill of product backlog management, a lot of questions about how many items should be on a product backlog? How do I know that my PBI is are in good shape? How do I know that my product backlog is bringing transparency to the product for my scrum team and stakeholders. And so Todd actually really started collecting a lot of these items, he started building on a mural. And over time, we just started looking at Wow, there's a there's a gap here, there's a and I shouldn't even say gap, I should say, opportunity to help these product owners and product managers and business analysts level up how they manage a product backlog. And so we started teaching and working through some material. Then we of course, we worked with you, Dave, and your team. And we said, hey, we see an opportunity here, we've got some material here that we've just started to work through. And of course, you know, the scrum.org staff jumped in and said, Yeah, this is an interesting opportunity. It fit well on the skills based portfolio that you all have established through facilitation. And now product backlog management, it's just a good fit. We've always worked well together. And we saw the opportunity. And I think everyone kind of jumped in and executed on it.

Dave West  6:11  
Yeah, and obviously the broader community got heavily involved as well providing as they like to feedback. And, and really helped us refine a pretty awesome experience for learners. We hope, Todd, so you were heavily involved in sort of marshalling this group have of seemingly random questions that all sort of coalesced towards a helped me with my product, product backlog. Tell me a little bit about that. And that journey?

Todd Miller  6:41  
Yeah, I think, from my perspective, I think back to the times where I was a product owner, and I've made a ton of mistakes, and how you manage the product backlog. And you start to hear themes, and consulting and in training of all those people making all those things, mistakes, right. And to be honest with you, most of the mistakes I made was by over managing it. And so trying to take something and take a one day or or just to sit with people in a classroom setting and show them the things that I wish I would have had like almost like a letter to my future self. But if it was, if I could take something back in time to first version Todd of product owner, I wish I knew just some of these simple things that I kept my product backlog simple. And I think that's the hope of what people get out of this class is that we tend to overcomplicate it, we tend to over manage it. And one of my favorite quotes of all time, if you've been around me at all, you'll know that I love your venture of Shannara from Patagonia to simplify yields original result. And that's what this is all about. Right? That's really what it's all about. Oftentimes, by simplicity, you can create transparency, and that helps you manage your product backlog and make it more transparent.

Dave West  7:51  
I love the and I don't know who said this, you don't have you too may have said this, that a good product backlog is about it is like a really good garden, you know, it is managed it is looks great different people can get everything they know out of it. Some areas are a little less managed than others. But it's clear that they are not as managed. It's also, you know, provides a great experience it, it isn't a mess, everybody knows it's not a mess, and people like going there to you know, for whatever for whatever reason. It's I'm not sure it's a great analogy, but it definitely makes me think that of what a good product backlog is. I've seen product backlogs that are massively overly managed, under so everything's perfect. And then nobody wants to do anything with them, because I didn't break anything. And then I've seen them that are so messy, that really that they really should be condemned. And and you know, and then all degrees between that so great. I see the motivation, I see the potential impact. So I guess our listeners would be interested to hear a little bit about what's in the class. So one of you wants to take us through this, this this experience.

Todd Miller  9:10  
Iran, should we maybe start with the for, for air areas of the class, the four sections, we start there? Yeah,

Ryan Ripley  9:17  
I think that can make sense. You know, we start off with really understanding your stakeholder, right? We want to we want to get rooted very early, that great product ownership really starts at collaboration with a a stakeholder with an end user with a customer, you know, we're really trying to right off the bat, get rid of this myth that the product owner just knows and you don't have to talk to anybody. And you've got to talk to people to understand what you need to build. And so we established that very quickly up front. You know, we try to route people and the purpose of the product backlog is expressing the needs of other people. We're trying to deliver value into other people's lives. We're trying to solve a other people's problems, right? So there's a Connect, there should be a connection between the product goals that we're trying to solve or deliver on, which you know, our product backlog emerges from and there should be a great connection there to stakeholder. And so we really we work through that. In the first section of the course, we offer some tools that product owners can use to better understand their stakeholders, and to also be intentional about how they communicate to the stakeholders. So we want to make sure that you know, our students walk away from this first section understanding look, you need to spend some time figuring out what people really need. And you can only do that by talking with the people whose problems you're solving. But also understand there's internal and external and users and customers and buyers, and all sorts of other stakeholders that you're working with, that need to be managed and communicated with and dealt with in different ways. And so be intentional about that, that communication plan about that, that stakeholder management, and really just giving them the tools and ideas and awareness to do that. I think that's a good way to express the that first section. What do you think, Todd?

Todd Miller  11:12  
Yeah. And you know, to one of our good buddies, Simon Rando, I read always stands out to me how he speaks if the product owner as an opinion aggregator, right, they're a decision maker. And they make the ultimate decision, but their opinion aggregators from these internal stakeholders and customers, right, and to be able to understand what you do, and what you don't do is ultimately in the product owners hands, and to really center on the fact too, that everything on the product backlog is a hypothesis of value. So all these conversations could actually be blinding as well. Just because people say they need it doesn't mean they actually need it. So that's another interesting thing that we tend to talk about and that section, understanding your stakeholders. I really like Simon's thought on opinion aggregator that stuck with me for many years. So shout out to Simon Reynolds.

Dave West  12:01  
Oh, so what section section to them. So section

Todd Miller  12:04  
two, right up, maybe brief that one, section two is all about how you define your product backlog. So we've just gone over understanding your stakeholders, your customers, all these things. And when we talk about defining your product backlog, one of the first things we start on is scrum guide. 2020 started out with this concept and this commitment called a product goal, a longer term objective for a scrum team. Right. And then we go into some nitty gritty details on how you could potentially define your product goal. And then things like levels of decomposition in your product backlog product backlog Item Attributes common formats for things like user stories, job stories, hypothesis driven development. And all along the way. We are walking through a case study where class attendees are using components of this case study and some of these techniques that we've offered about defining your product backlog. And they're building one, right, they're building one and then the instructor is giving you real time feedback on why it was good, or why maybe a notch on something that you could potentially have done a little bit better. With the idea. Some of these simple techniques that we can use can be brought back into your environment and use in your product backlogs. Right. And so this is really kind of where the pavement hits the road in the class where we're students are creating a product backlog of instructors working with them, giving them tooling and giving them nudges and viewing it and giving feedback as a class realistically on how the product backlogs are structured. Would you add, right?

Ryan Ripley  13:29  
I just love the simplicity of the tools, right? The the whole course is built around the idea that a product owner should be able to take what they learned in the one day course with us and with the with any other PST, that they they take the course from and the next day, apply these tools, like they should not have to go off and do another six months of research. Before they can understand how to apply these things. The next day, they should do, they should start doing the things that are discussed in these sections. And you know, Todd's done a great job of selecting a lot of really good defining your product backlog type ideas, you know, a one, we'll give one away here we talk about the user story format, for example, as a certain type of user, I want something awesome, so that I get value like that old school. Everybody knows that format. It's like come on, we've been there done that. We give options. We talked about different formats. We talked about different ways to express value, even simpler ways, right, that product owners can instantly use. And I think that part's really neat. And it flows. You know, not only are they learning these things, but they're applying them to a real product backlog. Todd and I give a lot of feedback. We spend a lot of time saying Well that's really an activity that's not a PBI let's work on how we express value, not just activity and and so they get a deep dive. I think part of what's cool about this course Dave is that, you know, as Todd was talking about, we work with them but we show Then what is potentially a good PBI and what isn't. And that's not really talked about a lot in the community, right? How many how many posts are on any site that says, here's a really good PBI. And there's not a lot of those, right. And so they get just a instant in real time feedback, a lot of directing a lot of coaching a lot of there's even some mentoring in there too. It's, it's just some really good instant feedback on the work they're doing. And you can see them leveling up as we go. And it's kind of neat to see as they continue to work through this product backlog. You know, the next section is product backlog refinement. So we make product backlog refinement, this, this big idea that, hey, you have to curate, it's like the garden analogy that you gave Dave, if you don't weed the garden, if you don't limit what's in the in the planter box, if you make if you don't make sure that the plants that they're not compatible, your garden is a mess. And so now this idea of product backlog, refinement is that look, you need to slice down your work, you need to slice down your product backlog, you need to make sure that the things that you're putting in the product backlog are the essential things. Now we're we're teaching almost this section is fun, because it's almost we're teaching them to be lazy. We want Scrum teams to do the minimal but sufficient to meet a need to meet a product goal and nothing else. Because that minimal that's sufficient that, you know, it goes back to the manifesto. You know, years and years ago, over 20 years ago that simplicity, the art of maximizing the amount of work not done is essential that to me as a product owner mantra, right, let's do the minimal to hit this. But the only way to know what minimal is is to do refinement, we need to think about our work, we need to slice down our work, we need to come up with the cheapest, easiest, quickest, quickest experiment that tells us whether or not something's valuable. And so that third section that we've put in is really all about how do we go from idea to any customer's hand as soon as responsibly possible, with the minimal but sufficient product backlog items and ideas. And that's where I think a lot of students, that's where a lot of light bulbs go off. Todd has picked some really great tools here. I think his his use of the Kaino model and the way that it's described and taught in this professional scrum course is unique. And I think it really gives the product owners an instant tool to go and be successful in the ordering of their work and the expression of value. And I think they're, they're just gonna be able to, you know, be a better aggregator of opinions, right? Because they have you know, this, you you're the you do a lot of product stuff, you and you have a community of PSPs who are not short on opinions, and you've got to aggregate all of our and we all think we're right. And it's I mean, it's this is a hard aspect of product ownership. You know this, I see you nodding at the podcast, people don't see you nodding and smiling. But it's, I mean, this is a huge part of it, these tools can really help them distill down to what's essential.

Dave West  18:04  
Well, the and that is a key skill that I barely got some days, I felt like I've got it and then the next day all goes horribly wrong. But you express these these ideas, these concepts, these backlog management items, these PBIS product backlog items, and you need to express them in a way that people can readily provide feedback that ensures that they're transparent that people can understand what they're not on what they are, whilst managing the fact that everybody reads them differently. And so refinement is a key activity I found personally, of improving that definition, that structure that whatever the information that we provide, to really help you get to that the heart of that, that that moment is excellent. All right. So we've got stakeholders, product backlog, the structure, we've now done refinement, what's the last section? What's section four?

Todd Miller  19:06  
So the last section is on how you create transparency. And we start off there by in my opinion, and I've been saying this for years, and I think people are actually starting to listen, right. And notice this is one of my big tangents. The most underserved event in scrum to me is the sprint review. So you see all these unbelievable formats for Sprint retrospectives, where you're in Hogwarts and doing all this crazy things and retrospectives, but your sprint review was a 10 deck or 1010 Slide PowerPoint presentation. That was a single direction communication to your stakeholders and did not enable a collaborative conversation. It's just the demo. And so to me, it could your retrospective is often not unless you appropriately are doing inspection, adaptation and transplant creating transparent See in a sprint review. So we start right out of the gate to create transparency, you need to properly leverage a sprint review. But that's not the only way you need to create transparency in your product backlog. That's a start. We really want people to even build agendas for the next sprint review there. And then you have to start to think about how you're communicating with others outside of that sprint review. Like there's going to be other opportunities as a product owner. So this is a section where we kind of lean in as as a product owner, how are you going to communicate with internal stakeholders, customers, and the scrum team outside of those scrum events, because it does require that it does require a lot of communication. And we talk about things like roadmaps and how you could leverage roadmaps to create transparency, there's a million different ideas on how you create a roadmap, we lean in just to some simple example ones. And then really, about creating transparency, the big thing that we really kind of rub in the entire class is that everything is a hypothesis. Just because it's on the product backlog is no guarantee that it's going to become valuable. And this was something that I really had to learn like the hard way, as a product owner, you get married to an idea, you're really excited about it, you spent a lot of time on it, a lot of money on it, and you put it out there, and it's something that no one uses. And you're flabbergasted. It's an insult you feel bad about it, you don't understand what to do next are picking things up. And you're just like, everything's a hypothesis, I need to find smaller ways to test my hypothesis, and then you test them in production, because the only way to know something's valuable is when it's on a customer's hands. So we're really emphasize that and those sorts of things in this creating transparency section.

Dave West  21:39  
It is interesting that you mentioned that there. I had a eureka moment. When we were working through this and talking about this, that eureka moment is ultimately, even if it's a little feature that we're adding that you're like, Oh, why do we why? Why do we need, let's just say exactly how it works, rather than spend any time on why anytime on outcomes anytime on value, because we know that people want this, of course, you know, and the amount of realizations that we came to when we did that when we actually step back, forced ourselves and actually looked at these, you know, features outside the context of a very strongly held belief that this is the must, this is how we must do it, etc. And the amount of times when, you know, somebody has said, Well, you know, we could do it like this, it'd be a lot easier. What do we know that will work? Well, we don't what's the cheapest easiest we can do? Well, this? Well, let's try it. Okay? And suddenly something that was so instone has become a little bit less in a way that actually has allowed us to deliver value quicker and actually solve the customer's problems faster. And I think that I'm still not always good at that. Sometimes, because I like my opinions. They're mine. And nobody's gonna tell me that I'm wrong. And I have press forward. But I really like that. And it's interesting how you weave it into transparency, and you weave it into the sprint review. I think that's pretty, pretty awesome. Yeah,

Todd Miller  23:18  
it's just one of those hard things. I just remember the gut wrenching feeling I had, after I had a team invest a lot of time and I invested a lot of money for a feature. And everybody said that they wanted it. Everybody said that the the stakeholders, were Validating my opinion on it. And so we're customers, and we shipped it, and nobody used it. And that was just like, I'll never forget that moment as a product owner and trying to think of how I could make that smaller how we can make that faster how we could test that hypothesis, hypothesis sooner, so that I didn't have that gut wrenching feeling. And that's still gonna happen. I mean, this is complex, it's still gonna happen. But we like to make sure that the way you're setting expectations in your in your environment, is that nothing is a guarantee. Right?

Dave West  24:05  
It's interesting. I just reminded me of Gillette, there's a case study that I did a similar thing to this podcast on with their head of r&d, Dave Ingram. And he was talking about the fact that one of the best things about the sprint review they had a PBI that was basically about price and go to market, etc. And they just add this PBI in a in a different way at a sprint review. From doing some work. It shone a light on this PBI and the senior stakeholder, I think it was even the CEO of Gillette said no, no, I just said that in passing really not, no, we're not doing it like you know, you don't have to do it like that. And suddenly, the entire that changed their trajectory with the exfoliating razor which Many of you may may use the latest razor from from Gillette. And it really just happened in a sprint review where they chat, where they use the sprint review to shine a light on our PBI. That was in stone, they thought that really wasn't. And, and it changed everything. And then they got one of their most effective, most amazing, but I used it this morning raises out to market faster, cheaper, better for the customer, I mean everything, just this one little thing that which was which is really, really interesting. Cool. So stakeholders, structure of the backlog, product backlog refinement, how you can minimally sort of create this minimal product backlog that delivers the value that you seek, and then transparency. Anything else about this this class in terms of its structure, and that our listeners would love to knit know?

Todd Miller  26:00  
It's experiential, right? So we want we want the tools to be applied. And in a case study, so we give a case study in a class, we want the tools to be applied to it, we want students to have a little bit of muscle memory, I guess, brain muscle memory, so that they can take the tools and go back and apply them immediately went to to have done it. So it feels a little bit more comfortable when you're applying it in your real world. Would you have anything else to add? Right?

Ryan Ripley  26:26  
No, I just I think that's the the key thing to zero went on, you spend a lot of time building a real product backlog, you get a lot of feedback from the professional scrum trainer leading your course. It's a lot of hands on. But you also get every tool that we introduce, I believe you get time with constructive feedback to experiment with and use. So again, it really, you know, after that day of with your trainer that next day, you can start applying these. And that's by design, right. So it's experiential, but it's also practical. Now, the skills based course should lead to a new skill, or at least the development of a new skill. And so we've been really intentional in that space at every tool, you can start using the next day and hopefully start seeing improvement, not only in the product backlog the artifact itself. But I think even more importantly, the collaboration that you have as a product owner, between yourself and the stakeholders, yourself and the customers and yourself in the scrum team. I think applying these tools and ideas well, will lead to a much better relationship between the product owner and the developers, and the product owner and the stakeholders. And so that's why we think Scrum Masters could benefit why we think product owners could benefit why business analysts could benefit. It just It raises the bar of collaboration, it brings transparency to our intentions. And that's got to lead to good things. Right.

Dave West  27:51  
Right. Yeah, I think a good product backlog ultimately, is incredibly important for the whole team, and the value that teams going to deliver. And the stakeholders that are interacting with that team. And ultimately, the customers of the other product or services being being developed. I mean, a good product backlog. It's funny, it's just when it when it's there when it's good, every everything is better, when it's bad. Everything is worse. And that is that is a real, real challenge. So I guess for our listeners, you know, you heard it, Ryan kind of summarized it there. If you're working with product backlogs every day, if some days you fail, your product backlog could be a little bit better. This is this is the class for you. This is a skills based class experiential get to play with product backlogs using the tools that are that are described and taught. And so at the end of the day, you'll get to know what a good product backlog looks like what a good product backlog item looks like. So gentlemen, you know, we like to keep these short. We could talk for hours about bad backlogs, good product backlogs. But what should we leave our listeners with as we as we finish this podcast today? I would

Ryan Ripley  29:23  
say a critical aspect of professional Scrum and what sets apart scrum from professional scrum in my opinion is collaboration. Right? professionals work together professionals work together well. Professionals collaborate and one of the key things that Scrum teams collaborate around is the product backlog. Right? The product backlog is a connection to customer. It's how developers know how they're serving a customer. Well. It's a connection to our internal stakeholders. It's A connection to value, it's a, it's a connection to solving a problem. And so if our product backlog is in excellent shape, if we, if it's well built, if it's transparent, if it's well understood, that collaboration is enhanced, and that's got to be a competitive advantage. And so as professionals, we seek those advantages, we work hard to earn those advantages. And I think leveling up our understanding and our skills around the product backlog is a very clear, clean and easy way to raise the bar for that, that whole team. And I think that's an important thing, especially in that context of professional Scrum.

Dave West  30:41  
Couldn't have said it better myself, Todd, anything to add that fantastic description,

Todd Miller  30:48  
just to Yes, and you know, the product backlog holds the future of the work that the scrum team is going to work on it is, it's where the future state of your product that you hypothetically think is going to bring value right now. It's where that exists in Scrum, right, and other methodologies and other places and might exist somewhere else, but it is on the product backlog. And in order for a person that like a product owner, to be that opinion aggregator, and to leave no stone unturned needs to be transparent. And through all the collaboration that Ryan was talking about before, you run a lot of risks, that people aren't in the know, with what's happening, and that your product backlog isn't properly adapted because of that. And so you might be missing something out in your organization that is, could be of great value to your customer. Because of the way your product backlog is structured, whether it's really messy, and needs to be simplified, or rather, it's really barren. And I think as you said, David should be like quarantine. So that's it's really important, all right, this is the this is the catalyst of the future or your product and the product backlog and it needs to be treated as such.

Dave West  32:05  
You heard it there, ladies and gentleman. It is the catalyst it is a very important artifact and crucial to effectively delivering value to your customers and making the right choices. It's all about choices. We know that we've got to make choices about delivering on that product goal. And if you do not have an effective product backlog, if you've not managed it effectively, those choices will be hazy and harder and harder to make a good product backlog helps you make those choices more effective. That's been my experience having written many bad product backlogs and continuing to do that on a regular basis. In spite of all y'all telling me how bad they are. Thank you, gentlemen. Thank you, Todd Ryan, for spending the time of us today, talking a little bit about a class that's recently launched professional Scrum Product Backlog management skills class, and little bit about the motivation, the why. And then really a good description, a deep dive into the four sections around stakeholders around structure around refinement, and obviously, transparency. Interesting idea around transparency and the importance of the sprint review I an event that is very poorly understood in most organizations. So it's great that we can use this as an opportunity with the backlog, the product backlog to improve that very important event as well, which is which is great. So thank you, gents.

Ryan Ripley  33:43  
Thanks for having us. It's fun, always good to talk to you.

Dave West  33:46  
It is always a pleasure. I always learn a little bit more of a add to my list of Todd's things that Todd gets angry about. I have this growing list every time I talk to him, which is which is always which is always good. It's still only on one page at the moment. So always good. So Thanks for Thanks for coming. And for our listeners. Thank you so much for attending today. Hopefully this has been informative. Hopefully it's helped you make the right choice around whether this class is right for you. My name is Dave West CEO here@scrum.org talking to you on this scrum.org community podcast. Thank you for your time and Scrum on