Lindsay Velecina: 0:02

Music. Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast, we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. This episode is a previous recording of our live ask a professional scrum trainer series where a live audience asks questions of professional scrum trainers. We hope you enjoy this episode.

Patricia Kong: 0:30

Hello, good morning. Good afternoon, good evening. Welcome to Ask a PST, product backlog management. Oh, we have Simon flossman and SAS Pavlov with us today. So we'll be taking your questions about this topic. I'm very interested to see what type of questions everyone has, and also what type of experiences and advice Simon and Sass will be sharing. So my name is Patricia Kong. I'll be your moderated moderator today. Just some quick guidelines, your microphones will be muted throughout the session. Is recorded, the recording and slides, our colleague, Lindsay, will get them up, usually within 24 hours. And so please use the Q amp a icon and submit your questions. I'll be keeping an eye out for them. I forgot to say hello. Hello, Simon. We've been chatting for like 20 minutes already before this. I forgot a little bit. Excuse me. All right. So who is scrum.org? We're founded by Ken scrumor, the CO creator of Scrum, and he is our chairman, and we have a mission@scrum.org that originates from him in helping people and teams solve complex problems. The company itself is focused on training, education, community. SAS and Simon are very intertwined in that, as are all the PSTs and myself and making sure that we can get our ideas and learnings from you and with you outside in the community. So before I hand it off to the PSCs to introduce themselves quickly, I just want to say that this is a really interesting topic, and one of the reasons I'm moderating is because last year, when I was looking at our scrum.org data, there was a lot of people coming to the scrum.org website because they were researching about product backlog and product backlog management, and so I wanted to make sure that we were capturing the type of resources and content that might be needed, facilitating the conversations that we can have. So we're hoping to do more of those where we'll take a look at the data and see what topics are helpful to EU with that. Then Simon, may I ask you to introduce yourself.

Simon Flossmann: 2:51

Hello, everyone. My name is Simon. I started my career actually as a product owner at a big German company where we built home appliances basically later, I joined consulting mostly as a scrum master, but my main focus was to help product owner improve. And over the years, I think I have seen a lot of product backlogs from small ones with just a couple of goals to really large ones, so maybe more on the specification site, and in the last year, I tried to pass on my knowledge and all my mistakes I made over the years so that you don't have to make them again. I think it's much more fun to learn from mistakes without doing them. That's all from me.

Patricia Kong: 3:38

And where are you? Based? Simon, Germany. Okay, could you

Stas Pavlov: 3:46

introduce yourself, please? I can. So my name is stas Pavlov. I'm a PST based in the Netherlands, in The Hague area. I call myself a product leadership consultant. That's not, that's a made up job, by the way. It's something that helps me to summarize what I do. What I do is talk about product management and agility a lot, and mostly by either advising people or by trading people. I enjoy both. I'm firmly rooted in my experience in the product product management world, done a lot of products ownership as well. Made a lot of mistakes. Managing my own product backlog helped a lot of people fixing some of their mistakes and not repeating my mistakes. And I'm currently working at a consultancy firm in the Netherlands called cowanas, where I get to do all of these fun things, aside from also being a professional scrum trainer with Scrum dork, and last December, I started a YouTube channel together with my friend and fellow PSD Bart, having a lot of fun doing that as well. And yeah, talking about products and agility more over there as well. Yeah. Looking forward to this one. Trish,

Patricia Kong: 5:01

great. So for people who just joined on, we're doing an Ask a PST, so please submit your questions. We're starting to get some in. As we start to get those in, I wanted to ask you, Simon first, what is the biggest challenge that you've seen as like a common thread with your customers in terms of managing product backlog.

Simon Flossmann: 5:31

Okay, we can tackle it with an interesting story. So I think I don't know. A couple of weeks ago, I stayed at a hotel, and after checking in the hotel and going to my room, I discovered there is no Wi Fi, and I actually had to pay for the access path for one night. I think it was around six or seven euros, which was kind of interesting experience. So my question to you, does is having a Wi Fi, a feature of a hotel, and what kind of feature Do you think it is?

Stas Pavlov: 6:10

I don't feel it is a feature, to be honest. I feel it's something that you expect to be there. It's a I would almost call this rude, but maybe just because I'm Dutch, yeah, I would expect this to be included, not having it feels like you might have stepped into a time machine. Yeah,

Patricia Kong: 6:31

exactly like insulting consulting to ask me to pay for that, yeah?

Stas Pavlov: 6:39

Maybe like in an airplane, I don't, I understand it, but in a hotel, no,

Simon Flossmann: 6:47

