S02-E07 Story Points vs. No Estimates: A Battle of Agile Philosophies – With Amanda Rae Arseneau

[00:00:00] Brad Nelson: Welcome to the Agile for Agilists podcast. I am your host, Brad Nelson, and with me as always is your other host, Drew Podwal,

[00:00:11] Drew Podwal: Hello.

[00:00:11] Brad Nelson: and it’s finally here. We finally have Amanda back, and we’re finally going to talk

about no estimates.

[00:00:18] Amanda Rae Arseneau: Yay. Hello again.

[00:00:20] Drew Podwal: we’ve been on the edge of our seats. Like, I don’t know if you’ve listened to some of the episodes, but Brad coming back from the conference and talking about the velocity trap and not talking about estimates was like murderer.

[00:00:34] Brad Nelson: Yeah. Yeah, it’s definitely come up multiple times. We keep teasing

people that we’re gonna arrange it and it’s here. We’ve done it,

[00:00:41] Amanda Rae Arseneau: Gosh, lower the expectations

[00:00:42] Brad Nelson:

Y’all. All right, so for those of you that haven’t listened to our last episode with Amanda, which I think pretty much all of our listeners have, it’s definitely by far our freak, most listen to

album or episode that we have, which

[00:00:59] Drew Podwal: our Led Zeppelin four.

[00:01:00] Brad Nelson: it is, it, it’s pretty great.

I think it was a combination of timing. We, it was really responsive to the news. Drew created this wonderful click bait title that really fed into it, and then it was just genuinely good content, so it was a triple threat.

[00:01:17] Drew Podwal: Yep.

[00:01:18] Brad Nelson: Uh, but if you haven’t listened to that one yet, I, I definitely encourage you to, it’s, I don’t remember the exact number, but

it was on the

Capital

[00:01:27] Drew Podwal: was also a part of the episode where we were trying to figure out what number this episode was and

[00:01:33] Brad Nelson: There we go. It’s very meta.

[00:01:36] Amanda Rae Arseneau: call backs.

[00:01:37] Brad Nelson: but in it, the, the concept of no estimates came up just casually through discussion like we normally do on our episodes. And we realize that Amanda and I, are mostly aligned, I believe, on the no estimates front, but Drew is standing strong for story points, and we realize that this is probably a whole episode in of itself. And so we’ve delayed this for, uh, months now, and so we’re excited

to

to, have this record.

And to, uh, to get the conversation going. I feel like I’m dragging out

way too long, so, all right.

[00:02:14] Drew Podwal: duke it out Battle Royal Rumble style.

[00:02:17] Amanda Rae Arseneau: Wait,

let’s even back up Drew. It’s not just estimates, it’s story points.

[00:02:23] Drew Podwal: am a fan of story points. and well, so why don’t we maybe start off by like saying each of our, our points for, for why we are pro and con.

[00:02:33] Amanda Rae Arseneau: Like someone

[00:02:35] Brad Nelson: All right.

[00:02:36] Drew Podwal: All right. I’ll go first on it. I, I actually have some notes that I’m gonna pull up. So first let’s just talk about the idea of refinement, right? Refinement of a story, A team should do that collaboratively together with everybody, with the product owner, developers, testers, we’re on the same page with there, right.

and that the act of refining a story and, and generating the acceptance criteria, , is boiled down to card clarity and confirmation, right? The, the alignment of, of what we’re taking on within this story, right.

[00:03:11] Brad Nelson: I think so. Yeah.

[00:03:13] Drew Podwal: And that the, the conversation is the most important

part there, right? We’re, we’re on the same page there.

[00:03:20] Brad Nelson: Mm.

[00:03:20] Drew Podwal: and that, when it comes to evaluating a story, and I’m using the word just generally evaluating or qualifying a story, that you’re looking at, the volume of work that there might be, right? How complex the work might be. what do we know about this story and what do we what do we not know about the story?

And then how much uncertainty or risk maybe exists within the story, how confident are we that we could, you know, just do this without anything going wrong. and so are we on the same page roughly still?

[00:03:54] Brad Nelson: Yes.

[00:03:56] Drew Podwal: Okay, so here’s where I think we jumped the tracks, right? I like the idea of then. Assigning an arbitrary Object. It could be a number, it could be a fruit, it could be an animal, That represents the team’s understanding of the volume, the complexity, the knowledge, and the uncertainty, it doesn’t need to be a number for me, but there’s two reasons why I like that.

one, it’s creating a shared language, right? Where maybe your product owner, has never really been a developer and there’s a misalignment in the language barrier there. And so it gives a person, like maybe even a scrum master who has never been a developer, a, a common language to say, if that is a.

Raccoon sized story, right? Or it’s a five, or it’s, a watermelon, That, that story has a heightened level of volume, complexity, lack of knowledge and, and risk to it, right? which then can help guide the team. And I find it, it’s been useful for me as that, that no-code coach or scrum master in the past to have that.

So now I could observe what teams are committing to and look for anti-patterns in, in what they’re committing to. Like for instance, most of the teams I’ve ever worked with, if they had more than one eight point story in a sprint, there was a really good chance that something was not gonna go well in that sprint, right?

And so if I see in their Plan that they’ve committed to two watermelons or whatever it is, right? It now is a, indicator for me of something that might be a coachable moment. And it’s not for me to say, we only can ever have one watermelon in the sprint. It gives me an opportunity to say, Hey guys, I’ve noticed that we’ve got two watermelons in the sprint, and based on our historic data, when we’ve taken on more than one at a time, we often have something that goes wrong.

What would you like to do about that? Is there a potential for us to split one of these watermelons? Do we wanna defer one of them? do we wanna talk about the risk and the uncertainty about one of them? Again, like what information could we maybe provide today to turn this watermelon into a grapegruit?

and so it’s a great shared language and it’s a tool that I’ve really think is valuable, and it’s a way that creates an wonderful representation of, of what it is that we’re really trying to get the teams to focus on. Right? and I’ll, gonna pass it back in a second, but the last thing I wanna say on that is , in high maturity teams where they’ve done lots of, of sprints together, They already have that shared language, they don’t really need that because they know how to work well together and how to communicate with one another to where they don’t need points. They don’t need objects to represent complexity, risk, and unknown. They’ve developed the chops to do that. All right? So what I’m talking about is really more for, for teams like early on to help them to, focus on what’s important, right?

When I do my workshops for story points, what I tell them is day one, It’s gonna be wrong, and that’s okay as long as we’re having conversations about it. And so at the end of the sprint, if something didn’t get completed at the end of the sprint, I’m gonna ask the question of what is it that we wished we knew at the beginning of the sprint that we didn’t know that caused this story to pop out the other side of it.

Right. And, you know, we said it was a three pointer or we said it was a tangelo. knowing what you know now, How will that help you to better estimate stories in the future? so that’s why I like it.

[00:08:00] Brad Nelson: clarifying question. When you say

Estimating what are you estimating?

[00:08:06] Drew Podwal: Estimating the, the volume, the

complexity.

[00:08:10] Brad Nelson: Uh, I mean like those are the, the factors that you’re using to decide the estimate, but like what items are you estimating?

[00:08:18] Drew Podwal: Stories.

[00:08:19] Brad Nelson: Okay. That, that was just my defining question. Like is it like stories?

is it tasks, is it defects? Is it, epics features?

[00:08:28] Amanda Rae Arseneau: Is

it everything?

[00:08:29] Drew Podwal: So,

okay, so the way that I look at tasks, is, um, have you guys ever heard of, poultry oysters?

[00:08:37] Brad Nelson: I’ve heard of it. I don’t know what it is.

[00:08:39] Drew Podwal: where, where the, the wing on a bird, whether it’s a chicken or a Turkey, meets the body, there’s a muscle there that’s, that, that looks like an oyster almost, right? And it’s, it’s the most delicious piece of meat on a bird, right?

It, it’s got The flavor of dark meat, but the consistency of white meat. And so they’re known as chefs, chef snacks because in restaurants, chefs will just pluck them out and pop them in their mouth and not serve them to the customer because they’re just that good. Right? And I refer to tasks as chef snacks, right?

