Backlog management from a different point of view

Welcome everyone to another episode of the Product Bakery. I am Alex and I'm here again with my co-host Christian. Hi Alex. Hi Christian. Before we jump into today's topic I quickly wanted to share with everyone that you can find us on social media as well as we launched our new website on productbakery.com and on productbakery.com episodes you can also find all our episodes with timetable and transcription as well as the possibility to comment and I think what is great about the commenting functionality is that you will also have the possibility to directly interact with the speakers and ask them whatever questions you might have to the episodes. With that said Christian I know there is one topic that you always want to talk about. It's general backlog management and I know it's also a very important topic for all product managers out there. Christian I'm happy to hand over to you to tell us a little bit more about what backlog management is all about. I don't know. I'm kidding but this episode I wanted to record it since a longer time because I have also promised a couple of people to do so because they had questions and I'm working right now with a couple of product teams that are a little bit more junior people who just get started in product management and we obviously work also on the basics and we spend some time on managing the backlogs getting ready for projects setting everything up and there are yeah there's a quite a pattern on questions and now it's really the right time to pick those apps because they are first of all fresh in my mind and on the other side it's a pattern. What's the question that you hear from everyone when it comes to backlog management? This is already the one million dollar question Alex that you asked. There is this common question of how to write user stories and how to write epics. I don't want to go into that today too deep because there are a couple of things to look at before you take care of writing stories, writing tasks, bugs, etc. whatever it is and who should do it, who should not do it, etc. There are these endless questions around those. I see many people not taking a step back and looking on the big picture so this is actually a common theme that I'm experiencing right now and want to talk about today. Awesome. Go ahead. Yeah well there's a nice story that I want to share. It's in Italy hundreds of years ago. Leonardo da Vinci was walking down the street back then and at some point people recognized his drawing skills and there was a lady who recognized him on the street and she walked through him and said, da Vinci, da Vinci, I'm such a big fan of your work. Could you draw a picture of me? So da Vinci said yes. He took out a piece of paper which was a little bit bigger than his hand and he started drawing this beautiful lady and after two minutes he managed to draw a, we would these days say a pixel perfect picture of that lady and he showed it to her and she was impressed. She fell in love with it. She said, amazing, beautiful. Can I have it? And then da Vinci said, no problem, but it costs you two millions. And remember 500 or a thousand years ago that was shitloads of money. Yeah. And she said, what two million? That's so much and I can't afford this. And it just took you two minutes to draw it. So how can you charge two millions for that? And then da Vinci said yes. And it took me 30 years of my life to be able to draw a perfect picture of you in two minutes. And what does the story tell us about backlogs? Everything inside the backlog and the tickets are the in quotes, 30 years that you need to understand and learn and to prepare. And this is what backlog management is about. The whole preparation phase and making sure that you know what you're talking about to have to write KPIs, numbers, and data in place to be able to phrase it then in smaller chunks of work and share it with the teams in forms of problem statements with, for example, hypothesis, business criteria, et cetera, to then come up with a solution instead of fighting or discussing too much, whether it should be this type of story or the other type of a story. Quick question before we dive into the 30 years of knowledge that you need to have to write a good user story or tickets. Did you just invent this story? It's a real story. Okay, awesome. I mean, I love your, I know your love for Italian stories. So I thought maybe it was just like something that you managed to make up. But Da Vinci didn't know back then about backlogs, but this is now my additional part. Okay, awesome. Then let's get into the crucial knowledge. And I think especially if I'm not sure about how to structure my backlog, what are the things that I need to know or that I need to be careful about before starting? Generally everyone does it different, but as Ryan in one of the previous episodes said, so there are a couple of non-negotiables and there are a couple of things I'm very open about. But one thing that I see in many backlogs, and I really like using the quote, show me your backlog and I show you your future. It's really true. So the quality of the backlog is super important and also a clear indication on what the outcome will later be. So if I go into a backlog and I see tickets with just one word and no description, you can very likely assume that stuff is not well prepared or not well discussed. And even if it has been discussed before, the moment you walk out of a meeting, you will forget 50% of it or even more. I would never ever say you have to document everything, or I'm not the kind of guy who would ever force a team to spend more time in writing tickets and working on those. But you see a clear pattern that people with clearly defined backlogs and a well-prioritized backlog produce better outcomes than people who don't. The very first thing that I think is very crucial, whether it is a user story, a tech story, a task, a spike, whatever is out there, most important is that it has a valid description and it has acceptance criteria. Without acceptance criteria, it's the hardest thing to do because you don't know what the scope is. You don't know how to test it. You don't know what you can see as done later, what you're going to accept as a product manager or product designer or both. So it starts really with the basics, making sure each ticket contains the information it needs. And many times people doing their day-to-day business tend to just create a ticket for the sake of having one, working on it with best intentions, but clearly missing out the process of communicating and making stuff transparent. And this is a big issue that I see where I would first of all say, whether you are working just a week, couple of weeks or years with your product backlog, make sure it contains all relevant information it has to. So if you would have to break it down in pieces of relevant information, what would it be, right? So you mentioned already description and acceptance criteria. Is there anything else that we need to add to the mix? Before I talk about it, let's maybe start on the higher level because I just recently got asked by a design student who has to create a backlog based on a couple of designs he developed. He asked me how should he structure his backlog and how to get started. Maybe we take a look at this because then we will also automatically answer the question of what information should be defined. What I like also looking at the current tooling landscape like Jira and Atlassian and all its products. Let's assume you work with Jira, but even if you work with sticky notes, doesn't matter. I think always having a feature on Epic is to me the starting point to collect basic information of a problem statement, hypothesis you have, how to solve it, business criteria, legal criteria, maybe even a couple of wireframes or depending on how the design processes work, maybe even already a nice working prototype. Find a source of truth that you put into your ticket system or whatever you use to have something that you can build up on. You start really with the high level and pitch it already to the team in form of a kickoff meeting to really spread the basic information of what you want to achieve. I think that's the very first thing. And I already mentioned a couple of points now inside like the problem statement, hypothesis, and also measurement criteria, success criteria to be able to also know when you have achieved or solve the problem. Once we have that, we can go deeper and then break it down into user stories or tech stories or tasks or whatever people use these days. What I see there is that many teams start discussing what is the right thing. So is this now a user story or is this a tech story? So this is one of the most common discussions that I hear. And I have to say, I can understand people asking it because if you look out there, there are many blogs, many opinions, many people are very religious about it. Some are more loose about it. And I get asked what is the right thing to do. And I like pragmatism. So I say, if you need more than five minutes to discuss it, fuck it. What I always did with my teams was saying, instead of discussing whether it's a technical task or a technical story or a user story, we just call it story. And if we have basic information inside a story, like an introduction, like acceptance criteria, maybe testing metrics or whatever belongs to the ticket, you will automatically solve the problem of what type it is. Because at the end of the day, we all need to know what we need to do. Yeah. Yeah. I think the pragmatic approach is generally always super important. And believe me, I had it so often that I spent more time simply discussing, okay, how exactly, even down to how exactly do we write a user story? And then people getting crazy about, okay, but this is a topic or in your terms, this is a story that I cannot fully pack into a user story because it wouldn't fit the semantics of how we write user stories. And then they spend hours on trying to figure out how they can write this one perfect sentence. And this is always something I was struggling with and I've seen different people bring different levels of religion, let's say, in how strict they are also in writing tickets or not accepting tickets that are maybe written in a not semantically correct way, even though all the information would be there. Yeah. Yeah. This is definitely something many teams are fighting around. And I only can say, instead of fighting, work together and try to find what's the best way. And again, the scope of your estimation or the work that you need to do doesn't change based on the ticket type. But what is important is to understand at which point a ticket contains all information to be able to start working on versus understanding, Hey, this is something which is not clear to us. And we maybe need a spike ticket or investigation time to do further planning, architectural planning, design sessions, et cetera. This is something where I also see many times people under pressure or especially product people trying to push things through also on their engineers. And this is not in a negative way because it's natural. It happened to me many times. So take a step back and really think about, first of all, are all information there that need to be there considering that you have eventually something like a definition of ready, which already contains basic information that should be in there instead of being too religious about the way you phrase it. But maybe just on this, because now you've been talking about like product managers forcing things on the engineers at the same time earlier, you were talking about like a design student who had to create a backlog. Who is the person who should be in charge of the backlog and writing the items for the backlog? Well, if you take a couple of scrum books, they will say it's the product manager. To me, it's common sense that I work with people together. And we just recently talked also to Luca, for example, about the future of product management and what the role of the product manager will be or teams in general. And I think looking at this, everyone should be a product manager. Everyone should work as an engineer. Everyone should contribute to everything if you can contribute something valuable. So for sure, at the end of the day, the product manager is responsible for the product backlog. And with responsible, I think also about the impact that backlog has, and also about the product roadmap and the future outcomes that you're going to produce. While I think still at the same time, if I have a very nice defined epic with business criteria, a problem statement, et cetera, I can also pitch that to my team and ask the team to break it down. And I've done this many times and it works actually very well. Let's imagine you want to redesign something. You can either do it screen by screen. For example, you and I as product manager designer would propose, but the engineer said, maybe we want to do it on a component base. It's much easier, much faster. So instead of telling people what to do, what you sometimes do when you go too deep, you rather pitch the high level thing and let them decide. So in this case, you as a product manager would give the context and then the team would pretty much write the stories themselves. Yes. Redesign is a very nice example to visualize it because this is usually something that you just release once. So once there are smaller tickets that have been finished, you're still waiting for the big thing to see and to test, et cetera. So you can really manage the high level exitance criteria on epic level. And then on a detail level, they can be a little bit more technical, which is not a problem. They don't need to fulfill the classic story template with all relevant business information, because they're already connected to the epic. How long should such an epic be like, just because because that, that has also been something I've, I've discussed like a lot on does an epic need to fit a sprint? How long should it be? How complex should an epic be? How many stories should it fit? Where do you need to split it or not? Let's talk about common mistakes that I've made back then when I was just introduced to the notion of epics. I created an epic and it was back then, I don't remember. I think it was the very first epic I wrote was a conversion rate optimization like topic. So we created that topic. We started working on improving the checkout, driving to conversion, redesigning slowly screen by screen. But at some point you realize this epic becomes bigger and bigger and bigger and bigger and bigger and bigger. And the biggest learning I've made back then was to always set a clear scope. How big should it be? That depends on your industry, on your company, on the context you're working. In B2B business, we have sometimes yearly projects, so that are very long or very big quarterly projects. But I'm saying define a beginning and define an end. And most important, and we also talked about user story mapping and MVP definition. So define the MVP and slice the epic based on the MVP. I think that's always a good rule of thumb you can get started with. And everything which is coming additionally on top as a 2.0 feature or 1.1 feature, whatever it is, and start linking tickets into the next epic. But would such a big and complex project like redesigning a whole experience be an epic? Let's talk about SumUp, right? The company we did work at when we were doing the redesign of the whole applications. I would say the whole redesign of the app was more an initiative than a big initiative or a big opportunity, however you call it in business terms. And what we did back then was doing it screen by screen and also the processes behind it, for example, the checkout flow, product creation, your text page, et cetera, your reports. So we broke it down like that and worked on it so that we had at some point every epics completed to really say, okay, now we can go into testing and also preparing a launch to holistically bring everything live. But the size, yeah, an epic can be something that you do within the sprint and it can be something that you work on multiple weeks and sprints and maybe even a quarter or longer. So that depends. The less scoped it is, the longer it will take. So the more you are precise about what is really in scope in that epic, the faster you can get it through and the clearer it will also be to all the team members. Another thing in terms of also coming back to the question of who is responsible of creating the tickets. I mean, I obviously like totally see or I am on the same page with you that it's important to see it as a collaborative team effort in creating the stories or also like filling the backlog. But at the same time, I'm also wondering if there should be some sort of acceptance criteria for a story, for example. And I'm specifically thinking of if something comes from a product manager and I'm an engineer, I'm a designer, I'm a writer or whatsoever, how do I flag, for example, a story that is missing the, let's say, the research that's needed or when I think the problem statement is not clear yet, when I think we still need to define better whatever it is to target audience or test something before going into build, like how would that fit the idea process? Yeah, I see two levels here. One is the acceptance criteria for the tickets and then also the point to raise or to challenge those. And if we start with the first one, so for that in Scrum or in some HR methodologies, you have the definition of ready. And the definition of ready contains actually all the information that a task, a ticket or epic, based on how deep you go with the definition of ready, needs to contain so that the team says, this is something that we see as ready for development. And that could be things like having this information in place, like acceptance criteria, description, measurement criteria. Plus on top of that, for example, a valid estimation of story points, a clear business value attached to it, and a possible release date, for example, could be a good indicator by saying, hey, this is the definition of ready and this is what we want to go with. And at the same time, before you can make a ticket ready, you need to groom it with your team. And the grooming sessions are usually the part where also you as team should challenge the product manager or each other on technical things you want to do or business related things you want to do that are on your roadmap to really go through it. If you did not manage to succeed there, you still have another chance, which would be according to Scrum in the spring planning, where you could one more time challenge the priority or discuss the priority, work it out together. I'm now going a little bit into the extreme between product and engineering, but I, again, see this as whole, so it should be rather discussed together. Nice. I think we would definitely go out of scope for this session if we would touch on all the details, because I think like simply down to estimations, story points, t-shirt sizes, all the sort of things you have down to like, when do you groom and so on. There is definitely a lot of stuff, but one thing that I would still discuss with you today would be like as a product manager, if you start with a new team, like how would you approach the backlog in that case, like greenfield fresh from scratch? So two things when it comes to the scope of this episode, I just want to say, I wrote an article called User Stories and Epics for the Win, which I will link in the description, as well as a backlog management email course you can try out, which is for free. It's five sessions where you get even more information and further reads to master backlog management and improve your skills there. To go back to your question, how to approach a new backlog. I'm a big fan of being very radical and straightforward when I start with a new team. And I just see this currently with a company I'm working with because there's a new product lead I used to work with. And he took over one of the teams that I'm coaching at the moment. So I handed all over to him and he said, Christian, the first thing I would like to do, because it's a very technical backlog and pretty much driven by the engineers by now, he said, Christian, I'm very likely about to close 80% of the tickets and make a fresh start. And as crazy as it sounds, in my opinion, I'm a big fan of doing so. But we also both knew at that moment he wants to do that, that it will eventually get some resistance from the team, which is fine. Of course. The question is now, how do you sell it? Because the team had a velocity of 10 story points. They had, I don't know, 200 or 300 story points in their backlog. And the first thing we did in the session where we're explaining the future plans, we're saying, Hey guys, no matter how fast you work, your backlog will be empty, just empty, not filled up with new tickets by end of 2136 or something like that. And they realized, okay, we're really not going to work on those topics. And we said, we're going to close those tickets. Closing doesn't mean delete. So we have an archive of it. We have a link you can always check. And whenever something pops up, you can just reopen it again. We want to have a very clean backlog to make a fresh start and really focus on the most important priorities that are on our table now. My recommendation is for sure, don't close anything that is promised to customer, et cetera, but making the cleanup and making a fresh start is to me always the best way to kick it off. Moving forward from there, having a clean backlog, it sounds like a dream, but I think like the more you, the longer the backlog also lifts, the fuller it will get again. And I think you will end up again, not having 200 tickets in simply there because every time someone requests something, it lands there and is never being touched. When do you, let's say, clean up again your backlog? Everyone does it different. There are people who really manage to continuously keep it as clean as possible. There are some people who let it completely go and just only work with filters and Jira to not see all the thousands of tickets. I'm like in between. I'm always aiming for having two to three sprints prepared up front at the very least one sprint already completely refined and ready for development for sure with the ability to switch priorities. And other than that, like two more sprints to look out in the future. At some point you're stacking up new tickets, et cetera. And I'm always saying everything that is older than three months, I'm going to close from on a monthly basis. So that means you always have, but this means you allow people to still add like new tasks, tickets, stories, but if they are not being touched for a while, you just close them up. Because for me, like one thing that I wanted to ask you is for example, if you're not going to be able to work on something where something is like such low priority compared to everything else that is on your table and on your roadmap, would you even allow it to end up on the backlog? Or would you simply be like, okay, let's talk again next year? That really depends on the processes you have within the company and you have defined as a team. In some companies, stakeholders are allowed or even supposed to create tickets in your backlog and in some don't. So not easy to say, but I'm always the kind of guy who likes direct communication with people. So I rather try to understand what they want instead of just seeing a ticket in the backlog. It depends on how you structure your processes. In case you want to have a process, inform your stakeholder and tell them that they have to fill out a ticket and make some fields mandatory that you get the information you want to have it at least clean when other people produce something from the outside. But overall, yeah, I would still allow people to put stuff in my backlog, but I'm always a big fan when someone drops a message in Slack or ideally in a team channel that everyone sees it. Yeah, cool. Makes a lot of sense. Christian, thanks a lot for the conversation. I think there's a lot of things that we can all constantly learn and improve also in the way we manage our backlogs and the way we write our stories and epics. So if there's nothing that you would want to add at this point, I see you shaking your head. All good, I'm fine. Perfect. It was a smooth teaser today, I would say. Yeah. Then with that, thank you all for listening in as well. Feel free to drop us your feedback through all our channels that we have available for you. Exactly. Check out the link description to get all the freebies and material that Christian worked on in his past months. And yeah, happy to answer also to individual questions on our website directly. Simply use the comment function and we will get to you as soon as possible. With that said... Thank you very much, Alex, and have a good evening. Bye, Christian. Have a good night.