yes, and I was, I was thinking a little bit about different features of a hotel room, so I would be a little bit embarrassed if the bathroom or so would be outside of the room, or something like that. So you, you used to have Wi Fi, you used to have a bathroom, a a bed and so on. And we are, I'm not used to have a hot tub or something like that on the floor. And that's an interesting observation I made, which has been done very a couple of years ago. I think it's from the 80s, where one, I think it was a Japanese researcher, asked the question, do more feature make the customers more happy? So the performance of a feature, if it's increased, does it provide more value to our customer? And it turns out, no, there were a lot of studies done, and his research is based on it. It's not about the amount of feature you have to improve your product which makes your customer more happy. It's about the emotional reaction on to a feature. So what does it mean? So for simplicity, we can divide features, or something like that into three categories, which are the must haves. These are the Wi Fi for your hotel room. Then we have some kind of performance feature, which means the more feature or the more quality of the feature you have, the better the experience for the user, the more value you could create. And there are some features which you do not expect. Kano, the founder of this model called this one, I think, delight us. And why is this an interesting story? In terms of product backlog management, I think that's one of the most common problems. And what I experienced over the years to understand that not everything has the same value, and not more finished product backlog items mean more value for our customer. And the question is, what do you work on and what not? So what do you prioritize on top of your product backlog and whatnot? And I think that's the most critical part, because of the end of the day, resources are constrained, so maybe stas you can add something to it from your experience,

Stas Pavlov: 9:07

yeah, I love the topic of product backlog management. It's one where I struggled with a lot when I started out as a product owner, initially I focused on really trying to create these perfect PBIS like I was reading books on user stories, stuff like that, reading a bunch about how to actually write requirements. And at some point I was really good at writing, like perfect user stories, really good requirements, only to find it didn't help me at all. I was able to perhaps better confuse my team and my stakeholders, because I kind of forgot that it's really important to do this in collaboration and to also put it into the context of having a product vision, a strategy, and really setting goals like, why is this thing valuable? I. And what I find interesting about prior backlog management, it's a topic that's both over emphasized and under emphasized in importance. What I mean with over emphasize is like we really just spend a lot of time writing things in a specific format, which really there's no reason why you should. It might be helpful, but there's people who claim that we need to follow these strict formats. You really don't. But also we tend to overestimate the importance of the stuff that's actually on a product backlog. Because people talk about, well, these things are valuable, and that's not true. Everything on your backlog has zero value. It's potential value, but whether or not it's valuable requires an actual release and an actual consumption by a customer. So perhaps it's better to spend as little time as possible and then get it out to a customer, ship it, see what it does.

Patricia Kong: 10:56

All right. Well, then on that note, thank you for sharing those stories. Think that conversation station started a little bit in the chat around MVP and all those things, which is really interesting, right? Because, oh, we could go down a rat hole, and I want to jump in, and I'm trying to resist, but I'd like to get to everyone's question. So most valuable payer, right? I'm gonna start with these thoughts, and I'm going to try to just just read these as these are, to make sure I'm getting the the questions correctly. So first question, I am the scrum master for the only Kanban team in our department. The Business struggles to track the value we deliver because our backlog and throughput are measured at the story level, rather than the feature or epic level. What tips can we use to meet the business need for a three month roadmap while still maintaining a kanban approach?

Stas Pavlov: 11:54

There's a lot to unpack here, to be honest, not so much the Kanban stuff, but the business need for a treatment roadmap approach was still maintaining a common roadmap was still maintaining a common approach. I think you can, for me, it seems that you might just need to have a bit more admin rights in I'm not sure if it's JIRA or Azure DevOps, it's either one of these, these ticketing tools that could help. But for me, this is really more of a symptom of a organization that really wants to understand when stuff will be delivered, which is a fair question to ask, like, if something's on the backlog, there's an expectation of delivery and the people not being able to report on when that will be in a reliable manner, that could be it. In that case, adding more stuff into a ticketing system is probably not going to help. It's probably better to instead have a conversation with the people requesting these things and really trying to understand, why is it that you need this information, and how can we provide this information to you in a clear and concise manner? Because, let's face it, if this is a bunch of slides, nobody's going to read all of that stuff. We don't, simply don't have the time for it. Have a conversation with the people who are asking for this stuff and really trying to understand, what is it that you need to

Patricia Kong: 13:24

know? Sounds like the story. Story done, 123, like it's interesting

Stas Pavlov: 13:30

to see. It's an it's a focus on output rather than on outcomes. So you should be having a conversation about value. But maybe before you can, you really need to see, look into the predictability aspect.

Patricia Kong: 13:45

Anything to add? Simon,

Simon Flossmann: 13:47

yeah, I would tackle the idea from stas or the question from the same idea as does. So if going from story to Epic to theme just makes this the requirement bigger and bigger. That's one direction you can take to derive to a roadmap. There's also another direction. It starts hinted at it. And you can also start at the story level and ask yourself, Okay, with a story, you want to produce something, and who does it benefit? And what's what's benefit, which is typically the notion of an outcome for your users and customer, depending maybe you have internal customer, external customer. This doesn't really matter, but what behavior change you want to see on their side, with benefits them and on the long run the organization. And you can come up with a road map and try to specify these behaviors you're looking for. It's a different approach. It's more like a goal setting roadmap. And I did this a couple of times, and then typically you get pushback, because if you don't know what to build, how can we forecast? That's. Fine, but you can try to combine both. So you can try to make goals which a little bit more outcome driven, which try to specify specific customer user behavior you want to see one hand, and then your product backlog items could be bets onto it, but leave a little bit room. Maybe something will change. You will learn some stuff, and the behavioral change is not so here what you're looking for, then you can add stuff to it which combines both sides. You can provide a little bit more predictability on the outcome for your stakeholder, but you have a little bit room to add new ideas to it. That's one way you can try. It's totally different as what stuff said I said at the beginning, and it doesn't matter if it's Kanban or Scrum, I think so. Yeah,