We don’t bother with them. If the team wants our scrum master’s assistance and a product owner’s assistance and they want to have a level down below the story to further refine their work, that’s a space for them, right? That’s their private space. They can do it however they want to do it, and I’ll be a part of that to any degree that they want me to be a part of that.

But nobody beyond the team should ever have any sort of even working knowledge that that exists. And I also treat story points the same sort of way. They’re for the team and that’s it. They’re only for the team.

[00:09:51] Brad Nelson: Yeah. And then another clarifying question. When you say story, you’re talking about like, a product backlog item that fits within a sprint, right? Is it specifically a user story when we think about the true definition, like as a user and it’s a, a card for later? Or are you just more

referring to kind of like that level of ticket item?

[00:10:14] Drew Podwal: I would say that level of ticket item with a few caveats, like, so first of all, enabler stories I believe should be estimated as well. I also think that most enabler stories, if you think about them deeply enough, you’ll realize that it is connected to user value, right? The idea of like sun setting a microservice and standing up a new one, you’re not just replicating what

existed.

You’re doing it to solve that, that microservice solves a user function, and so those should be written. With connectivity to a persona as well. Um, it’s not just like this tech only story. I think that if you shake the tree enough on that, there really is no such thing as tech only stories if you’re doing it right.

now for like defects and bugs, the way that I quantify a, a bug is, a bug is something that gets found within the sprint and it gets attached to the story, right? It’s just a, maybe a task attached to the story. It’s not a standalone object, but a defect is something that gets found in a higher environment, maybe in production.

and, uh, I believe that it’s good measure to, well, it’s definitely great measure to refine a defect, right? And I’m, I’m not a stickler to this to say that all defects need to be estimated. But there are teams that I’ve found that have found that very helpful, and it helps them to then slow the process down a little bit.

Like, that’s another thing that I, I, I use whether or not a story has an estimate or not as the, the canary in the coal mine. If I start seeing sprints stories and sprints that don’t have estimates, I know that they haven’t been refined. Um, because estimating is the last act of refinement, at least the way that I, I coach, you know?

[00:12:10] Brad Nelson: Gotcha. Yeah, and I, I do defects and bugs the other way around, but that’s part of the problem with our industry is like, there’s not great consistency and a lot of times people just default to whatever their ALM is configured to B, which is why I asked the clarifying question on the story is like, I believe out of the box Jira, they’re all called stories.

Whether you, you’re using user stories or not,

you know, In um, I don’t know what they are in version one or, or.

And Azure DevOps. Their

[00:12:40] Amanda Rae Arseneau: they’re, they’re lovely called, yeah,

bbis.

[00:12:43] Drew Podwal: Well, and the thing is, the reason why I think it is good to quantify a numerical value to your, your defects is now you can quantify the tax, you could say, all right, we’ve got x percentage of story points that we’re working on versus X percentage of tax, right? and it’s a great way to then, use that to show leadership as a way to maybe decrease the team’s capacity a little bit and slack it up on it and give them more autonomy to fix and resolve tech debt, or increase the number of enabler stories that are designed to improve performance and things like that.

so.

[00:13:25] Brad Nelson: All right. Awesome. Well,

Amanda, What are your thoughts? Rebuttal. You’re up.

[00:13:32] Amanda Rae Arseneau: I mean, well I kind of feel like you should go first cause I’m just gonna go straight to the

other end of the spectrum. Um, but, but I’ll gladly just go, uh, there already. Um, yeah, so for me, and it’s funny cause I was listening, I was brought back a good, good decade there and I was like, oh, I remember when I used to, I remember when I used to wholeheartedly believe this was the best, most useful stuff ever.

And it’s kind of actually a really good feeling. And it might made me wonder why I felt that way where I was like, this makes me feel safe. This makes me feel like I can make sense of it. It makes me feel like I have control. It makes me feel like. I understand what’s going on, but when I have that feeling, I have that feeling as a scrum master or as a manager, or as a leader.

I definitely didn’t have that as depth And even when I do hear this from devs, it is almost always because that’s what they’re looking for. They want rules, they want comfort. They want someone to tell them how to do it without even bothering to care why. And the worst part of estimation is that almost becomes a religion, and you have.

You always on a team, unless you’ve ever had one that was all like, Woohoo. Yes, let’s do estimation from the get-go. I’ve never had a team that’s all like, let’s do estimation. You have one or two people who are like, it makes sense. Um, and then you have the rest of the team going, oh God, like a three.

and so you’re, you’re dealing already with like, okay, yeah, maybe it gets them to storming faster. That’s a plus. for me it’s like you’re always bypassing into okay, good rules and then you’re stuck in the process for the sake of process. And then you’re stuck in Scrum for Scrum and then you’re stuck in My scrum master is a rule, rule person who is here to book meetings and run them and make sure that we have numbers that work.

I have like 50 other points, but I think that for me, I was, when I was like, oh, this feels so good. That’s where I check it. Cause I, I a hundred percent know that’s where it’s coming from. And when we start talking about the process, when we’re so focused on the process, we’ve just completely missed the point.

And companies stay there forever. Teams stay there forever. Individuals can stay there forever just because it makes them feel good. And that’s not Agile, like, that’s static. I understand. Or I believe that I I know and I can trust it. Like part of our job is to get them very familiar and comfortable with change.

And I don’t, I just don’t see estimation pushing us in a way that really allows for that.

[00:16:21] Brad Nelson: I’ll add to that, that I as well, uh, I would say had a very similar mindset at one time to what you just explained. Drew. in fact, if you go on my LinkedIn, I have an article that I actually published on LinkedIn about it. Uh, and I thought about taking it down, but I was like, you know what, no, I’m gonna leave it.

Cause it

shows that I’ve changed, right? That I’ve grown. And that’s okay.

[00:16:42] Amanda Rae Arseneau: that needs to go in the show notes,

[00:16:44] Brad Nelson: Yeah. Yeah. We’ll do it. Yeah. Yeah. And actually it was in response to, a publication of Mike Cohn. And so Mike Cohn does not use story points at the sprint level. He uses ours, just like Ron Jeffries uses ideal developer days.

And so it is definitely not a unanimous thing across our industry of our thought leaders to use story points. And it, and it kind of feels, at least to me, it felt like that was the case until you start to see these other things. Now, Mike Cohen does teach story points, but he uses them at a much higher level and uses them as more of a lagging indicator. I will agree that story points have benefits to them. For example, like you said, Drew, I, is this too big? You know, it helps with having discussions. Do we truly understand the work at hand? Are there dependencies? Right? It encourages facilitation, it encourages, um, predictability, right? That’s what we often say.

Predictability. We use relative estimation. I was surprised you didn’t say t-shirt sizing, cuz that’s usually the, the next alternative, not fruit, but, uh, I guess you’re, you’re being a little fruity today, Drew. There’s the pun. Uh, and and, and I’m never going to go into a company and say, you have to drop story points. In fact, I’ve had teams that preferred hours or ideal days, and if they work for them, ultimately that’s what matters. However, I think that there’s a better way,

queue infomercial.

[00:18:24] Amanda Rae Arseneau: please use

your, your best ad voice moving forward, Brad.

[00:18:27] Brad Nelson: ah, I haven’t practiced that yet.

[00:18:29] Drew Podwal: Are you tired of story points then? Brad’s approach might be right for you?

[00:18:36] Brad Nelson: just dropping. I, I don’t know how you drop software. But yeah, I, I think that there, there are better ways to go about it and there are alternative ways. And in the last episode, one of the things that I said was that it’s one of the hardest things for developers or or anyone to really accept, right?

