AA112 - Master Agile Estimation by Evolving Beyond It

So we've created a couple avenues for people to ask us questions on the podcast so if you want to ask us questions on the podcast, go to the website, fill out the form, or leave us a voice message. And we will play it on the podcast like the nice thing about a voice message. We can play it on the podcast. Yeah, so go to ArguingAgile.com. That's where you'll find that form. That's right. ArguingAgile.com. this podcast, we are gonna talk about a subject. That Clint suggested. Going from a team Who estimates to being a team that doesn't have to estimate at all? So Clint, this is your podcast. If you're listening, and his question was on the topic of story points and throughput, aka cycle time, lead time, but in Agile Podcast 50, we did the whole hour long podcast, just on estimation why you estimate different types of estimation. So I'm going to only try to rehash as much of that as I absolutely have to on this podcast. But, we did a whole hour long podcast. A deep dive in the different ways of estimation. Yeah. So we're not gonna touch that, but we are gonna handle, Clint, we're gonna handle the spirit of your topic rather than the letter of your topic. all right, so let's, let's start. What did Clint say? So he says, Have you guys covered story points versus cycle time as a topic yet? I think a lot of people could benefit from that. So, so Clint is using story points currently and I said cycle time, but I, what, what I believe, Clint, what I believe you mean is throughput. Like regardless of the, the actual metric of cycle time and or lead time I don't think in our, in Agile podcast 50. I don't think we talked about cycle time, lead time in terms of the, the wait time involved, right. And the time of delay being calculated and stuff like that. Yeah. That's a little bit deeper than what I think we got into in, in, in episode 50. Yeah. I suspect that's true. But, but again, this. The spirit of, his question is, the team kind of struggles with estimates. They're doing story points. They're doing the best they can. Now how do we evolve the team to get to a point where they don't even bother with estimates anymore yeah, that's a fantastic, topic because I, I feel like n people don't really address that sort of thing. They get into the, You know, the mechanics of estimation and things like that, but nobody talks about bringing a team through a level of maturity where they don't have to estimate. Right. Right. Starting for a spot where they, where they do. Right. If you are on a team that is estimating and you need help with that, check out arguing Agile Podcast number 50 is all of our estimation, maybe we'll put a link below. We, we'll def I'll, I'll even throw the card up on the screen for this one. This is gonna be a little bit different than our normal, like this is not gonna be like debate style podcast where we're trying to do pros and cons. We're just trying to give you different strategies in this podcast to help you. Maybe you can apply these strategies. Maybe you can apply one. Maybe you can apply multiple, maybe you can apply all of them. But when you apply them and you see them being successful, you are further along the path. To toward moving from a team that estimates to a team that doesn't have to, right, that's right. Kind of struggles with estimates. They're doing story points. They're doing the best they can. Now how do we evolve the team to get to a point where they don't even bother with estimates anymore If you think about it from a lean. Standpoint, anything you're doing that's not adding value is a waste. Mm-hmm. An estimation for the sake of estimation is a waste. Now, I, I get why people do it. It's a plethora of reasons. It's being asked off them, they hide under the the guise of wanting predictability, et cetera. so if you got a team that is doing estimation, Talk about this with your team and figure out, you know, why are they estimating? What are they trying to solve? Yeah. Anybody that picks up this podcast, like their team probably is estimating and they probably are like, whoa, what? What do you mean without estimating? Like why are they estimating the. First place. Let, let's start there. Product manager, bringing my product management needs to this discussion, I need to be able to forecast. So that, that would be the first thing that my brain goes to is I need a forecast. Yeah. And that forecasting ask is you know, not only from a product standpoint, I've seen it from the. PMO standpoint too, because they're used to handing down mandates in the form of prescribed Gantt charts and do this by the state type of thing. So when the team start estimating at the sprint level mm-hmm. People wanna know, you know, does all this stuff fit in with my milestones that are on my ga chart that I fabricated out of thin air. Yeah so teams estimate for a plethora of different reasons, right? We, I That's true predictability is one. We're not saying that you can't get predictability if you're not using story points, though. That is just a way to do that. Well, I mean, you could estimate in hours for Yeah. Could nothing wrong with that. It's just as good as any other, or as bad as any other way of doing it. What it comes down to is, People looking for accuracy or precision rather, you know, in estimates. Cuz the word itself tells you what it is. It's an estimate. Yeah. Which is really just a, a best effort guess as to when the team might get something done by. Mm-hmm so by definition it is not a guarantee but I don't wanna go down that path too much. Another reason that teams estimate is the act of going through the estimation where, you know, we say, Hey, we need to add a form to the website. And you know, Brian and Om both hold up cards at the same time, and Brian's holding a three and Om's holding a 13. The actual act of estimating helps facilitate the conversation where we talk through and agree on what is in and what is out of the work items and, you know what I mean, where, whereas otherwise, if one developer just picked it up and said, well, I got this, don't worry. Like, I'll, I'll pick up the next. Order off the line, you know, I'll pick up the next ticket for a cheeseburger or whatever. Like if we did that, like I might cook you a really elaborate cheeseburger when all you want is completely plain. No ketchup, no nothing. Yeah. Not even any cheese cheeseburger. Yeah, I don't. Cheese less cheeseburger. That's right. No, this is, this is where you end up with cheeseburger. Yeah. This, yeah. This is where you end up with team members saying, You know, I'm working on this right, pretty much every day at your daily standups so yeah, that's, that's very true that the act itself lets you reduce the, the cone of uncertainty to a certain degree. At least have a dialogue around it. So there is that benefit right to that. But there are alternatives too, right? Mm-hmm. To that so for example, what would happen if your stories were so small? That the team could understand what needed to be done. There's only one thing that, that exists in the story as the description for it. There's only one thing that defines what the definition is for finishing it, which is the ac, the acceptance criteria. Mm-hmm. And that's it. Mm-hmm. Just, just one. Right. Then ev, if every story was like, That your stories are so small that if you estimate them, they're likely not gonna diverge too much. It's, it'll grow from one to three, maybe a five, occasionally. Right. And then you keep talking about that and reduce it down even further. So it comes down to a three. Yeah. So fast forward, right? So most of your stories are one to three point stories. Mm-hmm is there a, is there any point unintended in estimating. All of those stories at that point, if you get to that level I see. Of breaking down stories. I see, I see. So, so if you, if the whole team agrees. Like if you have a team agreement that says if the story is considered a one, two, or three in story point size, we just call it three and move along with our lives. Pick a number one or three, nobody dies on. Yeah. Yeah. Because the difference between them is so small, right? Yeah. Yeah, yeah, yeah, yeah. I can see that is a, that's a great first step. I gu I guess we're talking about like w walking the walk now. So the, the first one that you recognize is keep refining a work item until you get into the range of a one, two, or three. The the other thing that I have told my teens before is when you pick up a work item, you need to look at it from the perspective that it can be done through whatever your definition done, done, done, deploy ion, done, completely done in two days. If you can't have that item done in two days. We need to first of all identify it clearly, identify this is not possible in two days, and then we'll talk about what can, what pieces can be delivered in two days. And we'll break the, we'll break the story up and we'll break it in pieces, and then we'll decide what priorities and. Stuff like that. So that, that's another technique I've used to, to, to help the team understand how to break things down. I guess we're talking about vertical slicing now, I guess. Well, we absolutely are. And, and yeah, that technique is good as well. Right? Um, because if you're deploying something into production or whatever your DOD is, In two days, that's well within a sprint, well within a sprint. So you can get things delivered as value in, in production environment so that's, that's good. I've seen this, this is credited to Mike Miller who's watching obviously. Yep. Good on you, Mike, everybody yeah. So he, he came up with this rule of thumb that's before he gets the host, you know? Yeah. One by, one by one equals one. So what he means is one by one, one action, one actor, one result. That's right. And that's one story. Anything more than the ones in there, break it down more. Right. So yeah, through your refinement, try and get to that point with your team where everything is so small that the team's not spending any time arguing over whether it's a one or a two or a three. One action. One actor, one result. Yeah. One actor, one action. One result. One act. Yeah. One actor, one AC action. One result. It's hard to say that of. Sure. You know, read it off the tongue. Yeah, sure. But but it kind of made sense. He uses the example of accepting payment by credit card, for example, right? Mm-hmm. That some teams start that off as a story, and they have another story that says, accept payment by ACH or whatever, right? Yeah but his point is why do that when you can break it down and say, Except payment by Visa, right? The first story is where all the learning happens. So maybe that's a two or a three. Mm-hmm. And then the next story, except payment by MasterCard. What really changed from that story to the previous one? Just the algorithm. Just the, yeah. The check sum changed, right? Yeah. So that makes sense to me because at the end of the sprint, let's say you didn't get all of the stories done to accept payments by payment, by different credit cards, but you got some done. Yeah. You could still go to production and say, we accept Visa, MasterCard. Tackle, discover, or whatever else you've got left in the next print. So you're delivering value at least. Mm-hmm. So that made a lot of sense to me, thinking about it that way as well. Yeah. I think all of these examples come down to this only. Right. Break your stories down so that you can deliver slices of value, but don't do it horizontally, please. I you said some, oh no, look at me. I got a jacket on now. That's so weird. How'd that happen? You said something in your example about like the, the learning is kind of front loaded with the first story. I want to challenge that because I, something I've been doing with my teams. for a while now is I spend the learning out on, into its own story and I will tag the story where learning is done appropriately to let the business know that that time should go on the budget wherever training and stuff comes from, like that, that particular budget because I'll mark things as capabilities, basically, the team has learned to do something that they didn't know how to do before. Maybe it doesn't work for credit, like credit card process. Yeah. Maybe it's better for like, you know, deploy like deploy our software via Kubernetes or whatever, when like nobody on the team has any exposure to Kubernetes, so they have to go out and learn career. So the, like the story at that point is like, Demonstrate to the rest of the team how to use Kubernetes, and that becomes a story. But I'm only doing that because I need to deploy a, a, a product that I'm ready to deploy. But I can't because my team doesn't understand deployment technology. So I have to send, I have to set up a story for them to spend some time to figure out, hey how do I use this? What's the best way to use it? What's like I could bake all that into a story and say, Hey listen, we're not gonna have a separate story to learn things. Just go learn by doing it. And all that will be assumed in the story. However, like as you know, like in like Scrum kind of assumes that There is some familiar, if you're doing relative estimation. Well, this is what we're, we're gonna come back to one of the main arguing points here. I know that wasn't gonna be the point of this podcast, but to, to address one of the main arguing points here, which is, well, if we're doing tasks that we've never done before, how can you say they're all the same size, we've never done them before. You don't have to handle those in the methodology. You can timebox that effort to say, Hey, take two days, three days, whatever it is, the whole sprint if you want. You are not on the team doing work that's counted against the team for the sprint. You are now on this task until you figure out how to do it, right? Yeah. Yeah. And, and, and, and so basically you're either using a framework scrum or kanban or whatever you wanna do. Or your timeboxing, well come on, kind of as timeboxing a task, but, or you're timeboxing the task and saying, Hey, at the end of your time box, come out of your time box. Come out of your hidey hole and share with us what you've learned after that time. And if you've learned nothing, you're like, Hey, I spent two days. I, I don't understand this. It's completely foreign to me well, maybe that, I mean, maybe that's the trigger of a bigger problem, but number one. But number two that's a way to leverage what you're doing now and deal with uncertainty. So keep predictability. Because they've not, if they're wasting time on things that are too complicated to figure out, we're never gonna do whatever. Yeah. Things that don't work out are good too. Hey, go learn. Go spend some time learning this new technology. Hey, I learned this new technology. It's a flash in the pan and I don't think that, I think this total trash, we shouldn't use this. Right. Well, you spent two days at least we didn't spend $2 million. Exactly. Yeah. No, I look, I agree with spike stories or spike sprints even, right? Yeah. Yeah, that's fine. I think that's a slightly different case to the credit card cuz assuming the team knows how to, you know, process. Credit card. Exactly. Yeah, yeah, yeah. But yeah, definitely agree with that. Yeah. But I do like where you went with allocating that story to a different budget. The learning budget, right? Mm-hmm. And I don't know if everybody has that luxury, but that's really good because it shows to the organization. You know, people don't know this stuff that you want. You want 'em to do something. They're figuring it out as they go. Right and that's a good way, I think, to illustrate the need for learning and training. Well, if you don't have a learning development budget, I guarantee you there's another company out there that does have a learning. I don't doubt it. Yeah. Yeah. So I mean like what are you doing and what is your company doing? What, first of all, what are you doing with your life where you're working for people that are like, We don't have time to get better. Get back to work. Yeah. Yeah. Those are people that, first of all, frown upon retrospectives, don't waste your time. That's right. Go code some more, you know? And then second of all, if, if you do have that budget, You probably have a management that's saying like, is this, is this a budget that, like we run out in December and try to hurry up and book people into trainings because we're gonna lose the budget? That's not a good look either. Like the, the better look is slowly over the year you're training your people or you're spending off time with to, for your people to learn, for your people to evolve. So some of that stuff is done in community of practice type events or like developer kind of hackathons. Yeah. Code, code. Dojos or whatever, whatever, whatever you wanna call it, right? but listen, some of that work it's in pursuit of product work. Why would you not bake it into your roadmap? When I do things like this, my default time box, my feelgood default time box is two days. Because I feel if I spend two days, even if people are peer programming two people to developers, so four, four days of pr, productivity, time, whatever in sprint time wasted, whatever man. Like I, at least I know I don't want to go down there. Well then it's not a waste Cause you learned something. I learned that. I don't want to go down that path. Yeah, yeah, timebox things that are unknown, truly unknown, work through the learnings together as a team and decide to pivot based on that kinda stuff. So so you don't need to estimate yourself this time box, it's just, it goes into your pool and you say, we're not gonna spend more than X amount of time on this. Yeah. Yeah, definitely. I agree. And one of the things that really makes me a little bit annoyed, let's say, is when teams have spike stories in their sprint that last, the whole sprint. And they say, this is a an eight point story and we've. Estimated it and at the end of the sprint we haven't completed it. So this goes into the next sprint. Like break it down some more, do some, some vertical sliced learnings, because not everything needs to go into a large story like that. You should be able to figure things out. Yeah, in a couple of days to see if you need more days. Listen. That I've definitely had it happen to me before where, where people come, you know, a couple days before the sprint ends, and I'm still seeing the, the task in progress and I'm saying, Hey, I thought we agreed to timebox this. Like, what, what's going on? Like, I haven't seen a demo, I haven't really heard about any challenges in particular. Like what, what's like, if you're walking the board, I feel these things will get vetted out to say, Hey, this time box task what's keeping it from moving forward to done? Right oh, oh, well now, oh, I'm, I'm still working through it. It's kind of complicated. I'll get back to you tomorrow. Like that, that that's fine. I want to leave your room to experiment and to figure out your way. I want, I wanna let you grow and develop as a human being. Psychologically, emotionally, physiologically, spiritually, but also if I hear that as an update and the first day is like, oh, no, no, no, just leave me alone. I got this. That's fine. That's fine. But also like you don't have anything to show. They gotta have something. You worked, you worked the whole day and you have nothing. To show I That's a little farfetched. Yeah. I am a terrible programmer. I will, I'll freely admit. Terrible programmer. Like the way that I program, I don't know if you program this way, there's probably people gonna listen to this that are gonna laugh at me a hundred percent fine because my things get done. But here's the way they get done. I write the script and then I'll go back and I'll take sections of the script that are like copy pasted, whatever, and I'll refactor those into functions. And then at the end, You have a nice, normal program with functions, but when I write it originally, it's a giant massive copy pasted script that's just garbage. And I don't wanna show it to anyone cuz it's embarrassing oh, I can't, I can't show it to you. It's really not like a no, I can show it to you. It's just ugly, ugly, ugly unmaintainable. Like I wouldn't want to pass it off to anyone else but I ca I do have something I show you. That's the point, right? You have something to show, right? It, it doesn't have to be the most elegant thing on the planet, right? Maybe you decided on the second day, Hey, none of this code gets called more than once and there are no functions needed. Fine, whatever. But show something toward the progress of it, right? And say, here's what I've done. Here's what I, you know, here's where I think I can get next. I don't know. I'll let you know tomorrow, right? That's fine. But don't keep doing that every day of the sprint and then at the end of the day, Last day of the sprint, say, I'm still not done. Yeah. Yeah. That's, it's crazy. The other things that are steps in this journey. Cuz that's kind of what we're outlining is like steps in a journey. Mm-hmm. Is now that I think about it I do this on pretty much every team I have ever been on is I start by writing the stories. Cuz I'll have the template and I'll kind of, you know, have'em the fields I need in Jira. I need business value, I need user persona. I need, I need a couple fields that aren't in Jira by stock. So I'll create them and stuff like that. And I'll I'll put refinements on the calendar and I'll start walking through the basic stuff. When you be estimating, you know what I mean? But eventually I will start gently pushing back onto the team to say, okay, you guys have seen me writing stories for six months. You know that I say as a, and then I name a persona, I want some kind of piece of functionality. And because, and that, that details the why. You should ask me the why. If you don't know the why, but I, I, I start gently pushing onto the developers. You guys have sat here and watched me write stories for six months. You should know how to write a story at this point, and, and if your writing stories is just completely copying the way that I write stories and it's just really bad. Listen everybody writes first drafts. They're all terrible. So don't be embarrassed. Like everybody learns to write stories by writing up a first draft of the story in front of everyone and getting yelled at. Everybody learns that way. So again, don't take it personal, but I feel if the product person, or I guess in larger organizations, maybe like a BA or something like that, if those people are writing the stories, interviewing the customer and writing the stories at the same time, talking with the subject matter expert, having them walk you through their workflow as you write the stories for them. Again, I assuming you need to talk to customers, right? I'd be even willing to be challenged on, maybe you should have never been doing that in the first place, but I like to show what success looks like. First and then start handing it off to the team to say, now it's your responsibility to do this and like slowly cut over over time. And then, and then at, at, at some point the team will learn They will learn that skill and start doing it in the future. And then literally all the product manager has to do is show up with the correct people, the correct users to the session, the correct stakeholders to the session, and the correct why and vision in their mind. Basically, I think the developers co-creating stories is, is excellent I encourage that by putting a template in place. When you click new to create a new story, yeah, you can do that. It starts off with as a, and then there's a couple of braces there. They can fill in the persona or whatever. So it. So one thing is, you know, initially yes, you're right. We need to show what good looked like. Don't go in there with the stories created. Do it in front of them. Yeah. And just work it out with them, you know, interactively. Yeah. So they can see the process is kind of, it's collaborative, right. In nature. And, and then flat out, ask them who would like to create the next story? Feel free to share your screen. And, and let's, let's do this. We'll do this together so they don't feel like they're gonna fail. Right. You really can't fail. It's a learning exercise. But I agree. I think co-creating stories sense has a sense of co-ownership too. Yeah. Right. And if one person does it and goes through it as a developer, next one's gonna put their hand up. That just happens. Yeah. Organically. So I like that. I think, I think that's the way to go. Not bring ready created stories and say, here you go. Right. Go, go chew on these things. That's nuts. I like where you Started with that which is one, one developer creates one story, and then when they create one story, like pass the baton to the next person and say, Hey, like it'd be nice to have a team working agreement that says like whoever creates a story can't create the next story and they have to pass it to somebody else. So maybe he is like two people trading off back and forth. Sure, maybe that's okay, but at a minimum, I don't want one person creating all the stories I want a trade off. Well, I'll tell you what happened, a little slight anecdote here a couple of seconds on that. Yeah. So one of the persons who basically put their hand up voluntarily, it was a QA person and when she started writing the stories, it was really good because she started putting in the QA perspective. Like she would start asking questions like, well that's good, but how can we, how can we test that? Right. And. To me, this is the essence of it. Right. Collaborate together to see how the team jointly could meet the d o d Yeah. On the story. So that's, that was a great experience. Something I brought up just now that we kind of glanced over is whoever the stakeholders are, that the stories are kind of being written on behalf of. They should be in those refinements when you're writing the stories and all of your developers on the development team should also be in those sessions, or at least whoever's gonna work on it, right? If you, if you have the ability to get down to that granular level before you even know you're gonna be working on it, I don't know. I even know how you do that. But if you can figure out how to do that, that's great. But the, the, the team should be talking directly with that customer that's heresy. I know, you know, at most site, most locations they don't do that. I haven't seen the actual customer in there. I've seen the customer proxies, I've seen, you know, ba I mean, whatever you gotta do to get it, whatever you gotta do to start. If it's a customer proxy, okay, fine. It's a customer proxy. But it's better than, it's better than the, the product manager and the development lead or team lead or development manager. Going off and talking with the proxy by themselves and then bringing the work back to, oh, oh, no, actually not even bringing the work back. This is like the Silicon Valley model or whatever. The people get lunch all day like the, the, the product manager and the development lead going and talking to the customer proxy and then talking to each other in a separate session, writing up the stories, and then the development lead without the product manager goes back to the developers and tells 'em what they need to program. That, that, that's the model that scares me more than anything else, like a proxy with everybody in the room, I'm actually even more comfortable with. Then what I just described, what I just described is scary, and I've seen it in a bunch, multiple hands off. I saw, yeah. Multiple handoffs, right? Yeah. I mean, that's a prevalent model out there, unfortunately. Yeah. That's what I've seen the most. Yeah. Well, that's very scary because the why doesn't ring true in, in, in that scenario, and a proxy's. Okay. But over time, whoever that proxy is, Maybe your development team can get them comfortable bringing the customer in as well, or, or if not, maybe you can get them comfortable asking the proxy to bring the customer to the sprint review. And then over time as the. As the customer and the proxy get comfortable with the development team at the sprint reviews, maybe they can kind of talk 'em into coming to the refinements. I, I think that's a good model because it sets the expectation, right, what's coming next at the review. And then during the refinement it says the expectation of, we're working on this. Confirmation of the what and the why so that at the next review, they're not surprised. Oh, what a, what a great and also sneaky way of evolving your team of like just dovetailing your sprint review straight into a refining because you have the people in the room. What a, what a great sneaky way. Of advancing your team's understanding and, and you know, well, customers are hard to come by in terms of their time, so you may as well leverage it as much as you can. It's not a bad plan as, as far as saving people time, it's not a bad planner. Like with sprint review is gonna dovetail straight into a refinement. Um, that's. That's, that's not bad. Actually. Now, now I think about it, like if, I'm trying to think about techniques for, for, for teams who have a difficult time getting in front of their actual customers they're serving, that's not bad. Then the customers also get to see if you're if you're estimating your work, let's say you haven't got to the point of no estimates. Yeah the customers, if you're refining and estimating right away in that same session because. The stories have just been refined. They're top of mind. Then the customer gets an idea of the process, right? And they understand how much work the team can potentially take up. It. It might change a little, but Yeah. You know, so it's all about setting the right expectations, right from the beginning, right? So at the review you can say, we agreed on all these things, these eight stories. We got seven done. One we were reading on something, we took it out of the sprint. That's fine. You know so yeah. I like that. Yeah. I'm trying to think of people that might push back on what we're saying. I'm trying to think of what they might be concerned about. I could see teams with like proxy pos or weak pos or pos that are just kind of like pass throughs for feature teams, stuff like that. They, they don't really know the why. They're just kind of doing what they're told it's difficult to align your team and what they're doing to business priorities when your PO is kind of not really the empowered person in the business that, that. So I, I guess maybe. Maybe I should have started this podcast with, with this item. It's difficult to, to, to proceed in all the different ways that we've been talking about. When your PO really doesn't know the why they're not informed as to the company's vision, they're not informed as the product vision. You know, maybe they're buried in a couple layers down in a group product management kind of layer. You know, I, so there, there's some challenges there that may be organizationally, I. Um, you have to talk with your PO and you have to talk with maybe a couple layers up in your organization to figure out if there's a better way you can solve, or, or maybe you have a PO who's overworked on many, many teams and you know, maybe that's another conversation. Yeah. And, and I've also seen that kind of behavior from teams that say, but we're developing things in a B2B environment, and then they have the customers. So how can we get access to those customers? Right. And, and that that's also not true because you need to really live in the shoes of the actual customers. Right? Right but yeah, I, I think any of these things, if you can start with them and then evolve to the place where your teams are getting more mature, might take a few sprints. You probably get there where they don't have the estimate eventually. Right. But give them, give them the, the rationale. Give them the tools they need to succeed with it. Mm-hmm. Yeah. And then put these techniques in place. I just wish I had a better suggestion about aligning your PO properly. You know, if they're not, I, I, I don't have much of a suggestion there because it, it, I have one. Oh. Oh. Okay. My suggestion is, is gonna sound a little radical how about your PO coming from the customer's organization? Right? From, from them, like one of the customers is your po. Mm-hmm. Now your SME is in the room with you, right? Think about it. Yeah. Yeah. Maybe if you show business value in line with the rest of your metrics, you know, or maybe if you have a customer actual usage metrics to show before and after features, maybe you can help your PO be a bit more empowered, a bit more data driven with their decisions. Maybe you can help them with their decisions. I, I, I don't know. I'm, I'm trying to think of, of trying to help a struggling po in an organization where they're, You know, basically just told like, just deliver these features and get outta here kid. That's a feature factory. Yeah.. That's about the only, that's the only The other thing that I tell my teams is I don't really care how they estimate, like story points, hours, whatever, because I'm gonna be watching the throughput for their stories. I'm gonna be watching the I'm gonna be, I'm, I'm going to watch the throughput and I'm gonna watch the cycle time and lead time. So how many stories did they complete in the sprint? Basically just pure number of stories and what the cycle time and lead time for the stories that the team pulls through are. I'm gonna watch the all, all three of those. I'm a little less concerned about lead time. Yeah, I'm a because you can gain that and then like the, it, it depends on the organization's intake method and stuff. Like I'm a little less concerned about it for the team. I am more concerned for the program right yes, but I'm gonna be watching cycle time. I'm gonna be watching throughput and, and with an eye on the, you know, the, the burn down slash velocity that the team is putting through. Cuz I'm gonna be kind of I, I'm going to, I, as the product person am going to be looking if there were kind of equal. Like if my, if, if my velocity is relatively stable, I would also expect that my cycle time is relatively stable. Oh, absolutely. They're correlated, right. So, yeah. I, I think the thing to do is to make sure you know what metric you're using and what time horizon it spans over. Yeah. Right so obviously velocity per sprint, et cetera. cycle time, you wanna give a good time range. Maybe a, I don't know, two, three months. Sure. So it can average out so, so I think that's good because cycle time does give you on average how long things are in the hopper. Yeah. From start to finish. You, I, I'm not concerned about lead time because it's one of those metrics that if. The team is doing a good job. It perhaps tends to punish them. And here's how right. You do a good job and get all these stories in your backlog, right? So you have a reasonably good backlog, not too deep to the point where it's so deep that it's just gonna decay away so if you're doing that and the team is taking off the top of the stack, certain number of stories and, and kind of churning away through the backlog. Those stories that you put on the backlog to begin with, their lead time started the minute they were created, right? Yeah. So that lead time is going to be excessively long when they deliver, but actually they may deliver their story appropriately, meaning when it was supposed to be delivered, right? Which sprint, et cetera, if you're sprinting. So that's one. The other side of it is if you are using CanBan you don't have a very deep. Backlog typically. Mm-hmm. Then your lead time looks great. Right and so what about cycle time? Well, what time bands are you using for that? Mm-hmm. There's kanban, so again, put up a time ban. Just say it's a month, or, you know, three months, whatever time period you use. Use it consistently. Obviously don't switch, but yeah. So I think those, those have to be taken in in context, right? Yeah. If you are using Jira for example, like I haven't done that in a while on a podcast, like if you are using Jira and you enjoy pain so that you use Jira and you don't need to ever show things like across multiple teams or products or at a leadership level. I guess then then I guess you use Jira. There you go there so like, if you're using Jira JIRA gives you a control chart. They call it control chart because they like to work controlled. Of course they do, because it's hilarious. Yeah. Well, they're you're working in a project, aren't you? Yeah. The, oh yeah. That's why all their products are called projects. But what the control chart in Jira does is it lets you see the time at every step in whatever workflow you've created in your overly complex workflow and or steps. But it, but it does, it lets you inspect every step. So how long does it take to go from step to step in every step? So if, if you truly are dedicated to continuous improvement, I mean, you, you really could. Sit down and look at the average of how long it takes items to go from step to step and have a good con, a deep conversation, a data, a data-driven conversation like emotions out of it. A data-driven conversation of let's look at all the work items that took longer than the average in the last three cycles, whatever, I don't know, time period to and figure out why they took that long to see if there's some kind of commonality to see if there's maybe. A whole bunch of flukes happened. Maybe something happened completely the outta side of your control. Maybe there's nothing you could have done and you just look at 'em all and say nothing we could have done. And you moved it. At least you've done something towards continuous improvement. You've inspected and decided that there's really nothing that could have been done. There's just terrible coincidence. Let's cross our fingers and hope it doesn't happen again. But more than likely, you will look at that. List of things and say, well, in this one we had to wait on whatever. We probably should have never picked it up in the first place. This one, we had this blow up in production and we just forgot to take it. Whatever. Maybe we need to be more diligent. This one, we had a problem. It was, we didn't expect it to be so to, to, to truly talk to the reasons with the data on the table. Not blame anyone, you know what I mean? Talk, talk through the work, not through the people, right? And have a, a conversation in each. So pick a step. What's your worst step? How can we approve that worst step? And if you're having a throughput discussion, right? Yeah. It could be the whole cycle, it could be one particular step in the cycle, whatever doesn't matter for this conversation you can have a real deep continuous improvement conversation. If you've got those metrics in front of you. Yeah. That's, those are great points. So the, the discussion you're having at that point in the continuous improvement realm, to your point right, they, they are evidence-based, right? So that's the first thing, right? Yeah and they are historical, but you can look at those as a team and say, Here's where we need to focus. So select where your focus is. You can't focus on everything and then improve on that. You can. You can, but you won't get anywhere. Yeah. So that's the other thing I wanna just quickly mention is, You can do this even if you're using Scrum, it's not just kanban. Sure. Right. And most m tools chart, that chart works regard in Jira that chart works regardless of regardless. Yeah, yeah. And, and in most m tools, right, you can, you can derive that chart. It's often called cumulative flow diagram. Yeah. Where it lets you identify where the bottlenecks are these are great tools for you to look at as a team. On a regular basis. Mm-hmm. Typically the best place to do that might be a retrospective or you don't have to wait for a retrospective, you're experiencing a bottleneck. Anytime is fine to have that discussion as a team. Have it as a team. No blaming. Yeah. Right tackle the problem, not the person or not the people. I think you golden if you can do that. Let's move to summarize kind of what we learned in this podcast. I think the number one takeaway here is you should build data. If you don't have data like you, you definitely shouldn't. You should be quantitative, not qualitative, in looking at decisions of what to improve and what not to improve. For certain you should involve the whole team. Yep. E e every time that you can. And you, you should try to get the whole team learning new skills of the like for example, the one to one-to-one type of thing we talked about before. Mm-hmm. And you know, deal with new work and unknown work and stuff like that in, in its own little time box, its own little area so it doesn't blow up and impact and take over your whole thing. Um, like maybe a, a fair point. Maybe a fair point that we didn't talk about would be well, what if I deal with a lot of unknown support work, you know, whi, which I kind of also would've ascribed to like, well, you can have a kanban lane for putting out fires and Sure, sure. We, us, yeah. That's what we usually set up is a, an expedite lane or a fire lane. So, yeah, I mean, just because you have unknowns doesn't mean you can't use these techniques. Right? Yeah, absolutely. If you do these steps, eventually you get to a point where the work items end up being the same size and at the point where you, at the point where you have a team agreement, will we, where the work items will be the same size. We're not gonna estimate things If we truly believe that we don't know, we're unsure. You know what I mean? You're gonna get to a point where basically you're, if you all agree, one, two, and threes are threes or whatever, you know, whatever you pick. Yep. Or you all agree that like, Hey, if it's over eight, there's too much unknown. We don't want to deal with it, we need to break it down. You'll eventually get to a point where your refinement process kind of weeds all this stuff out and there's just no point anymore in talking about estimation. And you'll be living in the future. You will be, you'll be in the flow rate world. You'll be talking about number of stories per item, number of days, four days, five days, whatever days. Yeah. So hopefully this was useful. Certainly let us know other topics that you would like us to tackle. Go ArguingAgile.com and yeah, just like Clint did. I think that's probably it. There you go. There you go. Clint, hopefully we answered your question. Like, and subscribe folks like, and subscribe if we answer your question and if we didn't answer your question like, and subscribe Like, and subscribe Scribe Anyway.