Patricia Kong: 15:50

there sounds like there's some fundamental things to think about there, and some good techniques. So Simon, staying with you, this is a good question. My product owner is new to his role and needs me to advise him on different techniques for prioritizing a product backlog. He's the product owner of one team within an agile release train. Any ideas for me to help him with choo choo?

Simon Flossmann: 16:19

Okay? A couple of ideas. So it depends a little bit on this situation. So I think the first thing you should help them is to learn about the stakeholders. I know stakeholders are very broad term here, so we can look at actually users, customer or, to be honest, sometimes it's more likely internal stakeholder you want to satisfy. I would say that's the first idea, to connect them. There are different techniques, like mapping techniques to know your stakeholder, who are your stakeholder. You can look at processes, where does the work come from? Who are you interacting with, and these kind of things to get a sense. I think that's the first step. And then at the end of the day, you need to talk to them, what's on their radar, what they want to achieve. That could be one source for prioritization. It doesn't have to be the ultimate source, but it could be a starting point. Maybe stas you can add some more. Yeah,

Patricia Kong: 17:17

anything? Anything to add there in terms of other tips, because I'm going to get you on stakeholders next. Yeah,

Stas Pavlov: 17:25

I love this question, by the way, because we need to understand that. So I'll briefly take you to my most used priority prioritization methods, which is number one, my opinion usually based on insights about my product and talking to people, maybe just not opinion, but usually there's a story attached to it second, and that's a shared second place. There's it's either the opinion of my team or the key stakeholder I know could be the CEO, or whoever is paying the biggest part of your budget, and the rest number three will be other stakeholders opinion. And the thing that I will do is I will sometimes use tricks, if you will, to translate that opinion to I know some kind of number like I will give them a bunch of Monopoly money that which they can then divide on which features they might want to invest in the most. But the reason why I call that a trick is because it's not true. We are trying to quantify opinions, and the benefit of these methods is that it allows you to have a conversation about, why are certain things more important than other things? And it could be a bunch of factors, right? But you need to have that conversation. Maybe some kind of formalized process helps there as well. You could use stuff like value poker, both for efforts and for for business, you can use methods like ice or just an opinion, because the thing is, you don't know whether it's true unless you start releasing it, and there's a very low correlation between your assumption and the actual outcome.

Patricia Kong: 19:20

So can we pull on that a little bit more? There's the next question. So you've given some examples, some techniques, and I'm sure you've been in this situation. I have myself. How do you handle situations where different stakeholders have extremely conflicting requests to Yvonne, I'm actually giving a webinar. I'm doing a webinar next week on the art of negotiation and product management. So that might be something you want to catch on to, but But you have an example and maybe how you handled something where there were very conflicting requests as a product owner. It.

Stas Pavlov: 20:00

There's always very conflicting requests. It's gonna depend. And I'll start with it depends, because I'm gonna use a lot of words to make that same point. Usually it's a sign of maybe there's a lack of cohesion or a lack of understanding between in your stakeholder group on what is it that's actually important here, or what, what is our actually, actual product? I find it interesting that we tend to have a different definition of the idea of a product inside an organization and outside of an organization, and we are able to hold these two conflicting definitions without even knowing it inside an organization, we sometimes qualify just a random system as a product, because somebody needs to own it, and that's fine. Sometimes that's part of a bigger product. Sometimes that's maybe a bit more of an internal product or a shared service, in which case you might not have that many ways to actually steer the direction of the product, because you're part of a bigger thing. If that's unclear, then everybody will just have an opinion on what the product is, and then they will steer in the direction that's most beneficial to them. In that case, fix your stakeholder management, if you will.

Patricia Kong: 21:26

Thank you on that note, let's just No, I'm kidding, Simon, this is for you two part question. I'm going to combine two of them. What are concerns with the backlog that only grows at a much faster rate than delivery happens. On top of that, how do you man, how do you recommend handling defects in a backlog? So one is, what do you do with a backlog that just keeps growing you don't see the delivery happen? And what do you think about handling defects in the backlog? I don't know if this person is maybe trying like, oh, let's pull them off, let's put them on.

Simon Flossmann: 22:04

That's an interesting one, so maybe let's start with, why do we have a backlog in Scrum? And Scrum is all about creating transparency so that we can inspect and adapt and do this as informed as possible. So we should make as good as possible, try to make good decision as possible. Now we have three artifacts in scrum to provide us transparency. So we have to increment this somehow represents the past. So that's the stuff we already did, and we have to sprint backlog what we are working currently on, and then we have some ideas for the future. So we think the future might look like this. That's the product backlog. And the moment we can make all three artifacts transparent. So we have a product increment or a product we have sprint backlog, and then a product backlog, we somehow make the whole time frame transparent. So that's the thing here. Now, what has it to do with product backlog management? In order to make a product backlog transparent, there are a couple of techniques, but to be honest, the number one technique for me to make it transparent, it should be short. The larger it gets, the less transparent it gets, it's you cannot. I don't know how many items you can keep up in your head. When I think back on my time as a product owner, the first position I had, we started with one team. At the beginning, for a couple of sprints, I would say we had 5200 items, and one day we had 100 and something, and it was unmanageable for me. And then we scaled up to three teams over six months, it was a complete mess. Nobody knew what to work on. I had no clue what are the items anymore. So I don't want to say you should have a fixed amount of numbers, so no more items than 20. This makes no sense, but the moment the product owner does not know what's in the product backlog, you should think about deleting stuff, combining stuff, make it a little bit more abstract to have a better overview, and you need to re refine the stuff if it comes More closer to implementation. So that's one thing here, and I wasn't sure, was the question that there is no release at the end of the sprint. It's

