Transcript
Hey Suzanne, good to see you. I try that pop out chat thing again. See if it works now that we're live. It went blank. So, [snorts] >> there's a whole new version three of Crowdcast, but I didn't think it was wise to submit to update to it right before we did did this. So, >> you're going live in 10 minutes. Would you like to apply this update? >> Yeah, I was like, nah, >> I've loosened up on that. You know, all my years of traveling, I always had a no installs rule when I was on the road. Um, and then finally just screw it and turned on the, you know, Apple auto install everything. So, >> I'm pretty yolo when software updates. >> Yeah, I'm pretty yolo with software updates. I mean, I'm, you know, I'm like I'm like on WWDC keynote day installing beta one of the next OS and half the stuff is like literally crashes on launch. Um, but >> pause for a minute, Tim. I'm downloading it. >> Yeah, exactly. Uh, >> Martina, you probably need to hit mute or something like that. It sounds like everyone else can hear us and stuff. Everything looks fine on our end, so presumably that's uh something you can adjust. [clears throat] >> Yeah, I think it I think it's working. Hi Ryan. Hi Moan Raj. Tracy, >> we'll start in Is it going well? There a couple. So, so >> this is uh you guys are here for >> being here >> the first time we're doing this particular live event. This is a brand new one. So, you get to uh experience that. Some of you may have done the user stories one that we've done several times, many times now at this point over the years. So, this is something brand new. >> You just made me nervous, Hunter. I wasn't even thinking about the fact that this was all new. I'm so used I'm so used to it kind of being the same uh the same webinar or two that we do and this this one is new. You're right. 100% new. >> Well, fortunately it's a topic that uh I think you're somewhat familiar with. So, >> um yeah, I've uh kind of been doing refinement for a long time. So, >> welcome all. >> Oh, Suzanne, you're on to something new. Hopefully that's going well. Hi, Keith. Good to see you. Hey, Robin. Hi, Audi Tune. Hey, Rita. I played chess on chess.com and I just played somebody from South Africa. One of the fun things on chess.com is it gives you um I think they call it your passport and it's like it shows you all the places where you've played people. So, um, and I just played somebody from South Africa, so I got to add that flag to my to my chest passport. So, >> glad you like the user stories webinar, Suzanne. I think we're going to be running another one here pretty soon. So, we'll announce that on the website and uh, if there's someone else you want to recommend it to, that will be their chance. >> That's actually going to be the last time we do that webinar. We're going to retire that uh, better user stories webinar. So, we're going to do it in a couple weeks. So, >> that's the plan. >> Wow, Suzanne, that's a lot. Sorry to hear that. Hey, Marian. >> Um, oh, you know what? Let me uh >> you're right, Angie. We um Angie's asking about the show. So, Angie probably found us on YouTube and is like, "What's going on here?" Um because we are simal casting it. U we are Let's see what's the best way to get you this. Um, the main the main event here is on the Crowdcast platform. Um, I wonder if I can add a link without breaking stuff. I don't know if I can [laughter] or not. >> You just said you're a YOLO guy. So, let's let's see if Hunter breaks everything. >> Well, hi everybody. >> Can I Oh, I can edit the description. Okay. Um, use for chat. Okay, there we go. I'm adding that to the YouTube description. Um, so Angie, I presume you can hear and see the video because you're on YouTube. Um, you might need to refresh the page to see the description update, but I put the link in to where all the people are chatting. So hopefully that helps. >> Well, well, thanks uh Suzanne and good luck with the search. So >> Scrum Foundation's AI learning. Great Suzanne. We appreciate that you um that you are appreciating the AI stuff. Um, you know, obviously it's an area of interest for a lot of folks, but we're always curious to get feedback on uh what you're getting out of it, if at whether we're trying to reach people at the right level, whether it's too advanced, too simple, what's something in the middle. So, we love that kind of feedback. Please keep it coming. >> And um Hunter just got us into the open AI app store, right? So, our apps in there. We do have an app for chat GPT that's available in there. Um still working to get it listed in the claude listing. Um and then for this is maybe a little in the weeds, but for um folks that want to do this, you know, you you can sign up for the Mountain Goat um AI toolkit, which is part of our our free MGS essentials package. There's a page inside of the toolkit uh website which um explains how to connect the tools to if you have a thirdparty chatbot not chat jp or claude um that as long as it supports the mp mcp excuse me spec um you can connect it there too. So there are some instructions that I added so that folks could go through that there's a couple of pieces of information you need to be able to hook them up. So, uh, maybe a little bit more of an advanced thing, but if you're using something else like, um, C-pilot, etc., uh, and you want to use those tools, you can do that. >> That's a a good tiein with what we're talking about today. One of the things we've added into our AI toolkit is a um a story critic. So, you can give it a user story and it will tell job story, whatever it is, and it'll tell you um kind of how well written the story is, whether it's um kind of been refined, ready for refinement, ready for development. it kind of looks at it from that perspective. So, um, kind of germaine to today's topic. So, thought I'd mention that. So, Manon, >> I would love to get to South Africa sometime, Stephanie. I looked at it one time and it's like I go to to London occasionally. I haven't recently, but I'd go there occasionally for work. And um then I looked at like, oh, what would it take to get down to like South Africa? It's like a whole another equivalent trip. >> My my wife went with her family um a few couple of your parents a couple of years ago and yeah, they flew from LA to Heathro to South Africa and like Heathro was not even halfway, right? It was like very far. [laughter] It's a it's a perception thing on when you look at like a globe. It's like going around seems farther than going down, right? So, but you know, I guess the world's as big down as it is around. So, so >> she loved it though. She said it was an amazing experience. So, >> Joanna in Copenhagen. Nice to see you here. Hey, Crystal. >> Hey, Butch. Denver, my former hometown. Casey as well. though >> coming up on our showtime here in moments. >> Thank you Neil and Boston. I'm watching the um Ken Burns American Revolution documentary and it's like thank you Boston for starting us. >> So uh oh Deborah doesn't have audio. Probably a mute thing. So we are definitely sending audio which you can't hear if uh you can't hear us say that if you don't have audio. Um, may need to unmute. Mike, are you just about ready? Looks like we are um seconds away. 3 2 1 kind of go situation. >> Let's go ahead and do it then. >> Bring that up. Make sure we got that. Hi everybody. I am Mike Con. Thanks for joining me here today. Um, we're going to talk about product backlog refinement and specifically why it feels heavier and less effective than it should. Teams spend a lot of time doing refinement, but they still get to the sprint with stories that are too big or too vague or still with important unknowns left in them. And in this webinar, I want to show you the five biggest traps behind that and what you can do instead. But first, I want to make sure this is the right webinar for you. You're in the right place if refinement feels long, but your team still doesn't feel ready. You're also in the right place if stories reach the sprint too big, too vague, or too risky. And you're in the right place if your team tries to answer every question before they're willing to start work on that story. Or perhaps refinement conversations drift into design instead of discussions of readiness of the story. And you're in the right place if you want a better way to know when an item is refined enough. Finally, you're in the right place if you want to coach others, especially your teammates, on backlog refinement with more confidence. Here's what I want to give you today. I want to show you the five traps that make refinement less effective. I want to help you know when an item is ready enough. I want to show you how to avoid both overrefining and underrefining. I want to show you how to keep refinement focused on readiness and I want to give you language and ideas that you can use to coach others with more confidence. I've got about 25 minutes planned for what I want to share and then I'm going to stay on and we'll take questions about refinement, user stories, any of those type of topics. I'm joined today by Hunter Hilligos, CTO of Mountain Goat Software. And Hunter is going to quickly explain just how to submit questions here, then we'll jump right in. Hello all, thanks for being here. Um, yes, as Mike mentioned, uh, we're happy to take your questions. You should see a submit a question button below the video here on Crowdcast. Um, if you're watching the YouTube Simoc cast, please follow the link there in the description. You can use that as well. Um, please do submit your questions using that system. They go into our queue versus just putting them into the chat where we might lose track of them or not realize that they're meant for Mike and not for your uh, fellow attendees. Um, let's see. As Mike mentioned, topic-wise, you know, this is a refinement event, so questions on refinement are great. Um, if you've got something that jogs a little bit more into user stories, that's probably fine, too. Uh, meaning of life questions uh maybe save for the next uh webinar. Um, one last note on submitting questions. We always appreciate uh difficult questions. Don't shy away from those, but sometimes um if there's too much detail in a question, it can be very hard to follow. So, if you wouldn't mind cutting those down as much as you can, that always helps. And with that, um, I will pass it back to you, Mike. Perfect. Thank you, Hunter. I see everybody saying hello in the chat. I just want to, um, say hello back and say that I appreciate you joining us here today. These are always fun to do. I want to make this concrete with a story about a team that I worked with. They were spending a lot of time in backlog refinement, but they weren't getting a lot of value from it. Their refinement meeting meetings were long, but stories still entered the sprint bigger or messier than teammates expected and the team never really felt like they were getting ahead. It was constant struggle just to stay current on backlog refinement. What was interesting was that no one thought the problem was refinement itself. It was refinement itself. In fact, they thought they needed more refinement. But that wasn't the problem. The real problem was that they were refining with the wrong goal. They were trying to drive uncertainty to zero. They were spending too much time on items that were still too far away from implementation, things that weren't going to be done for perhaps months. And their conversations kept drifting into design details instead of staying focused on whether the work was actually ready enough. So, we changed a few things on this team. We focused refinement on just the top of the backlog instead of trying to detail everything. And we used a simpler standard for refinement. That standard was, is this item clear enough, small enough, and understood well enough that it can fit into an upcoming sprint. And we stopped treating refinement as the place to finish design. That changed a lot of things. Their refinement sessions got shorter. Stories came into the sprint smaller and clearer. The team had fewer mid-sprint surprises. And perhaps most importantly, they stopped feeling like they had to solve everything before they could begin. They started this sprint with more confidence because refinement was finally doing its real job. That team improved by spending less time on refinement. Not more less time on refinement, but by getting much clearer on what refinement was actually about. That's the key point I want to start with here, too. Before we look at the traps, let's get clear on the real purpose of product backlog refinement. Product backlog refinement is about getting existing backlog items ready enough for an upcoming sprint. It's not broad ideation. It's not design and it's not an effort to answer every possible question before work begins. The real question in refinement is simple. Do we know enough about this item that it can probably fit into an upcoming sprint? The team doesn't need to know everything. They need to know just enough. And once a team loses sight of that refinement starts getting heavier and less effective than it should be. So let's look at the first trap. But before I go into the first trap, the five traps, let me ask you a quick question. Think about your last one or two sprints. When when refinement felt heavier than it should, what was usually the biggest reason? Please answer the question. Please choose the answer that best fits your team. And Hunter, I'm going to look down in a second. It's probably already open the poll here, so I'll give you few seconds to vote on that. Yeah, poll is open. I >> think this was meant to be a skinny slide. Unless your message, the word of the day is hidden. >> [laughter] >> Oh, is one of >> Yeah, it's fine >> on my slide. I screwed up. >> Uh, it's It looks like it's just the wrong orientation. You're We're seeing the the part. Not Not a problem. >> I'm supposed to be on this. >> There we go. >> Yeah. Yeah. We do something cool in the slides. I I have the slides um with um only like half of the slide visible and then the left side is masked out to have me bigger on the screen. So, So, um, I lost the screen with the answers here. What was the winning answer, Hunter? >> Uh, well, let's see if we ready to close this off. Let's share the results with the folks. It looks like the winning answer so far is uh we drifted into design or solution details with about 53%. Oh, and it's changing a little bit, but but it's still by far the winner. >> Yeah. Yeah. Drifting into design details, that's not surprising. um teams have this feeling that they have to solve everything and that is not what we want to do in refinement. It's good to leave refinement with some things still open and that those issues can be resolved during the sprint. So not surprised to to see that as a winner. So what I like about this question is that the answers there all point to the same bigger issue. Refinement has drifted away from readiness. Instead of asking, "Do we know enough to begin responsibly?" Teams start doing something heavier. They start refining too far ahead or solving design too early or trying to eliminate every unknown and they leave the conversation to too few people. Right? This is going to lead us right into the five traps. So, let's talk about these. The first trap is treating refinement solely as a meeting. A lot of teams do a refinement meeting every week or once per sprint. The problem with this is that everything gets saved up for that meeting. Questions pile up, unknowns pile up, dependencies pile up, and then the meeting becomes overloaded. That usually leads to two bad outcomes. Either the meeting becomes long and exhausting or important questions spill forward until the team is dealing with them later than they should. Good refinement. Good refinement works better as an ongoing process. Some of it can happen in a scheduled meeting, absolutely, but some of it can happen in small conversations during the sprint. Some of it can happen when a product owner clears up something with one or two team members before the big discussion. Not everybody needs to be involved in every discussion, right? So, it could be a product owner talking to one or two people about how something might work. The point is that refinement should be something that happens continually rather than forced to fit into one meeting. The second trap is refining too much of the backlog. Teams often act as if every backlog item deserves the same level of detail. So work the team might consider next week gets the same attention as work they may not touch for months. It's a mistake. Near-term items need more clarity. Farther out items usually need much less. The farther down a backlog item is, the more likely it is to change, to move, to merge, to to split, or even disappear, right? Gets canceled by the product owner. So, when teams put a lot of effort into deeply refining lower priority items, they're often creating detail that won't survive long enough to matter. The job of refinement is not to make the whole backlog equally clear. The job is to make the right items clear enough at the right time. I'm going to repeat that actually. The job of refinement is to make the right items clear enough at the right time. That's a much better standard. Top items need more detail because they're closer to implementation. Lower items need just enough detail to preserve the idea and the intent. I get a good example of this. Think about the travel website Orbits, right? Book trips on the website. On the early Orbits travel website, you could book flights, hotels, and rental cars. You could not book a cabin on a cruise ship. I bet someone had that idea, though. They probably thought of it the day they incorporated the business. But if that was on the backlog at all, one sentence was enough. Allow users to book cabins on cruise ships. That item didn't need detail until it moved closer to implementation. And I think for orbits, it took probably 15 or 20 years before they added support for cruise ships, right? So detailing that out way earlier would have been a complete waste of time. The third trap is refining to certainty. This is the biggest trap of all. Teams often behave as if refinement is successful only when every open question has been answered. But that's not the goal. The goal of refinement is confidence, not certainty. One team I worked with had a backlog item that they brought into three separate refinement meetings. Right? The first time they talked through the main scope, thought they were close, but they didn't feel ready to bring it into the sprint. So rolled into the second sprint. In the second time that item was in refinement, someone brought up an edge case they wanted resolved before they felt comfortable starting. So the item wasn't ready for that sprint either. The third sprint, some team members felt they needed to talk through implementation details because people still weren't comfortable getting started on that. In the end, this item was stalled for three sprints. These were important enough issues, but they were not important enough that we should have kept the thing out of the sprint. Bring it into the sprint, figured out during the sprint, this item was probably ready enough after the first refinement meeting. The team kept treating open questions as a reason to delay instead of as normal uncertainty they could handle during the work. Once this team changed refinement from asking what else do we possibly need to know to do we know enough to begin responsibly the meetings got shorter and more productive. the team could move forward, learn what they needed while doing the work, and stop treating every open question as a blocker. What better way to learn the answers to your open questions than by getting started on the work. And this is the trap. Teams think they're being careful, but they're often just chasing certainty. It's a very different standard. If a team tries to remove every unknown before starting work, refinement becomes endless. And you've probably been in these type of refinement sessions. The meetings get longer. Energy drops in those meetings. People start debating low probability scenarios and edge cases that may never matter. Despite all that effort, uncertainty still shows up during the sprint anyway because it's normal to have some amount of uncertainty. Agile teams learn best while doing the work. So when you're refining an item, the question is not do we know everything. Don't ask that. It's have we removed sprint threatening unknowns. If the item is small enough, clear enough, and understood well enough that the team believes it can likely finish the item in the sprint, that's enough. Good refinement removes the uncertainty that could threaten the sprint. It does not try to eliminate uncertainty. The fourth trap is turning refinement into design. Our poll winner from a few minutes ago. This is one of the easiest ways for a useful refinement session become a draining session. Teams start with a backlog item, but the conversation quickly turns into architecture, UI decisions, test design, database design, or a long discussion about implementation details. Some design thinking is normal. You can't completely separate product clarity from solution ideas. But refinement shouldn't become the place where the team tries to finish the design before work begins. The purpose of refinement is to clarify scope, surface unknowns, and build shared understanding. It's not to fully solve all those. So when refinement gets due too detailed, too implementationheavy or too polished, that's usually a sign the team has gone too far. A good way to think about this is this refinement should clarify scope. It shouldn't finish the design. I'm showing here what of what this often looks like in practice. The four common problems I've got on the screen here are tasks disguised as stories, vague so that clauses, too much solutioning, and stories that are still too large. Too much solutioning is the one I want to emphasize because when refinement becomes a design meeting, it usually stops being a readiness conversation. Instead of asking, do we understand enough to move forward? The team starts asking can we solve every detail right now? it's a different conversation and it usually pulls the team into depth before they need depth. The other warning sign I'd call out is stories that are still too large. A lot of teams mistake a longer conversation as better refinement. But if the story is still too large after all that conversation, then the team didn't get the result they actually needed. So these four items on the screen here are really a diagnostic. If refinement feels heavy, slow or unsatisfying, ask whether the team is doing one of these things instead of actual refinement. In many cases, the team is working hard but not toward the right outcome. The fifth trap is treating refinement as the product owner's job. A product owner can absolutely do prep work before refinement. We want them to. But refinement works best when the people who will build the work help shape the understanding of it. If refinement becomes the product owner presenting already prepared items to the team, the conversation gets weaker. Risks show up later rather than earlier. Important assumptions go unchallenged and the team misses the shared understanding that refinement is supposed to create. The product owner should absolutely bring clarity to the problem, the value, and the priorities. But developers need to help expose missing information, technical risks, dependencies, and size concerns. That back and forth is what makes refinement useful. It's meant to be a conversation, a dialogue. One place this often shows up is around acceptance criteria. The product owner is responsible for the acceptance criteria. But teams get into trouble when they expect the product owner to also turn those acceptance criteria into detailed test cases or implementation guidance. That work belongs with the team. So the product owner defines the acceptance criteria. The team turns those into the actual test cases. So the product owner defines what must be true for the story to be accepted. The team figures out how to verify that and how to build it. Let's look at an example. Product owner might say a shopper can pay with a credit card. Little user story or acceptance criteria. A shopper can pay with a credit card. That's acceptance criteria. The team then turns that into test cases such as what happens if the card is declined, what happens if the expiration date is invalid, and what the user sees when payment succeeds. So refinement should not feel like one person is showing up with completed homework. It should feel like the team building a shared understanding collaboratively. That's how items get truly ready. Not because one person thought through them alone, but because the right people helped shape them before and while before the sprint began and then during the sprint. So let me pull all that together. Good refinement does not mean refining everything, refining all at once or refining until uncertainty disappears. Good refinement g means giving near-term items the level of clarity they need when they need it means treating refinement as an ongoing process. Focusing on readiness rather than completeness out of unnecessary design detail and building shared understanding collaboratively. That's really the whole game. If a team gets those things right, refinement starts to feel lighter. Work enters the sprint smaller and clearer and the team begins with more confidence because they're no longer trying to solve everything too soon. See something that said the slide didn't move. So before I move on, I want to ask you one more quick question. Now that you've heard these five traps, think again about your last one or two sprints. Just the last one or two. When did your team usually stop refining an item? Please click the answer that's most true most of the time. >> All right, the poll's up. For those folks that [clears throat] um weren't totally clear last time, the poll there's you see the arrow there in Mike's slide screenshot that's indicating what the poll uh mode is. So that's um that if you can't find it, that's what you're looking for. Should be under your chat uh right there on the sidebar of the CrowdCast UI. What's your answer, Hunter? >> Yes. Yes. [laughter] >> Looks like we got people voting now. Give them a few. Is it >> We'll wait a few seconds here for the poll to finish >> and then we'll share the results. This one's closer than the last one. Well, I I'll I'll leave you in suspense for a few more seconds here, but this one's pretty close. >> Do you get to see the results before we do? Cuz I don't get to see the results yet. So, >> yeah, I'm special. >> You are special. So, Pablo, which kind of materials will be available after the meeting's over? um you'll have um access to a recording of this and we also have um a sketch note being made of this. So you'll have a sketch note of the the session to help you with notes from it. So >> all right, you guys ready to see some results? >> I'm ready. >> All right, here we go. Looks like people are still voting, but you can still do that. Here's where we are so far. when nearly everything had been answered is the winner. Not massively, but by 10% or so. Um, >> yeah, the entire time. >> So, the video quality is really bad, buffering every few seconds. Um, >> I'm watching a feed on another computer and it seems fine. So, um, >> our stream sets are fine and real strong. I posted a link to our YouTube simocast in the chat. You might have to scroll up a little bit. um but you can find the link there >> um and that might work better for you. >> So let's talk about the poll here. So the winner was when nearly everything has been answered. That result doesn't surprise me at all. A lot of teams are still using certainty as their stopping rule. But that's exactly what makes refinement heavier than it needs to be. The goal is not to remove every unknown, right? The goal is to have enough confidence to begin responsibly. And that's exactly why diagnosis matters. One reason refinement is tricky is that these problems are observable, but they're not always obvious from inside the team. And that last pull's a good example of why a team can think we're refining well and still be overrefining, underrefining, or doing it in the wrong way. That's why the first step is to diagnose what's actually happening. Earlier in this webinar, we've had these two survey questions. Those are the same kind of questions I'd encourage you to discuss as a team based on what actually happened in your last one or two sprints. In fact, to make that easier, we've created a refinement team checklist that you can use in a retrospective with your team. It's built around questions like these, and it's designed to help you identify one improvement at a time to try in your next sprint. So, here's what I'd encourage you to do. Download the refinement team check. We're going to send you a link to that. um in an email shortly after we wrap up and use that in your next retrospective with the rest of the team. Work through it together based on what actually happened in your last one or two sprints. Don't try to fix everything at once. Use the checklist to identify one improvement to try before the next retrospective. And that's how we've designed this retros this refinement team check to be used. So don't just download it, use it as well. It should give you the guidance you need to fix most backlog refinement issues. One of the things we wanted to do with this backlog refinement checklist is base it on what you experienced in the last one or two sprints. I made a first draft of this based on like, you know, how do you feel your team is doing it this? How do you feel your team is doing it that? And I didn't feel like we were getting good results from some tests with that version of the checklist. And so we made it much more practical by focusing on exactly what happened in the last one or two sprints. Not, you know, do you think you're refining to the right level of clarity? No. The questions are very specific about the last one or two sprints. But after you try this checklist, if you'd like even more help improving your team's refinement process, we can help. Email me at mike mountain software or reply to one of the confirmation emails that we sent from the webinar and we can help you out. So, with that, let's open this up for Q&A. I do want to reiterate that we've um had a sketch note made of this session and we'll send you a copy of that today. Hunter, I think our emails go out in an hour or two or when when do we when are we sending? >> Yeah. So, this is good to clarify since um people uh are probably going to ask especially this is the first time we've done it this way. So, um, at about noon Pacific, so depends on when we wrap, give or take an hour after we're done, right? If we're on hour and a half from now. >> Yeah. Basically, and you're going to get an email. It's going to include three important pieces of information. One is the replay. I know some people have asked about that. Um, two is the link to the sketch note. So, that PDF will be linked there. And three is the um, refinement PDF that Mike mentioned a minute ago. So, three important things in that email that's coming to everybody that registered automatically uh shortly after we're done about, you know, about noon Pacific time today, whatever that is in your time zone. >> Yep. So, about an hour and a half from that's all free. We're, you know, there's no um cost of those things. We're just stuff we're sending out to to help with refinement. Um so, um what questions do you have about product backlog refinement? I'm happy to take questions about any of the five traps or how to know when a story is ready enough, how much detail is enough, or even what good refinement looks like in practice. Hunter, I can see a lot scrolling by. Um, why don't you pick one of our questions and get us started with the Q&A. >> All right, let's do it. Uh thanks everybody for submitting and um if you haven't been with us before uh and done one of these I'm going to be going through this queue. Uh and so um sometimes I group questions together uh if you you may see your question earlier or later than you expect depending on that. So that's normal. Um they're they're in the queue here and we'll get to just as many as we can. So let's start. The first one is um from Phil who asks, "I'm wondering if there may be times when the team may want to assign a backlog item to a sprint in order to allocate the research time to actually ready that backlog item for a future sprint." >> Yeah, I think that's fine, Phil. I mean, if you you know, often a team will refer to that as a spike. Um a spike is an agile term for a learning activity. And um if uh you we want to learn something um it's fair to put that learning activity in sprint five so that we can do the work in sprint six or that we can or that we can evaluate like maybe we learned that this thing is huge and we don't want to do it at all but yeah it's fine to put the the learning activity into a sprint. >> All right Scott is going to be next and Scott asks what do we tell POS? >> Can you wait one second Hunter? >> Um AMA has got a question in the chat. if you can put it into the actual question queue otherwise they're going to scroll out and we don't get to >> to see them. So, um, in the same forum. So, um, >> question are going to scroll by. >> Submit a question button. Please do use that if you'd like, Mike, to try to answer it, um, in the chat. >> I'd love to answer them. I just can't if they if they scroll out of out of view. >> Alrighty, Scott's question. What do we tell POS that say, "What is my job if the developers can ask questions directly to users?" I thought that was my job to help the developers understand what our users are asking for. >> Yeah, it's a great question, Scott. don't want to um you know it's never good to to funnel everything through one person and say this type of person can't talk to that other type of person developers can't talk to users I I think the product owner's job is to help um understand those answers interpret the answers know what users to talk to know that this one user always overemphasizes a a certain type of feature um and so the product owner can guide who the developers talk to, right? You know, when you have questions about this, go talk to this user or we're building this feature directly for that user, go talk to that user. Um, but the product owner's job is bigger than a conversation with just one user. Their job is to represent the the mass of user, right? The the conglomerate users and to interpret those and the smaller details that a developer gets from a conversation like that, that's I mean, that's fine. And that's not that's you know product owner could be there for those conversations. Prod have them. But a good agile team is going too quickly for the product owner to have all those conversations personally. All right. Holl's up next. Who should be in backlog grooming refinement? One of the things I struggle with is some of my team finds backlog grooming a waste of their time. How do I focus the meeting so it's useful to everyone? >> Great, Holly. Let's talk about the term um uh grooming for a second because that was actually my term. I grew up in Southern California um in honey a city called Huntington Beach, California. Huntington Beach's nickname is Surf City, USA. And so I grew up in Surf City, USA. So guess what was on the morning radio? The Surf Report. I later moved to uh Boulder, Colorado. And when I moved to Boulder, Colorado, uh nice snowy ski town, no morning surf report. Boulder radio would have the morning snow report, the ski report, and the morning ski report would say things like, um, 30 inches of groomed, packed powder at Aspen, right? One of the ski resorts. 30 ines of groomed, packed powder. I remember driving to work one day, like, what does that mean? What is groomed powder? I had no idea what it meant. To me, grooming was back when I had hair, right? And it meant combing my hair. I was grooming. And so I got to work and I uh opened up an online dictionary and searched for groomed. What did it mean? And it meant to put something into a nice shape. And I thought, "Oh, this is perfect for how I think of a backlog." Because I think of a backlog as having like small things at the top, medium things, bigger things below there. It's got a shape. I called it grooming. Well, I didn't know that grooming also meant kind of, you know, bad things, right? grooming had some bad connotations that um maybe it was just my my my isolated world but I wasn't aware of them back in the early 2000s um but I don't think they were as used but uh you know grooming definitely used with some negative connotations so the world shift away from grooming to calling it refinement so I just wanted to comment on that part so Holly's question is um teams finding this a waste of time I've got a good answer for this Holly I don't think your entire team needs to be in backlog refine refinement meetings. [snorts] Um, a lot of people disagree with me on that. I just don't think it's it's necessary. Here's why. Suppose you got an eight person team. We get eight people. They show up for backlog refinement meeting with the product owner and um we're going to think of a set of questions. We're going to think of this many questions. If we have five of the people there, let's just go with like a little over half. If we have five of the people, we're not going to think of this many questions. We're going to think of this many. I did shrink my hands a little bit, right? Not much. We're going to think of most of the questions with five people there. Great. We thought of most of the questions and we probably thought of all the hard questions, the important ones. We don't need everybody there. So, don't I don't think it's necessary to have every person at every refinement meeting. Um, the other thing, Holly, is refinement is a meeting that is meant to speed things up down the road. So, yeah, it's it's a meeting. It's painful. I don't like being in meetings, but um, you know, if we can have a 1-hour meeting now and it saves us uh 3 hours, 5 hours, 10 hours of mistakes later, it was worth it, right? So that's how I convinced Team Sol. >> Natalyia is next. Um, and thank you guys for submitting your questions. Got a lot of them in here now. What is going on here? Sorry. Um, my button stopped working. Oh no. >> You want me to pick one? >> Uh, I can read it. It's just for some reason the something has gone sideways. Um, I'll read it. Uh, from this is from Natalyia. What if the team is so rich on ideas and questions that we often end up talking for more than one hour, although only 30 minutes were planned? We have two to three refinements per week, 30 minutes each. Um, Natalya, ignore refinement meetings for a second. If you have any meeting that um goes longer than you expect routinely, you want to change your schedule for that meeting, right? I mean, you know, you're having a you know, let's say you scheduled um I'm just going to be ridiculous. So, say you scheduled four hours for backlog ret or for retrospectives and you find your retrospectives need six hours. Again, I'm being ridiculous so nobody quotes me on a number. Um, start scheduling six-hour meetings, right? So, if your meetings are are not scheduled for long enough, start scheduling longer. Um, a lot of teams have kind of an internal struggle between somebody who prefers more shorter meetings. Andre, I'm going to ask you your preference in a second unless you're busy on that tech. I'm trying to fix the questions. >> Some people, some some people on a team prefer more shorter meetings. Other prefer longer but fewer meetings. Hunter, I'm curious. What's your I should have asked you 10 years ago. I think I know your answer, but what's your preference? Fewer, longer or more shorter? >> Fewer, longer would be my personal preference. >> Yeah, I'm with you. Right. But you and I might be on a team with somebody else that prefers to, you know, I never want to go more than an hour or I never want to go more than 45 minutes. Let's do multiple of these. And so that's kind of an internal struggle, Natalya. in some teams. Um I think personally it sounds like you're doing too much refinement and so I think bringing it back to some of the questions that we've discussed here um would be helpful in terms of like you know do we know enough that we can reliably expect to finish this. Um some of those design discussions that you're having might be useful probably are useful but they probably don't need everybody. So I'd break out subsets. So, a good result for you might be a a 90-minute meeting once a week and to have a decision to have three follow-up meetings. Those three people talk about that those two talk about the other thing. >> David asks, "At what point in the story life cycle should technical or architectural details be solidified and does that happen in refinement or later conversations?" >> Good question, David. I think it depend I know it depends on how significant they are. If you're doing um an architectural dis decision that is going to completely influence like the whole system or a whole set of functionality, you want to make that decision or at least investigate that decision earlier on. So I balance it out with the impact it's going to have. One of the ways to think about this is to think about upfront thinking as equivalent to insurance. When you do upfront thinking, technical architectural discussions. When you do that upfront thinking, you're buying insurance. You're insuring yourself against future problems. You can overinsure, right? You know, you might have a technical decision that's got to be made and we choose the wrong one. We could reverse it. We could easily kind of change things. Um, wouldn't be a big deal if we had to change it. You know, cost us a little bit, but not a big deal. That doesn't warrant a whole lot of thought, right? You do some doesn't warrant a whole lot of thought. If instead you're doing something where wow you choose the wrong make the wrong decision you really screw yourself that deserves a lot of thought as an example Hunter has been investigate moving us to a different content management system I don't want to get that right right that's not you know that's not something that's easy to switch if we screw that up so um you know do the decision at the time justified by the impact of being wrong >> okay um let's see Leon is going to be next here. My question would be here we are discussing backlog items. Would everything discussed here be the same for stories, features and epics? >> Yeah, I think so, Leon. Um, in terms like if you have an epic, you know, it could come into refinement and be split, right? That might be the discussion of an epic. Um, for a smaller story, the discussion is going to be what are its acceptance criteria? And one of the key things to realize in agile, and I didn't realize this, I remember like when I realized this, it was kind of like an epiphany, is that acceptance criteria and substories are two of the same thing, right? You know, how do we know an epic is done well? When its substories are done, um I'm using epic to mean big story. How do we know when a big story is done when its sub stories are done? How do we know a story is done well when its acceptance criteria are done? So, acceptance criteria and subtories are really two sides of the same coin. So I think the discussion here today is relevant for both. >> Okay, Linda's [clears throat] next recommendations for getting those details once a story is refined uh meeting definition of ready. >> Um Linda, I think some of it is um easily done by the product owner on their own, right? Product owner may just, you know, know what they want. The product owner may to get an answer may need to go talk to uh some users. Talked about that being a product owner responsibility. um others could come out of a conversation with the team and that's the refinement meeting. So I think um I think you want to have a set of tools at a team's disposal for answering questions and use the right tool for the question. >> Okay. Uh Andrews next. Is it okay to refine as post standup items uh to reduce refinement meeting time? >> I think I follow that Andrew. So are you saying can we refine at the end of a stand-up meeting? Yeah, I think that's um I think that's very common. Um, one of the one of the ways I like to use a standup I like to use a stand-up meeting kind of as described. Everybody talks about, you know, kind of their their problems, their progress. And um then and their plans and then after that um I like to end it by saying, "Okay, Hunter, why don't you and I stay and talk about this? And Andrew, why don't you and George stay and talk about this other thing, right?" And so we'll break up into just kind of small follow-up discussions. And I think post standup refinement would be a good example of a time where you probably don't need everybody involved. >> Patrick asks, "How do how refined do compliance and security items with long time horizons need to be? For instance, your database is going end of life uh in uh March of 2027. >> Um how refined. Well, I I think this is um you know, I think it's the the same guidance that we've talked about. It's got to be refined enough that you feel reasonably confident that you know what's involved, right? So, and you know, if you've got things that are high risk, right? Compliance and security. That's back to my insurance analogy. And I know you put the question before the insurance analogy, Patrick, but um you know, you'd want to think about what's the risk of being wrong on these things and the risk of not meeting some compliance requirements. It's pretty big. So, I want to think about those earlier. So, I would expect those to have more detail earlier than how do we how are we letting people log into our system, right? >> All right. Mo wants to know um if they're too reliant on spikes. Some of my team want to refine the work items until everything is certain. As a result, a lot of what could be stories are turned into spikes. From the spikes, the developer who take who takes them makes more stories for the work. I know there's a place for spikes, but I feel we rely on them too much just because things aren't 100% defined. Am I wrong, >> Mo? My simple answer would be this. If if anybody is ever asking, are we doing too many spikes? The answer is almost certainly you are. Right. So, yes. Um that would be my default answer. And having heard your question, yes, you're doing too much. Um, I almost said this because the first question we had today was about spikes and I almost added a little comment there about, you know, don't overuse these. That's a common mistake. Your your team is overusing these. Spikes should be for removing um excessive uncertainty from things. I don't want to use a spike for removing garden variety normal uncertainty. Right? Anything your team starts, there's some uncertainty to it. And I don't want to use a spike for those. when he uses a spike for things they just like really blow up and you know this things would be twice as big or four times as big as we thought or we have no idea how to do this right Hunter would want to run a spike multi-print spike in fact to do uh to choose a content management system right we're not going to just you know pick that we're not going to assume in the sprint we're going to pick and move so use a spike when you have excessive unusual amounts of uncertainty not garden variety levels of uncertainty >> Sam asked asks, "Can you give some examples of vague so that statements that were related to trap 4?" >> Um, just did some I was using our story critic, the thing that I said in our AI toolkit. You can sign up for that at the on our website. Just sign up for the MGS essentials. Um, and it it kept critiquing stories that I thought were halfway decent. Um, by saying that I had vague so that causes. Um I I always have a hard time with like specific examples um in the middle of this when I'm thinking more generically about the topic. Um I think Sam it's just you know when you one of the ones I had was something I we were doing a as an experiment writing stories for a parking lot attendant product. Right. So um the and the idea was someone who owns uh land near hotels and they want to or events venues and they want to use their spaces um valet parking space and um some vague so that clauses for that were in the stories that were related to um uh you know so that I can file an insurance claim if there's a problem, right? um you know the car was damaged and so things like that that weren't very detailed. So I don't have really good examples for you Sam. I could probably come up with some uh maybe email me if you want. I'll try to find some of the ones that I had that were bad or toss them into the story critic and you'll probably see some of yours are not as not as clear as they they should be. I definitely saw that with stories that I was happy with personally until I put it into the story critic. >> Deborah asks, "What do you think about using AI to help refine backlog items?" just using the AI input as a place to start. >> I have been shocked, Deborah, at how good AI is at helping do this. Um, so I've mentioned the story critic earlier, just mentioned it now. Um, again in MGS essentials, I think it helps a lot. Um, I think even just generic chat GPT has worked well. I haven't tried this with quad. Um, but I'll go to chat GB and say, "Hey, you know, what would the acceptance criteria be for this?" But I would start with our story critic and we have that packaged as something you can do on our website. It's downloadable as a skill a skill that you can plug into um various uh um AIS and um also as Hunter mentioned is a a uh in MCP I guess it's I well I guess it's just a a app now right inside of the AI open AI store. Andrew, do you want to add anything on Yeah, add anything on that? >> Nope. That was a good answer. >> Scott asks, can you at least mention user stories? I see too many teams refine something big that results in user stories like I need to create a new new API and I need to do some analysis and I need to modify the database. So, they had good discussions and then created tasks. That's not the end result of refinement. >> Yeah, Scott, those are not good. um you want to you want to have stories that deliver or at least create value for users, right? And what you're doing here are tasks and these are important steps, right? I mean, you know, modify the database important thing. We got to do that thing, but that's not the thing that we're going to to deliver or that creates value for users. So, I would um I would encourage your team to have true user focused stories, not developer tasks. CJ asks, "I'm seeing several teams wait for design teams to fully complete designs and wireframes before pulling a story into a sprint. How should this type of work align with backlog refinement and sprint planning? Should stories only be considered ready after design is complete? Or is there an expectation that design and delivery overlap?" >> Well, I just saw Keith's comment about a co-pilot agent. Keith, that sounds cool. Um, co-pilot agent that takes long descriptions, breaks into smaller stories. Um CJ, the the waiting for design is one of the one of the common problems. Um I tend to think of designers on a team. That could be UX designers, technical designers, whomever. But I think of designers kind of like the headlights on a car. They are looking ahead, right? But it doesn't mean they need to finish their work, right? We don't need them to uh illuminate the entire road. We just need to see far enough ahead where we're going. I don't need to illuminate the whole path to my destination. And so the designers are working ahead, but they don't want to finish their work before we start. I sometimes think about um for me it was like the old high school or college track or you see it in the Olympics, right? You know, and you watch one of the one of the running events where they're all going to run around the track one time at 440 or whatever that is, run around one time or four times or something. Um, and you know, people start staggered, right? You know, you look at it and like the guy in the then the outside is like way in front, right? It's like, wow, that's not fair. Um, but you know, they're spaced out so that that person has to um, you know, they're going to finish about the same time if they're all the same speedr runners. And so that's what I want on a team. I want the designers to be like kind of starting ahead, but I want them to finish their work during the sprint. So they should be resolving the last little issues during the sprint. So, um, fully complete design during the sprint, partially complete design before the sprint. >> Scott asks, "Can you talk about the difference in the discussion, what's important, and documenting the results of refinement? I have Pas that refuse to create user stories because that's not their job," quote unquote. When I ask more about specifics, they focus in on the documenting of the results because that's how it's been written internally in our playbook, which is far too literal. Everyone participates in the discussion. Doesn't matter who documents the discussion. i.e. creates the stories in our tool. >> Um Scott, I don't think it matters who actually writes it down. I love the early days of agile when um you know, stories were written on um on cards, right? And I've got a big one here, but you know, when stories were written on little index cards because I could look at a team's backlog and I would notice if everything was in the same person's handwriting, right? Um and that would be a bad thing, right? You don't want to have one person writing all of the backlog items. And so, uh, what I used to do back then when we were doing these meetings, I'd bring in a stack of cards. I'd bring in some pens and I'd have cards and pens within hands, easy hands reach of every space at the table. And that way, anybody could just kind of pick one up. Or I would occasionally do something like, um, you know, darn my my my pen's out of ink. It wasn't, but I would just pretend it was. Darn, my pen's out of ink. Hunter, can you write that one down? And I would call on somebody who maybe hadn't contributed. in your case, perhaps the product owner, getting them to write that down while I reached into my backpack and dug out a pen and saved the Gwen because it was still working. Um, so I like having anybody write these, but I wouldn't fight it too hard if this is, you know, if your product owners are pushing back on this, you probably got bigger battles to push with a product owner um with that mindset. I don't like that mindset. Um, I I can't think of anytime I want somebody to say that's not my job. So, >> indeed. All right, let's see. Lou Quest Lou's question is, "How our organization practices safe and solutioning is done well before the development team sees user stories in refinement. How do you recommend running backlog refinement when solutions live mostly outside the scrum team?" >> Uh, one of many reasons I'm not a big safe fan, Lou. Um, I would, um, I would try to, if I'm on the team, I'd probably just accept it and get what I get. Um, if I have influence beyond the team to wherever the solutioning is happening, I'd probably get them to understand the benefits of working more um, iterative and incrementally where, you know, they're um, not having to provide us complete detail. They don't have to do everything way in advance. And then I'd probably try to find some opportunities as a team member, I'd try to find some opportunities to where I could encourage bringing something in that wasn't complete yet. Right? So if they hadn't finished all their work, but it seemed important, I'd say, "Hey, why don't we have the team start on that? We, you know, we may make a few mistakes, but you can finish it uh the design decisions during the sprint. Let's let's bring it in early." I'd probably look for opportunities to do that. Sam asks, "If a team wants to design solutions, is it okay to ask them to schedule a how meeting and allow the refinement to stay grounded in the what?" Absolutely. Absolutely, Sam. So, um, you know, in a in a typical refinement meeting, I don't if I want to say typical, probably in every refinement meeting I've been in, um, one of the outputs of that meeting would be why don't the three of you get together and take this further, right? And so, Sam, what you're describing is exactly that, right? So have that, you know, figure out who it's going to be and say, you know, Sam, why don't you schedule that meeting? You and the these two others go figure that out afterwards. We don't need to solve that in here. Patrick's next. When a team has a has devs of multiple skill levels and a mix of front end, back end, how do you gain consensus on understood well enough when you don't know who will pick up the card? >> Um, that's a good one, Patrick. Um I think understood well enough can be answered independent of who is going to do the work. Um you know certain people have more uh you know more experience and more skills um than than others but they can always rely on their teammates for for support I'd hope. Um, so it's really just really have we removed enough of the uncertainty, right? Have we resolved the big open issues, right? Um, it's fine to have small open issues. We, in fact, we want the small open issues. So, I would focus the qu maybe I'd find a way to rephrase the question, Patrick, with your team, um, around the idea of just, you know, have we removed the big uncertainties, right? >> Stephanie asks, "What is the sweet spot for when to have refinement? Our sprints are two weeks." Um, good one, Stephanie. I like to do refinement um two to three days before the end of the sprint. The reason I like to do that is um most things have happened during the sprint like new items have been invented already, right? We're we're close to the end. But doing it close to the end of the sprint then gives but not at the end, close to the end gives the product owner time to go get some answers. If one of the things in refinement is like, "Hey product owner, we need an answer to this." and the PO says like hm let me go think for a day or let me go ask the user committee uh it gives them a day or two to to get that answer so on a two week sprint I would do it on like day seven day eight >> all right um sort of related here throw this in some teams have refinement days or pre-booked slots some do it immediately after a design session what do you suggest >> I like the idea of having it pre-booked I mean you know you know every other Wednesday at 10:00 we do refinement or every other Wednesday at 3:00 we do refinement, something like that. I think that's a good idea. I'm a little concerned about doing it right after design. And here's why, Stephanie. Um I noticed this with teams that were doing this. What were they doing? It was um they were they were estimating their story. They were estimating their stories right before sprint planning. And here was the problem with that. They were in the room where they were going to do sprint planning. So their mindset was massive detail, sprint planning. And I didn't want them thinking in massive detail at the level of just putting rough guest story point values on things. And what happened is the teams that were doing that I noticed were taking longer than teams that separated those meetings. So I'd be concerned doing this right after design. Right? We're already way into this, you know, deep design, heavy thinking, detailed thinking. Um, and that might carry over into refinement, right? Our mindset is just there. If that's the best time to do the two meetings back toback, I'm fine with it. But I'd be aware of that design mindset. You might want to do some sort of, you know, exercise to just get people to kind of clear their minds. Okay, we're not going that deep anymore. Now we're just doing refinement. Remember that's this. >> Kevin asks, "How does your approach differ from using the the invest technique uh for a definition of ready?" >> Um Kevin, I don't think anything I said is um in disagreement with um the acronym invest. Um, you know, I still think those are valuable attributes. The thing that I see people do wrong with invest is take it as like, you know, hard and fast rules. Um, and not everything is going to be independent. Um, especially as we get down to the level of small backlogs, we are going to have dependencies between things. But those dependencies are all resolved in the next one sprint. So, it's not an issue. So, um, I think invest is great. I think it's meant to be a guideline, not some some big nasty rule. In terms of a definition of ready, I'm not a huge fan of a definition of ready. Um, in many cases, a lot of teams will use a definition of ready to be hard and fast rules. It cannot come into the sprint unless design is done, for example, would be part of a lot of teams definition of ready. And when we do that, we're setting up a stage gate. We're saying you cannot go into this next stage until you pass this gate. And this gate is all of this type of work is done. So if you're going to use the definition ready, have it be more guidelines, right? We're not going to bring anything in unless we've thought about design enough that we feel confident we can finish design during the sprint, right? While also doing the coding and testing. So use use the definition ready as more guidelines than hard and fast rules because that's kind of a step back towards a stagegate process. Tom asks, uh, our org has teams made up of people with a with that span multiple time zones across the world. Is there any reasonable way to refine items asynchronously? >> Um, I think so. You know, you can certainly have um uh we use a tool called ClickUp. I'm thinking about ClickUp. I could go into ClickUp and have a a discussion in there about what are the open issues about this and people could put in their open issues. Um, you may want to have um a session, Tom, that most people can meet because I think it'll be faster to just get on Zoom and resolve it than to have to type a bunch of stuff into a tool. So, I'd kind of prefer to do that. And, you know, we heard AI earlier. I'd use I'd [clears throat] use AI to help generate some of those open issues and see what the team thought the answers were. I wouldn't use AI to answer those open issues, but to identify them. Suzanne asks, "What does done really look like for a story when refining the scope and acceptance criteria?" >> Done for me is that we feel reasonably confident. I've used that phrase before, reasonably confident that we can finish this thing in a sprint. I don't want to be 100% certain. If we're 100%, oh, definitely absolutely can do this in a sprint. Um, then we've probably refined too far. Now, don't take me too literally. Some stories are so small. Of course, we can do them in the sprint, but I want to have a reasonable level of confidence that this thing is is going to fit in a sprint. We've thought about it enough. We feel good to go. >> Okay. Rita asks, "When a team cancels refinement sessions, believing they aren't needed, but subsequently experiences clarity issues, for example, stories with unknown details, scope creep, etc., it signals that refinement is either ineffective or misunderstood. How do we balance the frequency and those times the team is silent during refinement that so that this doesn't happen? >> I bring that up during the retrospective Rita. Um you know, hey team, you know, we um we ran into all these issues during the sprint. Let's talk about I'd make it very concrete. Let's talk about which of those issues we probably would have identified if we had done a refinement meeting or a better refinement meeting. And um you know by making it concrete like that you probably realize most of those issues would have been caught during refinement. Um and then I'd have that conversation with the team about um you know would it be worth catching these issues right you know if one of the issues was something that cost the team one minute it's like no that you know it's not worth refinement uh but if any of the issues were bigger that would be the balance. All right, let's see. Um, Neil asks, "How do you differentiate between a task and a user story? I was taught the former required one person on a team to complete that work, while the latter required more than one." Yeah, I I use somewhat the same uh definition, Neil. A task is something that does not deliver value to users on its own. Um, you know, code the code the news feature, right? That doesn't deliver any value. Hasn't been tested yet, right? it has all sorts of other things aren't done yet. So coding is a task but it doesn't deliver value to users. Um user story job story technical story feature of some sort those deliver value or create value for users. So that's the distinction I use. I think the oneerson multi-person thing is a good kind of rule of thumb. Um you know if you see something that is one person it's probably a task. If he sees something that's multiple people involved, it's probably a story. Um although we might have a multi-person thing like have refinement meeting, you know, five people have to go. Well, it's still a task, right? But it's five people. >> Barry asks, "How do you focus your team on just getting enough to proceed during refinement with the pressure they feel from very short deadlines?" >> Um the team doesn't most teams don't want to be in a refinement meeting at all. most, you know, we're tactical people. We don't want to be in meetings. We want to be doing our real work, not the meetings, right? That's how we feel. Um, and so, um, I would encourage people that this is there to help them do that real work, to help them go faster. I use the, um, analogy of process, whether it's refinement or scrum overall or whatever, you know, safe. These are meant to be like the white lines on the highway or the colored lines on a highway, right? The white lines on the highway are there to help me go faster and I'm going to get on the highway and I don't I don't suffer from road rage, but I do get mad when there's a lot of traffic. I get frustrated with a lot of traffic and um so I'm going to get mad at the traffic and and being slowed down, that type of thing. But I'm not going to get mad at the white lines, right? The white lines are there to help me go faster. Refinement, agile frameworks, same thing. They're there to help us go faster. And yeah, they slow us down sometimes because we have to follow this process, but if we do it, we're going to go faster overall. All right, Holly asks, "My team struggles with ambiguity. They want me, the product owner, to spell everything out so that they have the info they need to use AI agents to build the code based on solid requirements. How do we find just enough in this new world of AI based development?" >> Um, I would push back, Holly, with two questions. Um, one is one I I've used forever all the time, which is am I uniquely qualified to answer that question? Um my team asked me something this morning right back how far before we got on to do this and that literally was my answer um back to two of my teammates was like am I uniquely qualified to answer this right and I'm not right so it's like I was telling them it's up to you I'm not uniquely qualified so I think you're fair to push back on that in some ways um and the other one is um how would your behavior change based on the answer what would you do differently on the answer to this um and if how they build something or interact with that AI AI agent in this case isn't going to change. They don't need the answer from you. So I would focus on those two questions as ways to push back. Okay, Neil is next. U let's say team refines for confidence and not clarity. If the team is unsure about that dependency's availability associated with completing that work item, then is the team right to leave it out of a sprint? Is the team being too cautious? >> The team refineses for confidence. Okay. like I went if the team is unsure about the dependency. Oh, so unsure about a dependencies availability. Um, yeah, that's a tough one, Neil. I mean, if you if you think it might work, you know, if I I'm assuming in my head, this is another team. We're dependent on another team. If I think the other team might deliver what we need, I'm okay bringing into the sprint, I would be very clear with my stakeholders. We're dependent on another team. Um, if that team has burned me two or three times in the past, oh, we'll give it to you, and they don't, then I will not bring it into the sprint until that team has completed their work for us. >> All right. Um, next up is Ama who asks, "How do you tackle when the team is not ready to estimate because they're waiting for certainty?" >> Um, I would do whatever we need to. Oh, I might be interpreting this wrong. So, um, Ama, if they have enough information to estimate, but they don't want to because they think they need to be certain, I would emphasize the idea that estimates are estimates. Um, and one of the reasons I like using the Fibonacci sequence for estimating, which is like 1 2 3 5 8 13, or you could use um, simple powers of two, 1 2 48. One of the reasons I like doing that is I tend to think of those as buckets, right? We're we're absolutely we're estimating. We're putting a number on something, but I tend to think about it, does this go in the five bucket or the eight bucket? And I'm not trying to put on here, it's 6.3, right? I'm trying to figure out what bucket it goes in, right? We round up. If it's the 6.3, it goes in the eight bucket. So, I'm not trying to come up with these perfect estimates. I'm just trying to to sort things, right? Is it going in the one bucket, the two bucket, the five, the eight bucket? Where does it go? And so, I try to do that to to remove the pressure that teams feel to be right about things. Adam asks, uh, and hold on a second. The Did it Did it go? Yeah, sorry. Do you have any tips helping the team determine if we need to do more refinement this sprint if they're running behind? Sometimes we refining less per sprint than our velocity, but the team doesn't want to do any more backlog refinement. Um, I think that's fine, Adam. If you're occasionally, you know, let's say your velocity is 20 and you only refine 10 items worth of stuff, I think that's fine. um you're going to your next sprint is going to be a little bit more at risk um because of that because you will be bringing things in with less with less clarity um and more risk. So I think that's fine, but it's not sustainable, right? You don't want to do that all the time. So one of the reasons that I advocate teams be about two sprints ahead is for exactly this, right? So if your team's velocity is 20 and we've got about 35 points of stuff refined, um you know, basically if we did no refinement for two sprints, we'd kind of be okay. So, um, you always be kind of looking a little bit further ahead than that. And this is back to my analogy of the headlights on a car, right? You know, I want my headlights on the car to be illuminating a certain distance. And the faster my car goes, the better my headlights better be. And so, um, I I need to be looking ahead more than just a one sprint. >> Sorry, y'all realize I'm slouching and like [laughter] falling asleep in my chair. Uh, that was not my intention. Camila asks, um, how what does a good refinement look like? How descriptive does it have does a user story have to be to be refined for a non-mature team? >> I don't think there's a a specific format or anything like that. I see all sorts of different formats people use for this. I think it just has to be that it answers the main questions, right? You know, do we do we feel like we know enough about this? For me, that's very simple. I tend to use just kind of bullet points about what is needed for the story. I have the story, the job or user story. I supplement it with some bullet points means this this this this. So it doesn't have to be very descriptive at all. >> Heather asks uh where I find I struggle the most is trying to pull my teams out of analysis paralysis. Do you have any best practices on how to redirect the team back to refinement mode mindset? I Heather, I think it's the the it's the questions and the perspective that I was sharing during the main part of the webinar about getting them to realize we don't need to know all of these answers up front. Um, one of the things that I'll do when I have a team kind of in this situation is I'll acknowledge the value of their question, right? So, they want they want an answer to something. I'll say, "Great question, wonderful question. Do you need to know that now? Do you need to know it before you start work or do you need to know the answer before you finish the work? And if the team's being honest, they'll normally acknowledge that they need to know the answer before they finish, but they don't really need to know it before they start. And so push back with that type of with that type of response. Great questions. Do you really need to know these before you start? Right. They'll probably say they don't. >> Twyla asks, "Any advice about handling cross team dependencies and refinement?" um a couple to um one would be to um uh invite the other team into your planning meeting so they hear you the end of you know you guys come for the last 15 minutes for a planning meeting um we want to talk to you about what we need from you and so have them come for the last 10 or 15 minutes and just so they hear that you're committed to this the person can go back to their team and say hey they really are dependent on us for this another one would be to do what's called rolling look ahead planning like rolling rolling a ball and rolling look ahead planning works this way. You plan your one sprint just like normal and then you look ahead a second and third sprint. And Sirius I'm going to say do that in five minutes. Just do it based on velocity. Right. Earlier I made up a team had a velocity of 20. Look ahead the next 40 points. Go what are we probably going to do in the next 40 points. Those are not going to be the things you're going to do. Things will change. Things will get resized but it's a guess, right? Look ahead 40 points two times velocity and see if you have any dependencies. That's the five minutes. Spend five minutes looking for things. Oh, we need the other team to do this. tell them now in sprint one they're going to say you told us it's too late we just planned our sprint one but they can do it in sprint two and you'll have it in sprint three right so by doing roll ahead looking planning two sprints you'll be able to be aware of those dependencies in time Nishan asks how is backlog refinement useful outside of software teams for example in sales marketing people operations or recruiting and what practical value does it create in managing work priorities and execution That's a good question, Desan. Um, backlog refinement isn't anything about the technical aspects of the work. It's about understanding what needs to be done. And what we're doing with a product backlog is what's called progressive elaboration. Progressive elaboration means we start with a vague idea, run a sales campaign doing such and such. Um, and then over time we add detail to that. I'm going to give you an example. We mentioned that we're going to do another webinar in a couple weeks. Um, as part of that, we have a special offer that we want to make. So, our sales group is thinking about that. That literally started out as a one item just, you know, promote this product during that during that webinar. Um, and they were having a meeting, I think, today to talk about that further. So, you're doing progressive elaboration and that applies outside of software. though. >> All right. Um, let's see. Ashley's next. I'm someone who has come from a QA and compliance background to product manage management and ownership. Do you have any tips or tricks for moving from an everything has to be perfect mentality? [laughter] >> Yeah. Um, yeah, I can relate to that, Ashley. Um, I I think it's it's letting go of items being perfect and focusing more on doing the perfect job, right? And so, Ashley, can you think about yourself doing the perfect job? And the perfect job um means leaving some open areas there for the team to figure out. Um, and I'll give an example that suppose that you um, you know, are absolutely brilliant at your product. I suppose you are. it's why you got, you know, promoted. Um, and you could write all the acceptance criteria. Great. Cool. You wrote all the acceptance criteria. Um, they're perfect. That's still not good because I want the teams um, uh, to cocreate that. When we co-create, we end up with better results. And so, when you work with the team to fill in those acceptance criteria, you're doing a better job, a more perfect job. And so, I'd focus more on doing the perfect job than having the perfect user story or perfect backlog item. Okay, Tyler asks, uh, for a small team, what level of backlog refinement is needed before you can reliably prioritize items based on value versus effort? >> Tyler, I don't think you have to do a lot of refinement at all to be able to prioritize. This is one of the things I like with um, why I've spent so much of my career focused on estimating. I like story points as an estimating technique. And I know your question is not really about estimating, but I like story points as an estimating technique because they're good enough, right? If a team tells the product owner this is five points, the product owner going to look at that and go, "Okay, yeah, I want that thing." If the if the team tells the product owner the same thing is 40 points or 50 points or too big to estimate, the product owner might say, "Nah, I don't want that thing." Right? If it's that big, I don't want it. Right? And so in terms of prioritizing things, we don't need a lot of detail. All we need really is enough to put these really rough, loose story point values on things. May not even need that in some cases. Um Hunter knows that one of my favorite questions to him is literally will this take hours, days, weeks, months, years, or decades. Right? And if Hunter tells me it's going to take weeks, I'm like, okay, cool. I want that thing. Now, I know that when I say it gonna take when Hunter says it's going to take weeks, I know it could take eight weeks, in which case he could have told me months, right? But when he when the estimate in his head is in weeks, it tells me something about the size of the job. Absolutely. It could turn into a month or two. But when the when the unit in his head is weeks, it tells me enough about the work to say if I want the thing or not. Mara asks, "What are some strategies when the product owner only wants to discuss design and doesn't want to look through the backlog per the more visual end result view? Any suggestions for what I can say or do as the scrum master?" >> That's tough, Maria. Um, I'm wondering if the product owner is a former designer in that case, that's why they want to look just at that, or if they're just very visually oriented and they can't, you know, really think through without that. Um, I would probably in this case, Maria, do that. Let them look at the design, focus on those things. Um, but I would also want to make sure we're asking questions about, and this is more of the team in that meeting about, okay, anything we got to worry about on the back end here, you know, any technical risks. I'd ask some questions like that. I'd also try to refine a little further down in the backlog to issues to items that don't have uh a design a visual design ready yet. Um and when the product owner pushes back, say, "Yeah, yeah, I know we we're going to we're going to do a design on this next, but before we get there, I just wanted to have at least a short discussion, a little a short refinement discussion now because that'll help the designer." So, and I'd be doing that to kind of get the product owner used to the idea that we can talk without a visual. >> Rita asks, "Mike, any guideline of good AI shortcuts that one can utilize for better refinement meetings that you could share?" >> Um, I don't want to I don't want to overly push our AI toolkit, but that's got our best thinking in there. So, sign up at MJs. Again, it's free. Sign up at MJs Essentials. Check out our AI toolkit for this stuff. Um, I have found a lot of success with uh I love our story critic, right? Being able to put a user story in there and get criticism um of the story uh recommendation for, hey, this is a great story if it's way down in your backlog. This is a great story if it's ready to do next. Um if you're not going to do it for a while, it's too detailed. So, I think that can help. Um I think asking AI to um you know help tell me the technical risks you see about this story or you know what might our users be overlooking in asking for this story right how can this relate to our existing system here's three screens things like that so those type of things helping identify questions can streamline the meetings Matthew asks we have two levels higher than stories as our issue type for example epic feature story. So, we find it difficult to determine where the boundaries are. We expect it to commit to features in a quarter, but where do we begin? I guess my question is, how do we separate the feature refinement from the story refinement? >> Yeah, Matthew. Um, my head boggles at the complexity that some organizations will add in. Now, Epic Future Story is not bad, but I mean, I've seen that be like seven layers deep and stuff like that, and it's like I just don't do it. Um, you know, to me it's um, you know, big stories have small stories in them and you know, I don't really have that type of that hierarchy. Um, so instead of a hierarchy, I think of it more as like hashtags, right? So if you have a big story, you could put a hashtag epic on there, hashtag feature on there. And so I think about it more as hashtags than a strict hierarchy. Um, in terms of the refinement here, what I'd be looking at would be on an epic, your biggest, do we know enough that we could turn this into smaller stories, right? Um, into features in your case with a feature. Do we know enough that we can turn this into its user stories with a story? Do we know enough that we can complete the thing? So, I'd probably refi revise those questions. But in terms of committing to features in a quarter, um, one of the most common ways to do that is to, um, uh, you know, break that down into the stories that are inside the bigger thing. And, um, don't don't act on those smaller stories, but break it down. They could be notes inside the big epic, but that way you know what those those items are. And this goes back to my point earlier that acceptance criteria and sub stories are two sides of the same coin. Just break the epic down into a sub stories earlier. Um that'll that'll help with this. >> All right, Lou asks, uh, what's a reasonable time horizon to see improvements in backlog refinement processes? Overnight change seems unrealistic. >> Lou, I do think you can see improvements in a sprint, though. Um, you know, so I think you can go in and you can have um a meeting that's less painful. That's kind of what I'm trying to cover today. Have a meeting that's less painful. Um, and what I would love to do is have a team that is overrefining today. What I'd love to do is have them under refine next, right? I want I want them to go too far because the only way to know that you're in the right place is to have been on both sides of the right place, right? Um, you know, do too much refinement, do too little refinement, then you got the right spot. So, I do think within a sprint or two, you can see improvements in this. All right, let's see. Um, Manthan asks, "Uh, we always get into a situation where team members are hesitant in refining work as they say, I will refine the work that I'm going to work on personally in the sprint. If someone else is going to work on it, why should I refine it?" >> Um, I think that's fair. This is in part man why was saying very early on in the Q&A that I don't think we need to have absolutely everybody there in every refinement discussion. Um, but it is um early on. we don't know who's going to do the work and it is useful to have at least a couple people have their eyes on what it is we're going to come up with with better questions. This is back to my example earlier where I said if we have the whole team there we think of all the questions this many questions. If we have um about half the team we think of maybe 80% of the questions. I'm making that number up but half the team maybe thinks 80 or 90% of the questions. If we only have one person they're probably only going to think of 50% of the the questions. There is some um data around that type of thinking in one of the Heath brothers books. I think it was um stick um where they have some data around like how much does one person see of a solution compared to a group. Eric asks, "Do you have suggestions for ways to help a team break out of old habits? We have an organization with five or six teams and our refinement habits have been ingrained for a few years now. We want to improve, but it's difficult to overcome the inertia of bad habits." >> That's a great one, Eric. I just got that with a um a a company that wants to hire us to do some training, too. And they're like, you know, our team's been doing scrum for a while. They're not doing it well. They got all these bad habits. What do you guys do to break them out of bad habits? Um I would um I would try some I haven't done this, so this is this would be an experiment. Let me know how this works, but I think this would work well. Um is to tell the team that we're going to try refinement in a new way. In fact, everything that we're going to try has to be different from what we've done in the past, right? So, it's like we can't take we can't keep half our process. We're going to like try something totally different, right? If Wednesdays were refinements, we're now doing them on Tuesdays and we're doing with half the team instead of the whole team. I would try I would probably change dramatically in your case just to see how things go. Um the basis I have for saying this is when I first got interested in estimating I had I was like 30 or 40 teams and every team had to estimate differently. I told all the teams they had to find a different estimating approach. Um and then when they finished that project typically 3 months or so they had to start with a new project they had to estimate differently again. It could be similar but they had to estimate again. And that really broke a lot of habits and helped us iterate over easily maybe 150 estimated approaches to kind of hone in on what worked best. So I would try something pretty d pretty dramatic by saying we're going to try do this completely differently. >> Ryan asks, "How about a definition of confidence rather than a definition of ready?" >> I haven't heard that term, but I kind of like that, Ryan. You know, um, you know, here's what we need to be confident, right? You know, we needs to be the design has to be at least started, right? designer has to say, "Yeah, I can finish that up during the sprint." And I don't mean on the last day. Right. So, yeah, I think that would be worth giving a try. I like the idea. >> Next question. Some of the refinement sessions take a long time, not because tickets are not detailed enough, but because engineers disagree with solutions or approach. What's the best way to facilitate sessions and get the right outcome? Uh, also when estimating people come with different story points and then agree rather than articulate how they got there, how do you suggest to get people to open up more rather than accept other people's estimates? I guess two questions. Yeah, two questions. So, um, Nick, the first one, um, uh, the engineers disagree with the solution and they they keep arguing about it. Um, I will often describe that this way. If we're going to do the refinement meeting and, um, Nick, you want to do it one way, Hunter wants to do it a different way, but you both um, agree that it's going to, you know, be fairly simple. Um, you know, it's be a day or two of work. I'm going to say, okay, we know enough that we can bring this into a sprint. you guys differ on the approach. When we bring this into the sprint, we're going to put something like a day of work on doing the task and we're going to put two hours in there to fight, right? And that'll be you two fights, you know, exaggeration. I'm being silly, but that's going to be you two arguing over which approach is the best, right? So, we're going to make this thing bigger by having the work and then having two hours to argue or four hours day, whatever, right? But putting that argument time into the sprint and just agree we're going to have it. Um, in terms of people coming with preconceptions for estimating, um, I would probably try to switch the approach to where we don't necessarily know what we're going to, um, estimate next, right? So, um, I might try to mix things up a little bit and I might go to the product owner and say, "Hey, I'm trying to break this team's habit. They're always kind of, you know, pre-estimating some of the first things. Um, I'd like to actually go down the backlog, seven or eight items. Um, and you know, do your seventh item instead of your first item, but that way we're going to try to break the team out of this habit a little bit. So, I'd probably try to do something like that to just break that habit. I talk to them too about it in the retrospective. Don't come, you know, with preconceptions. On the other hand, I like the fact that they're thinking about the estimates before they get to the meeting. >> Jessica asks, "We have three teams that just combined data analytics and engineers. The current team is 16 and growing to easily 25 in the next quarter. They're working on different programs in different business units. So, it's not one backlog. Management does not want more meetings, but there is no way to effectively go through all these different backlogs for all these different people. How would you advise them to break up the team management? Um, it's like we're going to have one 90minute meeting or we're going to have three 30 minute meetings. It's like why do you care? Right? I mean that's like by definition of micromanagement. Um so um I would argue with management about that or whoever that is. It's like look we can have a long 4hour meeting in this case um or we can split this up by segment. Right? So I I would I would push back very very hard on management um trying Jessica to figure out what their concern is. Right? Is it is it more than just the amount of time it takes? Right? Because if it's the amount of time, it's a pretty easy argument, right? We're going to save time, right? I'd also make the point that that way we don't need everybody in every meeting, right? So, um, you're going to have more meetings on the calendar, but for less total time and less total person hours. Um, and I wasn't sure if the, you know, you said you had three teams and the current team is 16 going to 25. Um, if that's one of the three teams, that scares me. That's an awfully big team. Um, I mean that team on its own should be three teams. So, I'm hoping that the the 16 to 25 people was the the three teams. Otherwise, I'd think about restructuring as well. Christopher asks, "The POS onboarded from a team where epics were the rule of the day. Stories were so large but almost always estimated as a five somehow uh that they frequently rolled over. Questions weren't asked until the sprint began, and that's where all the uncertainty compromised the ability to get the story done. So the question is, how can I offer compelling narrative that gets them off their internal definitions that are continually hampering their efforts? >> Um, trying to figure out what the actual problem is here. I mean, I know that things are rolling over. Um, I I I think Christopher, you just have to bring this up in the retrospective and talk about how in your case, the stories are too big and too uncertain. I don't know what your velocity is. Five probably isn't too big to bring into a sprint. Um, it could be. My rule of thumb is that I don't want to bring anything into a sprint that's more than about half of our velocity. So, if your velocity is 12, a five is okay. It's a little big. Um, you know, I'd certainly if your velocity is 12, I'd love to be bringing in a lot of, you know, one, twos, and threes. So, um, I'd prefer to to break those up smaller. And so I would try to get the team to agree on at least one change to make. Right? We're going to break the stories up smaller um would be where I'd start. And um I wouldn't emphasize necessarily more detail on the small stories. You'd probably get more detail by having smaller stories. And if that doesn't work, then I'd start to emphasize even more detail on the things. But those are the two problems occurring. >> All right, got a few more here. I think we're going to try and wrap up in the next five or soish minutes. Try and get through these. Let's do it. Um, Alex is next. Can you clarify where a business analyst might fit into refinement? I know not all teams use BAS, but typically our BAS get to sign stories that have been refined by a PO or three amigos type of meeting. At that point, they have enough to begin meeting with stakeholders, manage scope creep, and writing specs for our developers, including all acceptance criteria. Just wondering if BAS are ever utilized during the actual refinement process. >> Yeah, I I love this, Alex. To me, a business analyst, a BA is basically the right hand of the product owner. And they do everything that a product owner does except the overall prioritization. So, a typical way of working for me would be that the product owner says, "Hey, Mike, the analyst, you're in charge of uh the reporting part of the system for this new law that got passed." And so, I have to go read the new law, figure out what it means, and decide what it means for our system in terms of reports. I come back with, let's say, 18 user stories. I've prioritized those within their own little section and this is the most important report. This is the least important reporting change. I'd give those back to the PO who then puts those into the overall um priorities, right? And they may say, we're going to do top five. Um then in terms of refinement, the analyst would be serving the role that a product owner commonly does. Hey, tell me more about this or how does this work? What should we do about this? Is this, you know, is this law like we go to prison or it's a fine? How does this work? So the BA would be acting basically in the role of the product owner for that subset of the system in the refinement meetings. >> Karishma asks, "Do we know enough to begin responsibly is very vague, especially in a team of different skill set and experiences and can tend to backfire if not refined properly. So how does one find the sweet spot between too much and enough to stop and move forward with what we have now?" Yeah, Karishma, this is my point about you have to do refinement too much. You've got to do it too little and then you iterate, right? You iterate to finding the right amount. One of my favorite questions in a retrospective is to ask, you know, how well refined was that item? Did we, you know, did we know just enough just in time on this story? And if we feel like, oh yeah, you know, we, you know, we nailed it, we knew everything that was perfect. Okay, did we know too much? Do we do it too early? So ask about in in the retros ask that about every backlog item to see how you're doing with things and like so much in agile we can't guess at the right level of detail for things. So we have to iterate there. So do it by experiencing both too much and too little. Jana it little sidebar came out of nowhere there. I'm having weird tool issues today. What's going on here friends? All right here we go. Jana should should an epic have acceptance criteria when user stories and tasks have them. I have challenged to have overall view of all of what an epic delivers and what is already developed and I'm not sure what should be covered in documentation in epic in >> so Jennet. So it's a little bit hard because people use epic different ways. I'm going to use epic to mean big user story. Other times people use epic to mean group of stories. Um but I'm going to use it to mean big user story right now. So the acceptance criteria for a big story is have we done all of its little stories, right? So should an epic have acceptance criteria? Not really, but it should have sub stories and those subseries are basically its acceptance criteria. So that's how you'd reconcile that. All right, Marcos is next. In the squad I work for, every sprint, there are some long user stories that the PO reads for the devs and QAs to being voted on with story points after some days or hours. Do you think that these user stories should be analyzed by one or some of the developers before the refinement in order to clarify some points or even break the user stories into smaller stories or are there other strategies for better refinement in this case? >> Marcos, I think that'd be a great strategy, right? Right? I mean, if we know what's coming into the next uh the next sprint, I mean, you could um the scrum master or product owner could divvy them up among team members. You know, hey, Hunter, you're familiar with this system. Why don't you think about this? Mike, why don't you take this? Marcos, take these three. Um I shouldn't have done that. Hunter and I got one, Marcos, you got three. But, um you know, but divy them up. You know, give people a few to think about and they don't have to do a lot. Just think about it a little bit ahead of time. I think that's a lot better than when we get there and we're blindsided. Um, what I always would tend to do as a product owner would be a couple days before refinement, email out, hey, here's the top of the backlog. Not sure how far down we're going to go, but here's the top of the backlog. Um, I can pretty much guarantee that on most teams, most of the time, most people didn't think about it at all, but a few people would read through it and think about it and come prepared and that was enough. >> Okay. Patty asks, "Do you always have to use a pointing tool for pointing a story during backlog refinement? And if so, does every person in the meeting need input to the points or is it okay to only have the role who will be doing the work give the input? >> Um Py, you don't need a a tool necessarily. I mean, I've had plenty of teams where we'll vote with um you know, our fingers, right? I mean, you know, it's I like powers of two, right? You know, I think it's, you know, two to the two, so it's four points, something like that. So, we can, you know, need a tool for things. Um, I do prefer to have everyone allowed to uh be involved in the estimate um rather than just the one person who's going to do the work because sometimes um somebody else may know something about the work that gets overlooked, right? I asked Hunter to estimate something and by far in our company, he's going to be the best at estimating those things on anything technical. Um, but if he says something is two points and like I and I'm the one that asked for it, I'm like, uh, you're missing something. No way is this is two points. I mean, I know that I'm asking for something big and he might go, oh, you needed that part, right? And you know, all of a sudden it's bigger. So, I would prefer to have um a little bit more variety throwing up estimates, but the most credibility goes to the person or persons who will do the work or likely do the work. Lisa is asking, "When starting a brand new builder implementation, how best to set up the epics or features without being waterfall or technical. It is building blocks that can have dependencies before you can even get to a real user story." Lisa, I think it's just starting with like your highlevel desires. I mean, I used Orbits as an example earlier today. Travel website, right? So, start out with things like, you know, we've got account management, you know, log in and do all that type of stuff. Um, book hotels, right? There's a great big epic. That's a massive epic. you're probably going to have like a thousand user stories in there eventually. Um, book hotels, book rental cars, and eventually, you know, book cruise ships. That one stays alone just as one big thing. So, just think at a very high level. And we can think about this as, you know, in old waterfall processes, we had what was called a work breakdown structure, right? Break down the work into subtask. This just kind of a feature breakdown structure, right? At the high level, we've got uh reserve uh space on a plane, airplane by airplane tickets, and I can break that down to it. its sub story. So just think about your feature breakdown structure that way. >> Don asks, "Are the acceptance criteria expected to change during the sprint as new cases are found during development?" >> Good one, Don. Um yeah, I think so. Um if no acceptance criteria changed on anything during a sprint, I would think that we overthought things, right? And it's back to my point about, you know, it is possible to do too much upfront thinking. So, I would expect the acceptance criteria to um I'm going to change your word here a little bit to evolve during the sprint. Um I don't really want a lot changing, right? Oh, we said it was this, now it's this, right? It shouldn't be outright changes, but the you know, it shouldn't go from three items of five items or we had five exception and we decided one is not important. It went down to four, right? So, they started to evolve. >> Okay. And FD is asking developers would just create stories in the backlog for everything they find is pending or come across where either some technical debt or schema validation needs to change etc. So is it the time or value that would define if it's a task or a story? >> It's really whether we're creating value for users and um you know so something where it's you know validating a schema or something like that we're not really creating any value for users. So, I would not have those in my product backlog. They're great. They can be in a sprint backlog. A lot of teams will maintain a list of like, you know, tech backlog. I kind of don't like being totally separate, but it's like, hey, here's all the tech debt things we want to pay off someday. Have a separate list of of some of those things is fine. >> Okay. Uh, that's it for today. >> Well, lots of questions. Appreciate everybody being here and talking to us about backlog or refinement. Um, you get those emails probably about a half hour from now with some links. you can download um our checklist and hopefully that helps improve your backlog refinement. Um we mentioned our AI toolkit so check that out if you'd like. I think story critical help especially with refinement. Other than that, thank you all for being here. Greatly appreciate it.