It’s like a foreign concept to us. And it’s the thing that I f I spend the most time trying to explain to people. And they’re like, well, what is effort? Right? His effort time, his effort size. In the last episode I gave the example of if you walk a long distance or run a short distance, what is the effort of one versus the other? Drew, uh, was being, I don’t wanna say difficult, but gave me the answer that no one else has ever given me, which is the walking is harder. But the whole idea is that some things are harder to do, but take less time. A and some things take longer time, and if they don’t fit in the sprint and they take longer time, but you estimate them lower, like that’s where you get some of that variance. There’s also the law of averages. As soon as you average something, it’s wrong every time or most of the time. So there’s, there’s like a lot of factors that go into it. And there’s alternative metrics, which I think is where Amanda was talking about going next, where it’s like there’s alternative metrics that we can use that are more efficient.

Research has proven them to be just as

accurate, if not more accurate, and they take less time from the team.

[00:20:03] Drew Podwal: Well, okay. So from a metric perspective, I see story points as a team only metric, right? Um, the other side of the coin though is so in, in my experience, the normal story that I see is you’ve got uh, Scrum team that’s like attempting to do Scrum. There’s a lot of undocumented work. and work rarely is sized appropriately to be able to fit within the confines of a single sprint.

and leadership is just, cramming more and more, And so for me, the other use of a story point that I love is it gives the voice to a, a dev team to say, Here’s tangible evidence that we’re being overworked, right? Um, we need to.

Run an experiment where for the next sprint, we only work on X number of story points. And we believe that if we limit ourselves to 32 or 23 or whatever that arbitrary number is, That we can meet every single one of our commitments. You know, and we just asked during this experiment that, you know, you not add or change things that are in the sprint, that you don’t backdoor things to anybody else and that you just let us run this experiment.

cuz, cuz I find that developers and business stakeholders, they speak a completely different language and, and it’s really hard to create that shared language between them. But being able to see the metrics for, Why things are actually unachievable and unsustainable is, is helpful to then put a stake in the ground and say, no, the team cannot take another story in this sprint.

32 points represents the total volume of complexity, uncertainty, and risk that they feel confident being able to work on in a single two week sprint. and it, it creates that line in the sand that, you know, helps business stakeholders. You can grab ’em by the back of their, their neck and be like this is why.

And, and I’ve found that that’s been very useful.

[00:22:19] Brad Nelson: A, and this has been stakeholder management by

Drew. Podwal.

[00:22:22] Amanda Rae Arseneau: yeah, just treat him like a little puppy. Uh ooh. Actually, anyways, maybe that’s another episode. Uh, can we go back, because you have said a couple times now that story points are for the team only. Um, and yet now we’re saying we would use them to basically barter less with the business stakeholders and to tell that story, which predominantly is usually the reason, the first reason we give for using estimation or why we’re forced, and I will say forced to use estimation.

Um, also safe is like the, the poster child for leveraging them as metrics and bubbled up, et cetera, et cetera. So can you kind of explain

how you deal with that without it becoming then the velocity trap?

[00:23:11] Drew Podwal: I just don’t let it, right. Like as soon as I hear people talking about like, can’t the team increase their right. To me, if the team has said that their, their comfortable capacity is 32, And we get to a place where after a few sprints They’re meeting that, I might ask in a retrospective, Hey guys, I’m noticing that we’ve been hitting this number with, with severe confidence, right? Um, it’s been six sprints right now, and, um, this is not my decision. This is your decision. but do you guys still feel comfortable with that commitment? and, would you be willing to experiment with adjusting that now that you’ve gotten a few more cycles of, of working together under your belt?

And if the team says, no, we’re not ready for that, then the team’s not ready for that. And, cut my teeth as that project manager who loved the fact that my, my teams were wanting to work in Scrum and it was. My absolute chief duty to protect them and their process. And so I take the same kind of approach as a coach and a scrum master is I’m protecting the people who were making a commitment to try and making a commitment to improve.

And, and I will go to, I’ve been fired, I, I will never have been fired, but I’ve definitely not been asked to continue my contract, As a result of being that team protector, you know, to make that, that space coveted. and so, yeah, I, I won’t allow on my watch anybody to start to analyze team’s velocity, In an unhealthy manner. the thing that I say is that a team’s capacity is a representation. in number, form of the total combined quantity of risk, complexity, volume, uncertainty, and knowledge that the team feels that they can confidently commit to within a sprint.

that’s what capacity represents, right? their velocity is an indicator of their performance as a team together, and the team uses that as an indicator to help guide them towards improvements. Now, I get your point, Amanda, the idea that not all developers want to do that. I, and I’m okay with that, right?

Like, I, I only bring these, these tools as, as options and ideas for teams to try based on different, impediments that they’re facing. what I. Do talk to them about is, in refinement, The questions that I ask as the facilitator when I’ve been a scrum master, I use, , fist of five vote of confidence, right?

Um, you know, how confident are we that we’re gonna be able to finish this story within a single sprint, and then at the end, in, in sprint planning, how confident are we that we’re gonna be able to. meet This goal. And for me, five is we got this in the bag, Four is, it’s gonna be hard, but I’m confident that we’re gonna do it.

Three is, you know what? I don’t have a high level of confidence, but if everybody else is willing to go along for the ride, then I’m putting my trust in our team unit. Two is, I can’t go along with this. And one is you’re all crazy. and if anybody votes one or two, then I ask them the question of what is it that you’re seeing that we’re not seeing?

What is it about the sprint plan or what is it about the story that, that you’re not seeing? So I love using Fist of five in absence of story points. but I find the biggest challenge is helping teams to realize that they really need and want and should want to ensure that all of their stories are small enough to fit within one sprint.

And I found it be very, found it to be a big struggle, to get there without. story points, fist of five it’s a great way of, of helping everybody see what everybody’s confidence is. And I’ve actually had times where everybody put up a three and I was like, well, what you’re saying is nobody on this team believes in this plan.

but they’re willing to go along with it if everybody else is, and nobody is saying that they’re standing up for the plan. So, like, what does that tell you guys? what do you wanna do about that?

[00:27:44] Brad Nelson: One of your points, or I guess a recurring theme that I’m hearing as you’re describing it and like you mentioned, it’s like evidence. Well, one of the things that I like about it is also one of the things I dislike about it, and it’s that it’s science-y It seems like it’s science, but it’s really not. and so you’re, you’re kind of making it up and it does serve a purpose, but at the end of the day, you’re, you’re still kind of making it up. It’s still not accurate. And so there’s a danger there as well. and, and it is just gonna keep going back again. to like when there’s metrics that do those same things that are science, that are, evidence-based, why not use the ones that are evidence-based

[00:28:20] Drew Podwal: So you’re talking about like flow metrics, right?

[00:28:23] Brad Nelson: correct.

[00:28:24] Drew Podwal: Yeah. And value metrics.

[00:28:26] Brad Nelson: Yeah, well, yeah, I mean we’re, we’re talking about performance and productivity in this particular podcast. You know, I would say, right? Like value metrics are the most important metric. If you don’t have value metrics, then why, why are you even a business?

[00:28:40] Amanda Rae Arseneau: Why are you building anything?

[00:28:42] Brad Nelson: Um, but story points aren’t value. But that is, that is the velocity trap.

I love that you used those words, Amanda, but, um, the velocity trap is that we think that just because we’re measuring something that we’re, we’re delivering value and it’s a productivity metric, meaning it means we’re busy. It’s like butts and seats. Just cuz I’m punching the clock doesn’t mean I’m doing anything. And so that’s the trap as well as it gets used as maturity and like competition. And there’s all sorts of other bad habits that go with it. the act of story points and the things that it teaches a team to do outside of the actual, like primary use of story points. Are the most beneficial components of using story points, but as soon as you start moving into velocity and that sort of stuff, those dangers encroach and there’s a better way.

[00:29:34] Drew Podwal: and I agree with that, you know, and, and the way that I always teach it is, I do this activity called Throw the Cat, and I advertise it as a,

[00:29:43] Brad Nelson: Drew is just so mean to animals. We are just

[00:29:45] Amanda Rae Arseneau: It’s just

[00:29:46] Drew Podwal: I learned this one from,