Patricia Kong: 24:27

basically that it's growing and they're growing faster than delivery. The second part was handling defects in the background. Okay,

Simon Flossmann: 24:36

so thumbs up. If you're able to release, that's a good thing. Then you learn, and then you know what to do next. But from a transparency point of view, try to limit it somehow. And I think we have a cool new tool for that, and it was introduced to scrum in 2020 that's the product goal. Now let's think about a time horizon, for instance, of three months for a product code just to say something. I think then the amount of product backlog items in the next three months should be the product backlog, and not much more. So the scrum guide is pretty clear on that. So the product backlog should derive from the product goal. Everything else maybe should not be part of the product backlog. At the moment, it's a little bit distracting. That's one thing you can think of it. And in terms of box, I have an opinion on it, I would put it to the backlog. Otherwise you don't get transparency. But I know it's pretty hard for product owner to decide, should we invest in a new feature? Should we invest and maintain? Should we invest in box? Therefore it should be on one list. And I think that's a good starting point. If you have two backlogs, then transparency is reduced again. Thus,

Patricia Kong: 25:59

what is your opinion,

Stas Pavlov: 26:01

don't have two backlogs. I didn't really don't know defects. Yeah, definitely put them on there, make it transparent. But I think maybe, to add to what you just said, Simon, I think it's important to understand what we actually mean with transparency, like it's not just visible, it's visibility is a really tiny part of the concept of transparency. Transparency is much more about do we understand what's going on? And that's the entire purpose of a product backlog, is to make transparent what the plan is to maximize value. So a really good way to test the transparency of your product backlog is show it to a stakeholder, and if that will then trigger a conversation that doesn't start with huh, but actually talks about the product backlog, that's a really good indication that your stakeholder is able to see your Product Backlog, understand what's on it, and have a conversation on on one of the things that's on there, and really have a conversation about the details, perhaps as well. That doesn't come just by having perfect PBIS. You need to do a lot of collaboration together with your stakeholders, together with your team. Specifically refinements is much, much, much more than just sitting in a room talking about how many story points something is. I think that's the most boring and perhaps the least productive part of product backlog refinement. Involve your stakeholders. If there's defects, definitely put them on there, make them transparent to your stakeholders. These things are problematic, fix them.

Patricia Kong: 27:47

Would that be how? There's another question that's relevant in here, about in terms of the prioritization, because just because there's a bug doesn't mean you address it, right? So how do you know what to do?

Stas Pavlov: 27:58

Yeah, absolutely a certain bugs you need to fix immediately. Other ones. If they happen once a month, you might be fine. Maybe you're in a release freeze. If you're an E commerce, usually during the holidays, end of the year, you might not want to do a release, because that's where you make 80% of your money. I've been in that situation. You will have to live with that book.

Patricia Kong: 28:24

All right, so I have just changing speed a little bit. This is a great question for both of you. I'll just start with you. Stan, so as a product owner, I will probably, probably say, I own the product. I own the backlog, Extreme Ownership, etc. I ordered the items. I tag them, I label them, I categorize them, I question them, I close them, right? They're they're doing everything the question, I'm afraid this could result in everyone else saying so the team, the stakeholders, go ahead. It's yours, your responsibility. We see that. Thank you. We're not you are not to blame if anything is wrong. So now it starts to feel like a one man show. I'm a perfectionist, which makes it hard to share responsibility. What is some advice for this person on how to overcome this? Or is that even necessary? Love

Stas Pavlov: 29:11

the question. And by the way, thanks Eric for sending this question. Actually, Eric was in one of my classes yesterday for the products, professional products and discovery class was a lot of fun, but great question. This is exactly the thing that I ran into when I started out with product ownership. I was doing it all by myself, and what we need to remember is that product management is really a team effort. It's a team sport. It's not just you, it's your team. It's also your stakeholders. I often say that a good product owner, a good product manager, is a lazy one, and I don't mean that you need to be actually lazy, although I am, but what I mean with that is don't just do everything yourself. To give some work to your team, but also give some work to your stakeholders. Collaborate with them if you want to really improve the quality of your product backlog and the transparency, perhaps, do some co writing on product backlog items, not just you writing everything and then explaining to the team what it is that you were trying to bring across here, and what I really like for this specific topic is a really old, old concept, actually something that was start off in the 90s, when the initial idea of a user story was created, and that's the 3c concept, card, conversation, confirmation, and I kind of compare that to everything on your backlog should be kind of a pause button for a conversation. And you might have a conversation with your stakeholder on some need or some problem that they have, and then at some point you need to continue with today and the meeting is over, you just want to summarize whatever that was talked about in a few statements, maybe a couple of words, perhaps on a piece of paper, and put it on your product backlog so that when needed, you can immediately go back into that conversation, almost like it's a pause and a play button for that conversation, collaborate with your team, with your stakeholder. And to be honest, I sometimes pretend like I don't know how to write product backlog items when I'm dealing with a new team, just so I can see how they actually go about it. And then I kind of stay in that groove. We do this thing together, and we have a conversation, and then you get really concise product, but everybody knows where we need to build and why, which is the whole point? I hope that answers it.