Dave Pryor at Leading Agile. I took my C S P O with him way back when, and he used this activity as, as a way to teach story point estimation, and it really just stuck with me, and so I advertise it as a workshop for improving story point estimation or learning how to use story point estimation. But what it really is, is it’s a workshop in team collaborative. And so the way the activity works is the instructor takes sticky notes. Um, we love our sticky notes and you write like various objects on each one, right?

So one is a cat, one is a bat, one is a Jaguar, one is a spool of rope. and, and the way that I set up this exercise and the way that Dave taught it, is that for this exercise, once it starts, I am the product owner. And each of these are a story that we’re gonna be refining together. and the goal for the exercise is to, once you’ve refined it, determine which Fibonacci value one through eight does the. warrant, right? The acceptance criteria for each of the stor for the each of this is that you need to be able to throw this object 15 feet in this room without it damaging the object or damaging the floor.

And so, that’s all the instruction that I give them. And so usually everybody’s kind of like talking to each other, but nobody’s talking to me anymore, right? I make it obvious when I say I am the product owner, but nobody really takes that to heart until about like maybe five minutes in when the first person thinks about it.

And it’s like, Jaguar, is it the car or is it the animal? depending on how I’m feeling that day, I either say it’s a car or it’s the animal, And then they stay, well, wait, is the bat. Like the animal or is it a bat? And then I always say it’s actually a, a vampire bat and it’s got rabies, and then they’re, they start really scratching their heads and I’m like, okay, so listen, I’m your product owner, right? We’re in a scenario where I’m asking you to throw these things 15 feet without damaging the object or damaging the room. What is it that you need to know in order to be able to figure out if you can actually do this at all?

Right? you know, do we need legal to come in from a PETA perspective? Do you need to create a special throwing and catching mechanism for the Jaguar car? let’s think this through for a minute. Like, you know, what are the things? And and that’s when they actually start really having the conversation and start thinking about things like, splitting, or this is just way too big for us to deal with.

or in order for us to do this, we do need to build a thrower and a catcher. and so we need, stories for that. Right? and, you know, usually we never actually even get to the point in that activity where anybody comes up with a numerical value to say, this is an eight, or this is a three, or it’s a five.

And I’m like, totally okay with that because now I’ve gotten them to a place where they’ve unlocked their ability to realize that they have the permission to push back on a PO and say, we should split this, right. and start to think about the complexity and the risk and the unknown. And if in our first refinement session they refine like, everything wrong, well now that’s just a baseline.

And in the next one if it’s, you know, some of them are wrong and some of ’em are more right. You know, the baseline is now getting a little bit more accurate and it’s never like you, to your point, it will never be accurate. it’s purpose is not to be a science of accuracy.

It’s really just there to be a guide that guides the team from a place of never really thinking in this way before and never behaving in this way before, to getting better at thinking in this way and getting better at behaving in that way.

[00:33:55] Amanda Rae Arseneau: But we’re talking about story splitting now, and we’re talking about understanding how to split well and deliver small value, big value in small, in small little parcels. this is a lot of overhead of learning just to do what is also a very, very hard skill to learn, which takes a ton of practice.

Is the payoff worth it?

Speaking of value,

oh,

[00:34:19] Drew Podwal: Yeah, because I don’t if we get into a refinement session where, half the team says it’s a three and half the team says it’s a five, my question is, is there anybody on the three side of the house that would be very upset if we just said, this is a five or is there anybody on the five side of the house that would be very upset if we assign this as a three and if nobody speaks up

[00:34:41] Amanda Rae Arseneau: But isn’t the question,

can this story be sl any further?

[00:34:45] Drew Podwal: well that

[00:34:46] Amanda Rae Arseneau: Like is there still value to get, if we were to shave this off in another way, or is there a different approach like

Three or five, you’re gonna get people being like, yeah, cuz I don’t wanna have the discussion, or, yes, I

[00:34:58] Drew Podwal: and that’s okay. To me, that’s totally

[00:35:01] Amanda Rae Arseneau: but you might not get

the, there was another way to split this and we could have actually like leapfrogged this entire

[00:35:08] Drew Podwal: Oh, well no, the splitting happens first, right? The question of is this story the right size for, can it, can it be done in a single sprint? the sizing component or the, the numerical value component to me is the last thing on the chain, And, and if they decide, no, it can’t be split and maybe it should have been split and it pops out the other end of, two sprints, let’s say.

That’s their, that’s their bar mitzvah. It’s, you know, I’m just here to, you know, read the,

yesterday was Passover, but I’m just here to read the Hof tour portion.

[00:35:43] Brad Nelson: So question for you, Drew. How many developers are on a team?

[00:35:47] Drew Podwal: How many working members are there on a team?

[00:35:49] Brad Nelson: Yeah.

[00:35:51] Drew Podwal: Doesn’t scrum suggest seven to 11? I forget now.

[00:35:55] Brad Nelson: Uh, it’s three to nine, but, um, it, I mean, so you’re saying at least three, we’ll say right from, from my question, how many product owners are there on a team?

[00:36:05] Drew Podwal: only one.

[00:36:06] Brad Nelson: So why are we teaching three plus people how to split stories instead of one

person how to split stories?

[00:36:12] Drew Podwal: so I also like the idea of, a product owner writing features, maybe creating placeholder stories, but that the team should be refining features into stories with the product owner, The team should be writing those stories with the product owner.

[00:36:30] Brad Nelson: I mean, I’m not against that. I, I’ve actually written stories as a

scrum master with the team without the product

owner. Uh, that was an experience.

[00:36:38] Drew Podwal: Then you weren’t a scrum master dude.

[00:36:40] Amanda Rae Arseneau: we we are the

same people,

[00:36:42] Brad Nelson: well, and, and I was supposed to be mentoring that product owner who used to be a scrum master, which made mentoring really hard. but I mean, once again, it, it really depends. Most of the high performing teams that I’ve worked with, or when I’ve been a BA or a product owner, my guidance is always, The story should be like 70, 80% written.

When it comes to the team. You’re coming to the team to finish the details and to get validation that you’re on the right track. You’re not missing something. And the reason is it’s more about efficiency than anything else. There’s nothing worse than a refinement session where everyone is staring at one

person typing.

[00:37:18] Drew Podwal: I would say that the, the use case for a team where they all create the stories together and, you know, also a, a three person team or a nine person team is a very different dynamic as well. Um, what I’ve seen a lot of is product owners coming to the team. Like I’m seeing so much, so there’s so many AI tools that are out there right now that are being, targeted towards product owners for you put your feature in, we’ll write your stories and you can just chuck them over the fence at your team, and it’s just terrible. It’s the wrong way to use ai. But, um, that’s what I’ve seen a lot of is a product owner comes, you know, walking into a refinement session with their, you know, ready-made stories and they behave in a way that doesn’t even allow the space for the team to like, do anything other than say thank you for the stories, buddy.

Um, and that’s a cycle that’s gotta be broken, you

know?

[00:38:14] Amanda Rae Arseneau: Yeah, I, I’m gonna chime in here cuz I am, I am fully against, uh, stories being written in silos, uh, because I see it in multiple ways. I see either the po writing them and delivering them, or a team. team deciding to have one person write stories and, um, very quickly, no one, no one’s actually talking about how they’re gonna implement it, ensuring they’re on the same page cuz somebody else did the admin work and who the hell cares.

and then from the product manager side, or product owner, there are some crazy assumptions about how you can build software. Um, Usually within those splittings I’ve seen product managers come and I get it. Yes, coach ’em. Um, but some are very hard to coach and they’ll come with like, add this thing to the a p i, They are not technical. They don’t even know what the A p I is or, um, well I thought that we could split it to, you know, all of these things and the teams like, actually, well, yeah, that’s fine. Right. Again, like they don’t, they

stop critically thinking about anything because we don’t give them that space to do

it.

[00:39:20] Drew Podwal: think

[00:39:20] Brad Nelson: let me throw out a, uh, like perfect scenario to me, which once again I’m talking perfects rarely

happens. Uh, you might even say it never happens, but it has, you start with, with me, only me. Uh, that’s why you should hire me and no one else. No, um, whatever your higher level, ticket type is, if it’s a feature, if it’s an epic, if it’s capability, if it’s a project, I don’t really care what you call it.

Call it a watermelon. If you’re Drew, this is like a, a value request. This is the thing, the, the problem I need solving. This is the value I’m asking for. At that point, you should be doing a story mapping session where as a team, you’re breaking the stories out and you’re saying, this is how we’re going to attack this problem.

From there, there’s busy work is what I’ll call it. It’s not really busy, but it’s like somebody has to do the work of kind of fleshing it out a little bit. That is the, the work that I’m referring to when I say like 70, 80% ready, like have one person like kind of take that away, or maybe it’s multiple, I don’t really care.

But in most scenarios it’s usually the product manager, product owner, BA is taking those away so the developers can develop and then they bring ’em back and they say, Hey, you know, I, I filled this in. Is this right? Is this accurate? What am I missing? Is there a better way to do this? Am I is something wrong? And that is really, once again, just about efficiency based on skill sets. And if we’re really being, I’ll say maybe a little cynical, it’s because a BA

costs less than a developer.

[00:40:54] Amanda Rae Arseneau: not sure a product manager does though, just so So we’re

[00:40:57] Brad Nelson: True, but they also have, uh, the, the value tie-in and stuff too, right there, there’s benefits that a product manager brings and I don’t like when a product manager hires a BA to do all that stuff for them, cuz then we’ve created

this telephone thing again that we’ve worked so hard to

get rid of.

[00:41:13] Drew Podwal: I agree with that as well.

[00:41:14] Amanda Rae Arseneau: Yeah.

[00:41:15] Drew Podwal: you know, the other thing that I’ve seen is that where product owners are kind of checked out, And they maybe will come in with a user journey, right? but more likely like

a

[00:41:25] Amanda Rae Arseneau: seen that once,

[00:41:26] Drew Podwal: A P R D, product requirements document, and then, Review that p r d with the team, and then the team’s expected to write the stories. And then in those cases, the stories are always tech only stories, they’re like more like at a task level as opposed to at a slice of functionality, outcome level. but I still kind of feel like, I love the way that you framed it, Amanda, where you’re like, you know, I remember way back when, when I, when I felt like, you know, having story points was this comforting thing that gave me a sense of control. And, and I thought about that for a moment and I think that there, there is some validity to that, right?

Cause that’s real. Look at what I’m saying is it creates a shared language, right? but I still feel that. In many circumstances that I’ve experienced, at least, it can be a great tool that can help teams to accelerate to a place where they’ve got that shared, learning.

And we talked about in the last podcast with Todd, where we’re talking about, he said this great quote, and if you haven’t listened to this episode Amanda, this is a really good one to listen to. , he said frameworks are a great place to start and they’re a terrible place to stop.

And I wholeheartedly agree with that, the idea that like, you know, user story points to me, it’s a great place to start. It’s definitely not the place to stop, right? Like, and I think that, well, let me actually pose it this way. if I set it from that perspective, are you guys maybe down off the ledge of a, a little bit to say that I think it can be a useful tool.

That could be a great place to start.

[00:43:02] Amanda Rae Arseneau: I think you said this last time. I’ll let Brad go.

[00:43:03] Brad Nelson: Uh, I will say I have used it that way and, and through experience in trying it out. I would say once again, it depends. Maybe some people need it. Usually, like I still give story pointing workshops when requested. I’m asked to do it. I teach Scrum, I teach common, I teach Nexus, I teach safe, I teach all these frameworks even though I’m like the anti framework guy, uh, out of the two of us, at least verbally, uh, I do whatever the client needs.

With that said though, I still think that an ideal

scenario, you can skip all of that.

[00:43:40] Drew Podwal: Well, that’s the point. in an ideal scenario, you could skip so much of what it is that we coach, right? Like that’s why in the last episode I said I think it’s an overreaction, I think the no estimates movement is an overreaction. To a real problem. Right?

And, and like,

[00:43:58] Amanda Rae Arseneau: But I feel like,

there are so many ways, like aside from the shared language, which I think to, if anything came outta this for me, I’m like, okay, yeah. Shared language. That’s a valid, that’s a good one. there, are there other ways to cultivate that? Yeah. but it’s probably the, the strongest because the rest of them all either have to be done as well or have to be learned as well, and have to be practice behaviors.

I think my one thing about story points is always about the fact that it’s, it’s a lot of cognitive load for stuff that you have to do anyways and you’re gonna have to learn anyways that is actually divorced from story points, unless you’re looking at more of. that Velocity metrics. trying to understand how when something will get done, because you are talking about predictability and estimates and things don’t, that don’t exist in any common sense land.

And I get it, business is not a common sense land. but it’s, I don’t know it, again, I’m not a consultant, so I have the luxury of being like, no, you wanna do story points? Cool, let’s go. Have a long, long chat over coffee about what you’re experiencing as a problem, because I guarantee you it’s not the answer and it never is cuz it’s not the pain point.

Pain point’s, always something else. The pain points. We don’t understand how to implement, we don’t understand how to talk, we don’t know how to talk about any, anything. We don’t know how to talk to our product manager. To your point of shared language. or simply there’s too much work and then like, high whip limits or the, and your proof is that nothing is coming out the other end because there’s 20 things in progress in

three developers,

[00:45:43] Brad Nelson: Yeah, well, the thing with story points is it’s an effort. There’s an effort that goes into estimating. It takes time, it takes effort. There’s effort in learning it. There’s effort in applying it to velocity. Whereas statistically speaking through research, people trained in research, people with doctorates that are way smarter and better at this than me have shown that teams consistently deliver the same amount of items in a duration. Whether it’s a week, whether it’s two weeks, whatever it is, and if it’s inconsistent, it’s the same problems as if your velocity’s inconsistent. It’s, they’re too big, they’re not understood well enough, so on and so forth. And so if I could get you the predictability and all of the other things that you’re asking

for with zero added effort, why wouldn’t

I do that?

[00:46:37] Drew Podwal: Okay. I mean, that’s a fair assessment I think. I just don’t understand so if now we’re just looking at the number of stories, right? I think that’s what you’re saying is we’re looking at the number of stories, right? ,

[00:46:49] Brad Nelson: It’s more than an average, but yes.

[00:46:52] Drew Podwal: all right, so we’re in a, sprint planning meeting.

We’ve got 12 stories the team is committed to, how do you know, then at that, In a sprint planning session that the team is actually maybe not realizing something.

[00:47:09] Brad Nelson: so I would say one, it doesn’t matter, like research has shown that it doesn’t matter It’s the same, like people will say like, oh, all the cards have to be the same size. They don’t, research has shown over time, it does average out. there are other things though, if you put card aging on there, that’s a great.

To kind of track, oh, this was very large. It took us extra amount of time, there was extra dependencies, whatever it was. There’s ways to, to track that sort of stuff and to learn from it. but I will say once again, like, let’s stop making excuses for product people. we have a serious problem in this industry, in product.

There’s some amazing people out there. Uh, most of them hate Agile Agilists, by the way. and like there, there’s, um, Teresa Torres wrote a book, continuous Discovery Habits. I actually, on LinkedIn was like, eh, I think this is a little extreme. And she called me out and she was like, what was so extreme by it?

And I was like, uh, I don’t remember, uh, so point to her. But I, I do remember it just being kind of an ideal scenario. Once again, we’ve said that several times and some of the stuff just didn’t seem to align with my experiences. But with that said, how, how did we get Scrum Masters in the first place?

How did we get Scrum teams in the first place? We, we train them. And so I think as an industry, we have to commit to training them. And if you’re a Scrum person, the Scrum guide specifically says you serve the team, the product owner and the organization. And yet, most Scrum masters that I coach are only focused on the team.

And most managers, that’s what they expect is that you’re only focused on the team. And then they throw on the PM works, they’re like, oh, you have extra time. And I’m like, do they, they’re only doing one third of the job.

[00:48:53] Amanda Rae Arseneau: One third, like 1, 1,

6. If you go