Patricia Kong: 31:47

I think that was great. Lots of techniques I'd be interested in. Simon, if you have some suggestions on a little bit of the deeper level of or different level of this notion of this person is trying to share that responsibility, and they feel like this is so important. So that person, you know, Eric's going to go and do everything that staff says, but still feels like, wow, I need to do all these things. How do you start to move this from that little bit of responsibility to this notion of accountability and having that group dynamic where everybody feels some shared ownership.

Simon Flossmann: 32:24

That's a That's a good one. I think it's a misconception. Also, with the notion of roles, accountabilities, responsibilities gets a little bit mixed up. And I think the accountability in Scrum is more like a safety net. So how does agility at the end of the day work? It's about speed, speed of delivery and speed of learning. And how you enable speed is by making decision. So if you don't make a decision, nothing will happen, nothing will deliver, nothing will be learned. So in order to become that type, or that agile, you need to make decision, and that's the safety net, net of a product owner. So when we are unable to decide, somebody decides not that she is right or wrong, but that we start learning. So we deliver, get some results, and then we can learn. So that I think that's from a bigger perspective, and I try to think of it as a captain of a ship. So every ship has one captain, and the job of the captain is completely different depending on the size of a ship. So if you have a very small ship just one person, then the captain does everything. He's responsible and accountable for everything. So if you look at a bigger ship, like a tanker or a cruise liner, there is still one captain. But does he do the same jobs as a one person ship? Hell no. I think the only thing what he is still knows what to which harbor we are going from where are we coming? That's it. He does not steer anything or so. He's just in charge of the whole ship, and it's a safety net. If something goes wrong, he can give direct orders what to do to resolve the situation. I think that should be more the notion of a product owner to have more free time to think, also more on the strategic level, and be a captain of a real big ship. I think that's the notion here. But I'm not sure if this is helpful. It's not very practical.

Patricia Kong: 34:34

I mean, it's an it's an exercise in developing as product general. So exactly, and

Simon Flossmann: 34:39

I think it takes a little bit time at the beginning, it's all about creating backlogs. But the more experienced you are, the bigger the picture you see, the more you become a captain of a bigger ship.

Patricia Kong: 34:53

I think, I mean, you pulled me in. So this notion of the captain is interesting, because you're staring right? But Eric, I think that was Eric. Eric, who said that Eric is a perfectionist, so if you want to be agile, you have to make a decision. You have to be ready to fail. You have to be ready to say yes, which means you're saying no to something else. So those are interesting things, and that's the only way you can Captain a ship, Simon. We're going to keep on going with you. And we have lots of questions. This one we've talked about this is for Fami. So one of the issues in my PO experience is that stakeholders always give very tight deadlines due dates for features migration. Because of this, my PO has problems. There's problems in terms of balancing between features that the stakeholders want now and features that actually improve the system. And then, because of that, our tech debt is increasing as life goes on. What is some, you know, one or two pieces of advice that you have for Fami,

Simon Flossmann: 35:53

we can tackle it from a more general perspective, what is value? There are different areas, I would say. And of course, there's a time component to it. I think does mention it. If you have an E commerce site, then in the holiday, the holiday season, before Christmas, there is a timely component. If you deliver something, then it will improve the revenue much more than if you deliver on the summertime. So there's a timely component to it. But that's not everything. Value is also more on the customer and user sides, how they perceive value, what they are able to do, which problems they can solve in their lives. That's the next component, which we can think of. And last but not least, there is also a notion of becoming better. How good are we to deliver new capabilities and stuff? And the more technical debt you have, you either get slower or you are less good at developing new stuff. And I think the critical part is to balance those areas. And I think the if an organization is very much focused or used to project like thinking, and that's the scope needs to be delivered on that time in that budget. Otherwise, everybody is mad. That's a hard thing, but I think you should look at value, at the more holistic view, and also to be at the end of the day, it's stakeholder management to educate them a little bit. What actually is value for your organization? How does it tie back to revenue at the end of the day? And I think there is a timely component, but not everything. It's on that component. Now

Patricia Kong: 37:37

the key value areas and evidence based management would be a nice place to look at the data, right? So what's what's holding you down, what's your time to market? What's actually contributing to value the future things we might work on? So looking at in that horizon lands, lens, lens, lenses. Looking at through those lenses may, may help. So take a look at the key value areas, Fauci and next question for you,

Stas Pavlov: 38:03