[00:48:56] Brad Nelson: yeah, if we’re talking bullet points, but yes.

[00:48:59] Drew Podwal: I, I actually use those three bullet points of service to the team, service, to the PO service, to the organization as the performance metrics for a scrum master, right? it’s my belief that early Scrum masters, they’re getting their feet. Wet and steady with being in service to the team.

And maybe they have a hard time learning how to manage up to be of service to the product owner. And that, you know, as they get their feet wet there, then they start getting their feet stable again and being able to work with stakeholders, right. To provide coaching to stakeholders as well. And so I I, I do love that.

I love that the scrum had says that. I think it’s fantastic. I’ve had teams before where, when I came in on day one, there were stories, multiple stories, not just one or two that had been rolling over Sprint to Sprint to sprint, some of them six sprints, And when I, kept going with them, I would say, guys, this story has been rolling and rolling and rolling and rolling, Do we want to, at this point, split this story, what is the outcome that you think you can actually achieve with this story at the end of this sprint?

Do you guys wanna take the time? And then they were like, no, we’re gonna finish it this sprint. And then like, still like three, four sprints later. The denial of, that particular organization, the product owners, it was lazy product ownership. it was easier for them to allow their developers to have their Dev only work, Than it was for them to lean in and work with them, to connect those stories to value, And work with them to split them. And I don’t know. I still think that story points are useful in that kind of circumstance. All right. Because you’re able to at that point. Right. Because usually when I see that it’s always, you know, Jim or Barbara, they own that story. They’ve been working on that story for the past six sprints.

That’s their story. They know what it is. The rest of the team doesn’t know anything about it. Right. Um, having the ability to, to do story pointing on it, allows everybody to weigh in, in a safe way. without the risk of, of harm or foul or injury.

[00:51:12] Brad Nelson: Yeah. I, I would say usually in those situations nobody else

knows the work, so they’re just like, I defer to, to Jim or Barber,

[00:51:19] Drew Podwal: yeah.

[00:51:20] Brad Nelson: said, sorry, I cut you off, Amanda.

[00:51:22] Amanda Rae Arseneau: And they, they still have to like explore, It’s tough to explore what was actually. What is the work going on there? I mean, God, six sprints, what is the work that seems magical? Um, normally when I see something like that, it’s just because nobody ever got around to it or they forgot it’s in development cuz they don’t look at Jira.

And maybe that’s where we start. But, um, you, you still have to talk about the work. You still have to start questioning and again, hopefully in a safe way, but hey, maybe not. Let’s storm. what, what is supposed to be the outcome and how can we break this down? And I, again, like you still, you still have to do the meat potatoes.

even when you sprinkle little parsley on top, it’s, it’s not really actually

where the good stuff is.

[00:52:04] Brad Nelson: Yeah.

that was where my

[00:52:05] Amanda Rae Arseneau: Sorry, to anybody who loves parsley.

[00:52:07] Drew Podwal: you ever been in an organization where like all the developers are heroes

and

[00:52:14] Brad Nelson: Yep.

[00:52:14] Drew Podwal: like, will,

will not,

yeah.

Will not admit that maybe something’s too big, and,

[00:52:22] Brad Nelson: Yeah, for sure.

[00:52:24] Drew Podwal: will not admit that they’re taking on more work than they.

[00:52:28] Brad Nelson: But usually to Amanda’s point is that it’s not, it’s usually not the ticket itself that’s too big. It’s the amount of items they’ve taken on. And I had a team I used to tease, uh, when I was just, I was helping them with their daily scrum, cause they’re a scrum team. I would observe scrum master, uh, for this team.

The scrum master typically facilitated it. And then when was done, I would see, like they, they assigned tasks. It was a physical board, they assigned people’s names to the cards. And I’d go up to the one guy and I was like, Hey, I see you have three items in progress right now. And I’ve seen the nineties hacker movies where the hackers are, are typing on two different keyboards at once or running down thing. And, and I haven’t seen you doing that. So are you actually working on all three of these things at once? Or can you actually only work on one at once? And like I threw a little bit of humor in there and they’re like, oh yeah.

And, and I would get a laugh out of them. And doing that enough, they started to realize like, oh yeah, let’s finish something before we

start something else.

[00:53:33] Amanda Rae Arseneau: Yep. And then it’s, especially with the hero complex, right? Maybe it’s more about priority. Maybe it’s more about taking time for knowledge transfer. maybe it’s actually that. They really are working on two or three things because they, those tickets weren’t even ready to be, they’re in the first place.

I don’t wanna get into definition of ready, but, they took something on that had dependencies externally or needed input, and it’s just sitting there because they’re waiting for that person to email them back or a ticket to finally get through another support system. and then they can work on it.

And then they actually just mean, mean to, you know, actually learn how to block

tickets properly and have an actual signal for that. So we know what they’re working

on.

[00:54:13] Drew Podwal: I will say in that organization, the thing that helped me to get everybody unblocked from that mindset and move forward was, at the issue level, right? Not at a story point level, what I did was I, created a new issue type in Jira called unplanned work. and then there was an issue also already there for defect, and a story and an enabler story, and so at the end of every month during the, the full company presentation, I would show, you know, the percentages of where time was being spent, , and. You know, I would ask people like, what, what do you see? Right? Um, they’re like, oh, we see that there’s actually more defects being worked on than stories , that are being delivered, right?

Um, there’s more unplanned work than there is planned work. And I would say, well, what do you want to do about that? Right? How do you think that that’s hurting us? You know, so I, you know, it remind me, I did not need the story point value to show the size of the defect versus the size of the story versus the size of whatever, right?

and I guess I probably could have used, cycle time to say that like from the, the time that it entered into the queue to the time that it was marked as done. But I really, I don’t like hours anywhere. Like I get really, really anxiety ridden whenever I hear anybody talking about hours anywhere near the Scrum team.

[00:55:39] Brad Nelson: Yeah, Menlo wrote a book, joy Inc. Where they shared their process and it’s very cool. I, I don’t know if I’ll ever do it, but they, they use paper, physical paper, and a piece of paper is a day, and then in half is half a day. Folded again is two hours folded as one hour. And then they make their actual capacity, like in paper, put it on a table and they say, Hey, stakeholders.

And, and they’re, uh, a boutique shop. So their stakeholders are always external customers. They’re like, you know, we’ve estimated the work for you in hours. Fill up our

schedule.

[00:56:19] Drew Podwal: do they use the same. Point font

[00:56:22] Brad Nelson: yeah. I, I, I don’t, I don’t have that much details. They do free tours as well, virtual ones, even if you request, it’s a really cool, kind of cute concept and it works great for them. Like I said, I don’t think I would ever try it,

but that is an example that it’s been published that supposedly works.

[00:56:39] Drew Podwal: and suddenly all of the thick chisel tip sharpies were removed from that company.

[00:56:47] Amanda Rae Arseneau: It’s a 0.03

only

please.

[00:56:50] Drew Podwal: you know, I, I’m persuaded, I, I still think that the thing that I take a little bit of issue with is the idea that spitting out a number, Is really that much additional effort, right? Like, I don’t believe that there’s, like I’m saying, I, there’s no science, there’s no perfection to this.

Cuz it’s not about getting a perfect number for me, it’s just, to me it’s really just about that shared language. but I will say this, I came armed in this conversation for, cuz what you guys were saying last time was the predominant reason why you didn’t like it was, because it gets weaponized, right?

[00:57:28] Amanda Rae Arseneau: Well, admittedly you, you kept like taking that out of our equation, so we’ll put that

[00:57:33] Drew Podwal: well, so the thing to me that I was gonna respond to with that is that, if we’re removing it we’re, we’re obfuscating it, and. The scrum, value of, of openness, and transparency like that goes, like the idea of like hiding data from senior leadership to me goes against those values, you know?

So I’m very disappointed that you guys didn’t bring that up today and

[00:58:03] Brad Nelson: those, things are based on empiricism. And empiricism is based on historically looking at what you’ve done and that my friend is throughput, not sciencey

velocity,