maybe to add to that, because I do want to add, we can get to that. You can make me uncomfortable with that question. But three things, because something about the deadlines we need to do, we need to fix predictability seriously. That's why we do Scrum. Don't use velocity. Velocity is trash. Doesn't do anything for predictability. Use something sensible, like throughput. Just count the number of stuff that you finished. Use that data and actually try to do something with predictability to your stakeholders that will kind of get them out of your hair. Secondly, with regards to the technical depth feature thingies, I have a trick that works for me. I'm not, I'm not going to say that that it will work for you, but I know maybe it's how I sell it. Instead of calling them features, I because stakeholders are kind of like magpies, right? They want more features, like more features, more stakeholder happy, for some reason. So instead of calling this thing also a feature, I call it an enabler. And I know maybe because it's also English, it sounds kind of cool. And usually the story is somehow kind of like, well, if we do this thing, it will enable us to do much more of these other things that you like like one enabler gives you more features. You like features, right? I know I'm oversimplifying it, but I'm trying to kind of sell it in a different way, and really trying to explain what will this How will this actually benefit us?

Simon Flossmann: 39:38

Framing, yeah, no, I want to add something. Do you want

Patricia Kong: 39:41

to answer about Jared?

Stas Pavlov: 39:43

No, go for it. No, no, I'm fine with Go ahead. Simon,

Patricia Kong: 39:48

go ahead. Simon, what do you want to add? I think one

Simon Flossmann: 39:52

key responsibility so if you're scrum master or so, to make the impact of technical debt transparent. In terms of money, because the only the common denominator for the stakeholder, what they're looking for, it's cost or revenue or something like that. It's all about money. And I think a lot of software teams, at least the ones I work with, are doing a really poor job and converting their internal work, what's needed that the software is maintainable and still functions well to financial outcomes. And if you can do that, if you compare it to what you will likely gain from implementing another feature or something, then the this conversation is a really different one, and that's something you can also try. You can start with costs, of course, development costs. So you can at least add a number here. I think that's a beginning, but maybe it's a little bit of cool metric. But the more you dive into it, the more you actually see the financial impact on delivery speed and ability to invade and I think this one changes the conversation by at the end of the day, money is what drives businesses. So maybe that's but now you can ask us about JIRA.

Patricia Kong: 41:13

That's really those are all great, great points. Okay, sass. Are you familiar with JIRA product discovery, how are new products like this impacting backlog refinement or management, and in general, what are your favorite tools for product backlog management?

Stas Pavlov: 41:32

Cool, yeah, love the question. I'm not familiar with JIRA product discovery. I'll probably suffer from it at some point in the future. Use So regarding tooling, use the tools you have, because often you are restricted by whatever the organization gives you. Use those, but try to keep it simple. But in terms of product backlog refund, it's product backlog refund is one of my favorite things, but because it's much because it's much more than just sizing and talking about requirements, for me, product backlog refinement is all about and trying to answer the question, what is it that we're trying to build, and why? Kind of like product discovery, which is also about, what are we trying to build and why? So during refinements, that's the place where we do product discovery, which I really enjoy, because that's where we come up with new stuff and do prototyping. So I use a bunch of techniques for product backup refinements. It's really good way to put those darn business analysts to work, because you always get this question, well, what should I do during this print Well, work in product backlog. Same for architects, same for UX people. It's all called product backlog refinement, easy, but you can do prototyping, customer infused, digital prototyping, all that jazz, right? However, a lot of teams overlook the importance of developing actual slicing skills, and it's a skill. It's not just sitting in a room staring at a screen or pretending you're staring at a screen, screen, because the scrum master is sharing his screen on the big screen. It's really trying to understand, how can we actually create functional slices? Alistair Coburn, one of the Agile Manifesto writers, did fantastic work on this topic. We all know the concept of elephant carpaccio. It's one of these legendary things in the world of Agile. If you really try to understand how that technique actually works and how you can do something like that with your developers, there's a lot of value there. Another version of that is called hamburger slicing. It's really developing the skills, and how do you create functional slices, and how do you actually have that conversation with your team? For me, most effective ways of doing that is not using a laptop, close your laptop, either use whiteboards, flip over, or if you're in a distributed environment, use tools like Miro. I like, I really love tools like Miro or Miro, or even whiteboard, if you're unlucky, like Microsoft whiteboard, because they allow you to make these things visual and really collaborate with each other and have a conversation in that matter. But you need to engage people. You need to develop this these skills as a team. Doesn't really matter if you develop these skills by yourself, like it's helpful, but you need to guide your team in actually developing these skills using the tools that you have. My role is great. I use a lot of generative ai, ai, atom. Moment, which is great. It doesn't replace the conversation. All the output that you will get from Ai tooling is fantastic. If you have a effective conversation around it, it doesn't replace the conversation. That's why it's individuals and interactions over processes and tools. These tools are there to support your interactions, and that's how you should use them.

Patricia Kong: 45:28

All right, thank you. Staff. On that one, that was a really good speech. We have 15 minutes left. No, I really actually, there was, there was, there's a there are a lot of important reminders there that are beyond just, you know, tell me the tool. So we have 14 minutes now, and we have lots of questions on our backlog. So this one's for you. Simon next, how can I as a scrum master, handle when the items in the backlog are suggested solutions rather than user needs for the team to solve. I think you gave a suggestion before, if you want to, just reiterate it quickly, and then I have another question for you.

Simon Flossmann: 46:10

If the solution is done, what would be different for our user, customer and so on? That's the question I would ask, and that's the thing you should aim for, that's the thing you should write down. And let's just switch from output to outcome, and it has a different conversation, because now there maybe is a different output as well which creates the same user behavior

Patricia Kong: 46:35

you want to see. Let's just use anything like impact mapping or anything like that.

Simon Flossmann: 46:39

Yeah, that's some more advanced technique, but the idea is the same, if you're doing this, which what should be different for our users and customer? What can we observe that's typically outcome? And then you can think of impacts as well. And

Stas Pavlov: 46:53

maybe to add to that, sometimes it's fine, if it's just a solution, if that's everybody understands what it is, keep it simple,

Patricia Kong: 47:01

yeah, just know why you're doing that. Yeah. All right, Simon, what are your experiences and best practices for getting an estimated backlog quickly at the start of a project? My goal is to be able to create a forecast as soon as possible. I'm assuming it will be on a higher level feature or epic, but how exactly, and how do you go about getting a more accurate estimate later in time at the PBI level, so that the possible incorrect assumptions can be made transparent as early as possible. This is from anonymous.

Simon Flossmann: 47:35

Yeah, the thing is accurate in estimate does not go a long way. So there are a bunch of techniques I want to share. One thing which saved me, um, my job as a product owner, I would say, oh, story time. So when we start, we were starting out. We had a tight deadline by the end of the year to deliver, I think it was the second iteration of the product I was in charge. The first one was not really good, to be honest. And I think we had around 122 product backlog items. And I was pretty comfortable, the more the team and knows each other, the more likely, the more faster they will develop and everything will work out fine. So I was pretty confident that 122 items with a velocity of five, which totally doable in 10 sprints, something like that. And then the scrum master took all the developers into a room, and I was not able to join. It wasn't allowed to join. And then they did a technique that I learned the first time called Magic estimation, where they really quickly estimated all the product backlogs in a relative scale. So they developed one as a baseline, and then they compared all the other 22 items with them, if they're bigger or smaller. And then they came back and they told me on a rough estimate, so it will take more time, Simon, we will finish next summer with all the stuff you have currently in your backlog, the one to 122 items, I think they estimated for around 90 minutes, or something, to 122 items, and they used some crazy techniques. They were not allowed to talk, and these kind of things to make it really fast. And what's the benefit here? It's not about precise estimation, because I think that's a waste of time, but you need to have a rough idea if it's feasible or not. So that I, as a product owner, can course correct end of the day. I think we delivered by the end of the year, maybe 28 items or something like that. So he he showed me, I should focus on the most important one, because the other stuff will not be built. This will not happen. And the estimation effort was around 90 minutes. So I'm not sure if I'm answered your question, maybe stuss can add some more cool techniques. Oh

Stas Pavlov: 49:57

yeah, for sure. So interesting question. And yeah, like Simon said, estimation and accuracy, there's no such thing because we're dealing with complex work. However, if you want to improve the accuracy of your forecasting, which will never be 100% focus on developing these slicing skills that I talked about. They really help you. Also stop using philosophy. It's rubbish. And the reason why it's rubbish because if you look at the data, and I've done so like a lot of times, I know this is a controversial topic somehow, but the data really shows us we suck at estimating. Just think about the amount of times that people told you Just five more minutes, and those five more minutes turned into 10 or 15. That should give you a good indication on how good we are at estimating. But this is also the reason why we don't talk about estimations anymore in the scrum guide, we talk about sizing. Improve your sizing. You will improve your accuracy of your forecast. However, if you would just want to have something be done faster. Just move it up in your product backlog. That's the easiest way, like if you wanted to get this done now put it on the top of your backlog. Downside is you will have to explain to other stakeholders why. They will have to then wait for a longer time. Tip, have stakeholders in your sprint review. That's why they're there, and then have those conversations there. So it's not you trying to having to explain these things, it's them having a conversation about these things. But use throughput, use cycle time, use work item aging. Those type of metrics are actually helpful because they are real data, rather than an estimate, which is something that you've made up. And then use stuff like a code of uncertainty, which is a really easy way a burn up, release burn up, to use the data to visualize when things might be done. Best case scenario, worst case scenario, not the most accurate, but the most easy one, because you just need to count a bunch of data that you have plotted in a graph, but if you want to improve it, look into stuff like Monte Carlo simulations. Those are much more helpful. But again, there's no guarantees here, and the more variation or variability in your product backlog items, the less accuracy you're gonna have as a result in your forecasting. It's called the kingman's law. But yeah, there's a bunch of stuff that you can do. The only thing that you can't do is guarantee.

Simon Flossmann: 52:31

Plus, there's another dimension we could mention, not only the variety on the product backlog items, but also, if you look about team and technical practices. So if you change the team every sprint, no estimate will ever work. And if you do not invest in modern development practices, you will get slower, slower as well over time. So these are two very important factor where, for instance, a scrum master can work in the background to guarantee a little bit more, I would say I could, I don't want to say the word velocity, but a more stable development velocity that I think that's a critical part nobody talks about. That's the value of Scrum Master. Also provides having good

Stas Pavlov: 53:21

coding. And maybe to add to that, whenever you say something to a stakeholder about a timeline, always use the caveat. Based on what we know now, based on the current state of the product backlog, and based on the past performance of our team, our forecasts for this specific item will be best case scenario then, and worst case scenario then. But that's all premise on what we know right now things will change.