[00:58:12] Amanda Rae Arseneau: Yep.

[00:58:13] Brad Nelson: like drop.

No, it’s hung up, so I can’t,

[00:58:16] Drew Podwal: Yeah. Uh, look, I, I think that in, in early

Agile culture organizations, Story points can definitely be a thing that can be helpful, they might not be a thing that can be helpful. Like if it go into a scenario where, where nobody wants to do it anyway, then that’s not the hill that I’m gonna die on.

It’s not appropriate to go into an, you know, a high culture Agile organization and say, all right, now everybody’s gotta start using story points. Like that just doesn’t make sense. They’ve already got that, that shared language. So, you know, to like what Todd said the other day, there’s so many methodologies that are out there and there are things about each one of them that may be right for an organization, there’s no such thing as a one size fits all methodology, and as a result, I think that story points is something that companies might benefit from. and I definitely agree with you guys that it’s. Not the end all, be all metric. It shouldn’t be used in the way that it gets used oftentimes.

if you try to make it too science-y it becomes an a, an overhead that actually prevents teams from being able to deliver value. Um, but I think it’s a viable option depending on the scenario.

[00:59:32] Brad Nelson: So, I wanna ask Amanda a question. So let’s say our listeners are now convinced that they’re, they’re in a shop now where they’re using story points and they’re like, you know what, that Amanda, she’s so smart. I wanna try this. But my organization has this expectation that, I, that I’m using points now. What would be your suggestion to start moving down

the path of no estimates?

[00:59:57] Amanda Rae Arseneau: I mean it de it depends on the culture.

[00:59:59] Brad Nelson: Hm.

[01:00:01] Amanda Rae Arseneau: number one, shell game. 32 points. Yes. Here’s this placeholder story. You know, where are they getting the metrics from? Do they even look at your board? Um, no, I’m not that person. But, uh, honestly for me, are you in a team that you could actually safely experiment?

Are you in an actual Agile company that allows you to experiment with the way that you work? If the answer you firmly believe is no, because you have direct evidence that this has never been able to happen, great. I guarantee you there is somebody else in your company who also wants to be like, oh, okay, I’ll experiment with the way you work.

Find something to barter with. Even if it’s like, I’ll bring you lasagna for five weeks if you just let this team do this, this one time. hopefully you are in a little bit more of a flexible world or you have a a time where you can, just try, or you create a separate No, I’ll stop. Do the research. there are tons of articles out of there, like when this first came out quite quite a while ago. Uh, as hashtag no metrics. So many articles have been written. yes there’s articles on both sides, but I guarantee you, at this point, most of them are no estimates. find alternatives because you are gonna have to answer, you know, well then how are you going to know if you’re gonna be able to deliver?

Talk to your team. Are they comfortable with that? does knowing if we’re gonna deliver, like my, the best fun you can have is what if we took everything away and we just went with our gut instincts and then actually like rated at the end of how this felt. Were we even close? And then can we laugh about it?

Cuz that’s a little bit different than, you know, ugh, we failed our sprint. All our story, like all our story points out, submissions were wrong. You know, what could you, what else could you sandwich? Even with trying no estimates for, for one day. On the flip side, what might you have to spend more time doing if you weren’t story pointing or what could you spend more time doing?

Sorry, I just, I just suggested that it’s taking a lot of time, but I bet you if you’d asked abs, they do think that it is. and just to pause on the effort part, I would also say at this point, everyone’s done Scrum, everyone’s tried story pointing. Everyone’s mostly used it without even knowing why they used it or been properly trained.

And I a hundred percent know if I was on Drew’s team, I would not mind learning it. And I would go for it and it would be fun and I would feel safe. But Drew, after you left, then what? And when new people join and you’re not there, then what, especially as a consult, I think that’s where I’m like, now you have to do the unlearning as well.

You have to try and find people that are gonna be able to carry that beyond you. And that’s, we already know that some of the hardest stuff you’ll ever do as an Agile coach, and you cannot predict what’s gonna happen in the future. So I love that you are giving people positive, time with story pointing and actually having people learn from it.

but I definitely am on the side of like, if you are out there and

using story points, you don’t have to ha you don’t have to live like this.

Um,

[01:03:04] Drew Podwal: point sold

that, that point there that you said, where I’m not gonna be there forever and that who’s gonna protect the story points when I’m gone. That that was a, that’s a big selling point for me

to step away from that.

[01:03:18] Brad Nelson: I, I I

[01:03:19] Amanda Rae Arseneau: that

is title of, of

[01:03:21] Drew Podwal: that’s

[01:03:22] Amanda Rae Arseneau: Who’s gonna protect the story points

[01:03:23] Drew Podwal: Yeah.

Uh,

I feel like I wanna sing that as

a heart song on karaoke night.

I feel like there’s, but, uh, I love also that apparently you have a team of developers that are all Garfield, that that can be bribed with lasagna.

[01:03:42] Amanda Rae Arseneau: I don’t know. Maybe it’s a Canadian thing.

[01:03:43] Brad Nelson: Um,

[01:03:44] Drew Podwal: I feel I do. I feel like I’ve been persuaded. between the, the idea that I’m not always gonna be there. and the idea of if I could teach them to look at flow-based metrics earlier. Then that will wind up getting them to a much better spot. Really glad we did this because for a while I’ve wanted to know more about like where this no estimates movement is coming from, right.

um, and now it’s starting to click, so

[01:04:12] Amanda Rae Arseneau: I would do wanna point out we are on the cusp of, we are just on the cusp of also flow metrics being possibly thrown out the window as well. Alexi Zoff, I believe I sort of discussing it. and if you start doing a little bit deep diving, it’s, it’s a very interesting world. It does kind of just bubble back down to the, possibly being weaponized. Really, actually in the end still just being estimations. I mean, scientifically, mathematically, yes, we do have an

85% confidence level,

but

it’s definitely a different

[01:04:46] Brad Nelson: Yeah.

[01:04:46] Drew Podwal: here’s the thing though. I I forget what tool it was, but there was some plugin for, for Jira that we wanted to use, And it was built in such a way where it was only built for the teams that were idealized teams that were working in this way perfectly. And, I filed a, a ticket with one of the, and I love doing this.

I, I’m always doing this kind of thing. where I’m trying to talk to somebody in product at, at the companies that have these tools that don’t work the way that I want them to work. And, and we talked about it for a bit and I was like, look, you know, you’ve got two types of customers out there. You’ve got customers that are doing.

Scrum and Agile practices perfectly. And then you’ve got ones that are transitioning towards doing it perfectly. And the way that your tool is set up right now is it’s not flexible enough for it to allow those transitioning to, to become more perfect, And I think that we’ve gotta think about that in the way that we coach.

it would be wonderful if we could just flip a light switch and say everybody’s doing it perfectly now suddenly, you know? I, I think that we have to come up with coaching methods that meet our teams where they are in their agility, and go from there. Because if we’re trying to pigeonhole them into this perfect model too quickly, we’re just gonna

[01:06:05] Brad Nelson: I, I agree with that, Drew, and, and I wanna throw out there, cuz I, I’ve talked about the research that’s out there. I haven’t said exactly where it comes from. So there’s a book Accelerate by Nicole, Dr. Nicole Forsgren, gene Kim and Jazz Humble. That is all about the research that they’ve done at Dora, the DevOps Research Association.

I feel like there’s a million Dora acronyms, but this one is the DevOps Research Association. Nicole Fork is one of my idols in the industry. Fantastic. , researcher, author, presenter, watcher stuff. Read her book. The other one is Daniel Viti. Uh, I believe he’s from Pro Kanban. He’s written two Actionable Agile Metrics and When Will it be Done?

And it teaches Kanban through metrics and they’re both phenomenal books. He co-created the Professional Scrum with Kanban course as well, which, if you are into Scrum training, one of my favorite Scrum classes, cuz it kind of blew my mind and challenged my preconceived notions on what Scrum is. But I also had him as one of the trainers, so I can’t guarantee every trainer will be that way.

Uh, My scrum trainer in that was Summer Lawrence, who is phenomenal. I have to sweet talker into coming in the show at some point. But Amanda has second that, uh, the PSK is great, but those are three books that are, instrumental to, to learning the flow metrics, to having research to back it up,

uh, and, and to move you down the correct path.

[01:07:37] Amanda Rae Arseneau: I would also say there have been multiple, conference speeches on door metrics lately. Um, a really great one is, Michael Shrouds, um, that might be the completely wrong name. ex VP of engineering, who did an entire transformation at eBay. Uh, basically, you know, dumpster fire of an engineering department, uh, won’t say a hundred percent turnaround, but relatively well turned around baseline metrics all through metrics could like actually have that value, um, being shown.

So even if you’re in a world where you can’t get out of story pointing, highly recommend you still look at Dora, talk. If you have a DevOps or SRE department, I guarantee you will become their best friend. that you can leverage these metrics across an org. It doesn’t have to be specific to your team.

And it’s really just worthwhile to sort of understand, you know, that sure, productivity is one thing, but it’s how do you measure the health of, of your engineering org. Um, also Google has a really cool interactive Dora page where you can kind of answer questions to see where you guys currently sit. Um, cause there’s a bit of a, a scale, for where you’re trying to aim to be too.

So you, you can see where you sit and where you could sit and how some of the best companies in the world do it.

[01:08:57] Brad Nelson: Yeah, so Nicole did work for Google and I do believe they technically like own her company or whatever that created. And then she works now for Microsoft, uh, in GitHub as a researcher. also puppet releases an annual state of DevOps report, which is based off Dora as. Or in partnership with them. So there’s a lot of resources out there. and lastly, I’ll plug myself Velocity Trap my presentation. If it’s in your town, come check it out. If it’s not, reach out to me. I’ve done it as lunch and learns, and I’ve done it at meetups.

I’ve done it. virtually. Just hit me up.

[01:09:31] Drew Podwal: Love it. I think that we also need to get feedback, right? Um, I would love to find out what people have to say of going through this journey with us, with me, really. Right? Like what side of the fence did you start this podcast from? Were you pro points or con points? what were some of the aha moments, if you had any?

Like, are you still in the same camp that you were in when, when we started this?

[01:10:00] Brad Nelson: yeah.

If you have

questions.

challenge us. If you have something that we didn’t

answer, challenge us and, and we’ll sit Amanda

[01:10:08] Drew Podwal: And I think I’m gonna

[01:10:09] Brad Nelson: on it.

I, I want to call out to Drew. I really appreciate your curiosity and your openness and that is something that you do so well. Time and time

again on this podcast, that is just fantastic.

[01:10:23] Drew Podwal: Thank you. Yeah, it’s, you know, I was once in a, in a training session where I, I was one of the trainers and the lead trainer asked everybody to raise their hand and, show with a number of figures how, uh, how much experience they had, with Agile, right? and I put up four fingers. and everybody looked at me and they’re like, but you’re our trainer.

and I said to them, I I will never know everything there is to know about this. this is a commitment. That I’ve made to learning more as I go along, and, I believe in vulnerability. showing vulnerability to your teams within your team, as a leader even is, just the best way of leadership.

and yeah. So I definitely have Macon a point, Macon made a point to be vulnerable on this podcast and admit when there’s something that I don’t know and allow myself to be very open or transparent to, my thought process of, of how I start and finish and evolve. So, I appreciate you for pointing that out, Brad.

Thank you.

[01:11:29] Brad Nelson: Yeah, yeah. There’s also the Dunning Kruger effect as well, and the less you know, the more confident you are in what you

know, and the more you know, the more you realize you don’t know.

[01:11:38] Amanda Rae Arseneau: I was half afraid, full transparency that I’m just gonna come, if we were gonna do this and Drew was gonna talk me into it. Cuz I have been known to in the middle of a meeting go. Oh. And um, I really hope one day we’re all in a room having a podcast and I get to change my stance on something.

It’s one of my favorite things to do. And if my team listens to this, they will also say that maybe it’s too much. But, I agree. I think having, A strong stance is awesome. Being able to recognize when you have a strong stance, but still be flexible is where really the gold is. And letting other people see that or hear that in this case, that is invaluable.

And I hope, I really do hope that a lot of people take that away and learn from it.

[01:12:23] Brad Nelson: Yeah. What is the saying? Something

like have, have passionate beliefs, but hold them loosely, or

[01:12:29] Amanda Rae Arseneau: Yeah.

[01:12:30] Brad Nelson: there’s a more eloquent way of saying it that it’s not coming to me, but.

[01:12:35] Amanda Rae Arseneau: It’s not, it’s not a day for eloquence.

[01:12:38] Drew Podwal: Bribing teams with lasagna.

[01:12:40] Brad Nelson: Yes.

[01:12:41] Drew Podwal: I love that.

[01:12:41] Brad Nelson: That’s as elegant as it gets a little chardonnay, you know?

Um,

Yeah. So let’s, let’s wrap this up, Amanda. Any last thoughts, parting

gifts, words of wisdom, things you have going on in your

[01:12:54] Amanda Rae Arseneau: what life? Um, happy spring. , apparently it’s semi nice outside in Canada, which is lovely. Canada, it’s huge. Sorry, in Ontario. I don’t know what it’s like in the rest of the provinces. Um, but yeah, no, I’m hoping to finally attend a real conference at some point. Again, uh, I’ve been signing up for a lot of virtual ones.

I’m starting to feel a little bit sad about it. Um, Brad, I noticed that you’re, you’re speaking next month, right?

[01:13:20] Brad Nelson: I am virtually, yeah. Yep.

[01:13:22] Amanda Rae Arseneau: Yeah, I’ll be there virtually.

[01:13:24] Brad Nelson: Yes. Awesome.

[01:13:25] Amanda Rae Arseneau: yeah, if anyone has like, good.

Ideas or where to go to next. I’ve, I’ve lost track of where good content is. , but yeah, just thank you both. This is always a pleasure and, and a bit of a mind tickler every time we get together and it’s, it’s such a good recharge. So please, please have him be back anytime if you should like,

[01:13:46] Brad Nelson: Definitely. Thank you, Amanda And Drew. Uh uh, sounds like you have,

I don’t know, a little ruckus going on over there, but part parting thoughts.

[01:13:55] Drew Podwal: I would say that, if you’re doing story points right now, and it’s working for you, maybe find something else to go figure out, another impediment to go or improve on, right? But, you know, if you’re in that situation where, where you’re with teams that are, that are rolling over and rolling over and rolling over stories spend time with them, getting them to really start to think about card clarity confirmation. and you know, looking at what are the things that you want to evaluate your stories on, right? complexity, risk, uncertainty knowledge I think are great ones. There might be more, come up with ways to help your teams see what it is that they’re doing. and you know, I do think that acceptance, right?

Accepting that, sure, maybe the faster path to having metrics might be to teach everybody to do story points, but the more valuable metric really is throughput, cycle time. and definitely value, if you’re at a company that is not looking at value and you’re just a feature factory, you know, God bless you and I’m an atheist.

So, um,

[01:15:07] Brad Nelson: Yeah.

Thanks Drew. I appreciate the value plug and the blessing. Uh, so I, I do wanna like asterisk, I guess we came down a little hard or I feel like I came down a little hard on product people. I love product people and that’s why I’m so passionate about it. And most product people are not set up for success.

So I wanna realize that as well. Probably a whole nother podcast. but I do wanna say thank you, Amanda, for joining us. Thank you Drew, always for partnering with me. If you’re listening to this episode, we want your feedback. We crave your feedback, we need your feedback. We’re Agile Agilists, we’re empiricists, we need it.

So please send us a comment, send us an email. use our voice feature that I cannot remember the name, Drew

[01:15:52] Drew Podwal: Memo fm. Memo fm.

[01:15:55] Brad Nelson: memo.fm, which you can find on the right side of our website. If you go there, Agile for Agilists dot com or shoot us an email. Hello

Agile for Agile Agilists dot com. Thanks everyone.