Patricia Kong: 53:49

All right. So I have two more questions that I'd like to get to that are on a little bit of different topic. There's such good questions, we just aren't able to get them through, through them all. So I'm actually going to move to the bottom of the list, and it's a question from Mary as a PO assigned to tech debt features, how do I have a productive refinement session when my understanding of technical requirements is a bit limited, and I'd like to expand that in general to even, you know, when I'm a product owner, I'm not that technical. How do I help with refinement? Simon, you're nodding. So can you take that and give us one minute.

Simon Flossmann: 54:35

I think stuff's already decided. You don't need to be a technical expert. You need to be a you need to fall in love the problem you try to solve, not with the solution, and guiding developers with questions and don't give up easy. There's always a way to make it smaller in these kind of things. And I think stas has mentioned a couple of things. There is some how is it called splitting sheet with different. Yep, years. Who did develop this one? It's an Australian

Stas Pavlov: 55:04

fella. I forgot his name. He's done some fantastic work on slicing, but I was more over splitting tactics. We can include it into the show notes aftercare package, whatever we call it,

Simon Flossmann: 55:23

something so get comfortable with, do not know the solution, but the problem, and then start asking questions. Yeah,

Patricia Kong: 55:31

that's powerful, right? Because, and then there you're talking also about, there's sometimes some sort of, I don't want to say power dynamic, but something when, like, she doesn't know what she's talking about, so they're just gonna, they're gonna dance around you, right? All right. That

Stas Pavlov: 55:43

being said, I think it's really helpful if you invest in understanding the technique of it, like you need to understand how your product actually works. That doesn't mean you need to be a, be a coder, but that really helps you to build a rapport with your developers, sit next to them, just have them explain to you what is that they're doing, and then really to explain the architecture, and spend some time actually understanding the technique

Patricia Kong: 56:11

and interested, yes, staff, this is for you from Wayne. How do you incorporate ITIL, change management, review, evaluation, approvals, into the product backlog, I'll say refinement process evidence is required for regulated industries like banking. You work with a lot of clients like this. What would your suggestion be? I do. I

Stas Pavlov: 56:31

just really not an expert on ITIL at all. I would say a whenever I need to understand it, I acquire that knowledge in the moment, and then I forget it immediately. So let me read the question. So from my limited understanding of ITIL, if certain things have a certain priority and you need to do it in a certain way, that could either be part of your definition of Done, or if something is deemed extremely important, just do it. Obviously, that's how you need to set it up. But maybe this also adds additional steps in your development process, and add those steps as a column in your workflow. That's why we have these JIRA or COVID or scrum boards, whatever we call them out in the wild. Don't just have a To Do, doing done. That's the most immature workflow that you can have. Have a representation of the actual steps that you need to undertake in order to get something out to production or out to whatever the next stage in your development cycle is, in your organization, which is not always done, we want it to be done. Sometimes it's another step. And even if you're done, you're not done. But visualize those steps as part of your process. That could help but maybe. Simon, if you are more knowledgeable on ITIL, and I apologize waiting and it would need to brush up on my knowledge. There, maybe you have some additions.

Patricia Kong: 58:10

I think, I think for me into what you suggested, what I found really interesting, this is to looking at it from a different perspective. Is actually assigning how long it takes for each one of those steps to get done. Because sometimes we think that something else in this type, in those types of industries, insurance, banking, is that we need some other things. But it's actually this process, that approval process, that takes a long time. I think, breaking it down, putting that time on it to see what, what might be an impediment, and how to speed up that process is

Stas Pavlov: 58:40

interesting, and that's again, where we try we track work item cycle time, right? So we have this data

Patricia Kong: 58:48

all right. So thank you very much, both of you. Thank you everyone for attending, listening all your questions we have the rest of them, Stass and Simon can address them all in their after package. I'm just kidding. We'll find a way to make sure that those questions get answered. And if you liked something like this, let us know, put it in the chat. Maybe we can do another podcast episode or something like this, where we talk about the rest of the questions. Okay, this has been really fun. Thank you again. And have a great day everyone. Actually, how can they get in contact with you? Steph and Simon,

Stas Pavlov: 59:22

thank you. That's really good question. So either you can, if you're Dutch, I would say, because right now it's just in Dutch, subscribe to my youtube channel at your BS link is in the chat right now. Or you can connect with me on LinkedIn. I tend to be pretty loud and obnoxious there as well. Some people enjoy it. I don't shy away from controversial opinions based on facts, like why philosophy is trash. So yeah, both are in in the chat right now. Or you might. TV on local events meetups, or perhaps scrummy Europe in the summer.

Simon Flossmann: 1:00:08

Thank you, Simon. I think the easiest way is via LinkedIn.

Patricia Kong: 1:00:13

Okay. Simon Fauci, all the hard questions on LinkedIn to you, and again, I'll be doing a lot of your questions were relevant to this the art of negotiation for Product Management. I'll be doing that next week with PST Magdalena furloughed, so we have some content for there for you too, and we're also working on some ethics pieces in product management, which is exciting. All right. Thank you. Have a great day, everyone. You doing Cheers, bye, bye, bye.