Recently, Sam and Dan discussed velocity; an important metric to agile teams, and what it looks like when used correctly vs. incorrectly. In keeping with this theme, they’re exploring two other important metrics that are also often misused and misunderstood: story points and user stories.
Story points and user stories are all-too-commonly misused. In this episode, Sam and Dan debunk some of the common misunderstandings, share how both concepts are often misused, personal experiences in their roles as agile coaches, and how to correctly use them.
- What are user stories? How can they be misused?
- User stories come from extreme programming as one of the practices that were advocated for during its emergence
- User stories were born out of a need for telling a story about what the users want the system to do (and use that instead of the detailed requirements documentation that nobody actually reads)
- Kent Beck is attributed to coining the term “user story”
- User stories have good intentions and work in a particular context but are often misused and come with a multitude of unintended consequences
- If the user story framework helps you, great — but if it doesn’t, don’t use it (don’t think that you have to use it because it “makes you agile”)
- The idea of the user story framework is to concisely suggest to developers what a user might want to do with a system (it should also answer: What kind of user? What kind of behavior? And why?)
- Good vs. bad uses of utilizing user stories:
- Misuse: If you simply want to do something as a developer, put a task in your backlog; you don’t have to twist it into a user story format
- Misuse: Writing everything down and believing that the problem has been clearly communicated (just because it is written down, doesn’t mean there is a shared understanding)
- Correct use: When user stories are used to have a conversation about what we want the system to do or what the user wants the system to do
- Misuse: If the user story is short enough, it isn’t necessary to have an abundance of written documentation (If you’re finding yourself needing to attach a lot of written documentation to the requirement, it is most likely too broad of a scope for a user story)
- Misuse: You don’t need to know all of your stories ahead of time to get the project done
- Correct use: Understand that in creating user stories and moving through your agile journey, many of them will be wrong and it’s unknowable
- Correct use: Conversations should be happening more frequently and be broken down into smaller pieces so that everyone has a clearer picture
- Tips for leveraging user stories effectively:
- Get in the mind of the user so that you can better come up with some strategies for appealing to their needs of fulfilling their needs
- Address the acceptance criteria/conditions of satisfaction (i.e. How do I know when I’ve achieved this goal?)
- Try to make the user story about what the user is trying to achieve (i.e. conditions of satisfaction)
- Reference User Stories Applied: For Agile Software Development, by Mike Cohn
- Don’t take user stories too seriously
- Remember the three C’s: Card (because they used to be written on index cards), Conversation, and Confirmation
- Good vs. bad uses of story points:
- Misuse: Story points are often conflated with days (i.e. how long it will take to do something) which, in turn, become used for velocity metrics (which is then often weaponized against the team [listen to episode 135])
- Misuse: You shouldn’t be predicting too far out with story points (instead, talk about what you can do in the next couple of Sprints and then go from there)
- Misuse: Similarly to user stories, don’t take story points too seriously (i.e. don’t take them as means of precision beyond having had a conversations around something that is possible to do)
- Correct use: Story points are simply unitless measure of relative size (in Sprint planning you can worry about the finer details and granular approach)
- Misuse: There is no value in breaking up story points into multiple points, resizing the stories, etc. (It’s supposed to be a close-enough/estimate… it’s not supposed to be precise)
- Misuse: Software development is unpredictable and filled with unknowns, trying to force specific predictions with story points is counterintuitive
- Correct use: Breaking things into smaller pieces with user stories is a lot easier to figure out the size of the task
- Closing Thoughts:
- Don’t take user stories and story points too seriously
- Don’t think you know more than you do
- Cut yourself some slack and cut your team some slack
- Break things down into smaller and smaller pieces
- The smaller something is, the more easily it’s understood and the fewer unknowns there are
Mentioned in this Episode:
- Agile Coaches’ Corner Ep. 135: “Exploring Velocity: What is it? How Do We Measure it? How Can We Leverage it?
- Lean Coffee
- User Stories Applied: For Agile Software Development, by Mike Cohn
- Killer Nashville
- Devil in a Blue Dress: An Easy Rawlins Mystery, by Walter Mosley
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
Intro: [00:03] Welcome to the Agile Coaches’ Corner by AgileThought. The podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach, and agile expert, Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of the Agile Coaches’ Corner podcast. I am your host, Dan Neumann, and joined today by Sam Falco, Professional Scrum Trainer and principal trainer at AgileThought. Thanks for joining Sam.
Sam Falco: [00:31] Oh, sorry. I was just getting into character.
Dan Neumann: [00:33] Oh, you were just saying, you got to see how long will you go with a silent podcast and just listen to the clicks as people stop listening.
Sam Falco: [00:43] Recently read a news article about a, uh, someone attacked some people at a disco and it said a silent disco and it never explained what’s like a silent disco. So I had to go go, I totally want to go to one of those. No, that’s not what you think it is. Um, no, it’s a disco, but everybody, it, the music is broadcast over headsets so that they can not worry about, oh, it is what you think it is. This is exactly what I think it is that you don’t have to worry about noise, ordinances or curfews. And I thought that was pretty, pretty clever. Also, from my perspective, I’ve been to clubs and stuff and I always come away basically partly deaf like, well, this way you could control the volume. So you’re not getting deafened, but you can still dance. I thought that was a pretty cool idea that has absolutely nothing to do with what we’re going to be talking about today.
Dan Neumann: [01:31] Well, we are talking about points and I was going to ask what’s your point?
Sam Falco: [01:38] Yeah. I thought we recently talked about velocity and I thought we would talk about two other super misused and misunderstood concepts that are adjacent to it. Story points, which of course come from user stories and these a, you know, terribly misused, both of them, um, the whole, no estimates movement arose because people were misusing story points and making them a big pain in the butt for people. And, uh, and people sort of saying, why are we doing this?
Dan Neumann: [02:16] So right in the Scrum guide, it talks about the three roles, Scrum Master, Product Owner developer and artifacts, product backlogs, sprint backlog, increment stories. Nope.
Sam Falco: [02:29] I get though every time it’s funny. One of the exercise we’ll do in Scrum trainings is say, what are the artifacts of Scrum? And now I never hit them with this without saying first and advanced read the Scrum guide. And I’ll say, what does it say in the Scrum guide? But almost always someone will say user stories. That’s an artifact of Scrum. Okay. Please go find where user story is mentioned in the Scrum guide. And this is not, um, uh, excuse me, story points are what we often refer to a complimentary practice. That’s something that teams can use, but Scrum doesn’t care how you manage your product backlog or what goes in it or how you express it. It just says you should have once user stories are just one way we can do that.
Dan Neumann: [03:13] Yeah. And I know, I mean, like you said, so much of user story is conflated with being a thing you have to do to do Scrum. Well, if you’re doing Scrum, you obviously using user stories and, um, maybe we get back into our way back machine. I think user story comes from extreme programming as one of the practices, those advocated for there. Yes. Yes. I get my history.
Sam Falco: [03:42] Yeah. It’s just the idea was how do we tell a story about what users want the system to do and use that instead of detailed requirements documentations that nobody actually reads. And so user stories are born. Um, I’m not sure who created them. I remember seeing a tweet recently from someone who said, I created this concept and I wish I hadn’t, which seems to be pretty common. I created this concept and then it turned into a Frankenstein’s monster and I really wish I’d kept my big mouth shut.
Dan Neumann: [04:17] Uh, so how often does that happen in, in you name it? You know, there was a good intention, a thing that worked in a particular context, usually small, somebody goes, well, if it works in a small scale, we should make it a huge, oh now there’s all these unintended consequences. That thing that worked in a very specific ecosystem.
Sam Falco: [04:41] And often the thing that we’re doing now, isn’t actually the thing that was originally articulated. Someone heard the name, they liked the idea and they ran with it. I’ve seen that happen, not just in agility. We should do that. There was, uh, someone at a presentation I was at on, uh, data management and the, the term data lake came up and this person like eyes lit up and oh, we can just go fishing in the data lake like, oh, I’m pretty sure this person did not grasp what this was. Uh, because they kept making the little fishing sign with their hands. Like they were casting a rod. Like I think they really thought that they were going to go get rod and reel and go fishing in the data lake.
Dan Neumann: [05:29] And I do like that metaphor, not what that means, but okay. And fishing stories will bring us back to user stories. So that’s good. I’m going to keep trying to bring it back on top of topic. I’m going to keep us, at least within arms reach.
Sam Falco: [05:48] Dan tries to drag Sam kicking and screaming back in the vicinity of the point he’s trying to make.
Dan Neumann: [05:54] Yeah. So I, uh, I used, uh, my favorite search engine here, which apparently does track everything I do. And, uh, Kent Beck came up with user stories or at least has claimed to have come up with user stories and it’s attributed to him and kind of like, tell me the story of what the system will do.
Sam Falco: [06:11] Yeah. And from that, we get people started saying, oh, epic, because a story was too big. And then of course that gets misused. People say, oh, we have to write epics and then break it down into the story. No you don’t.
Dan Neumann: [06:23] When I was a kid. Oh nine and Mike Cohn did my Scrum master training. He said, what’s a really big story. It’s an epic. And he laughed. Yeah. And now that stuff is a three epic feature story breakdown in your Azure dev ops or your JIRA just so abused. It was a joke.
Sam Falco: [06:46] Yeah. It’s a metaphor four. It’s the idea that you can’t tell a story in a single setting it’s longer than that. It’s an epic. Yeah. Anyway.
Dan Neumann: [06:56] So what do we do with this? So we’ve got a complimentary practice of user stories, not in the Scrum guide. Scrum guide says, have a backlog, have it ordered, have value in it. Right. It doesn’t care how, um, so we won’t take your Scrum badge away if, uh, you know, you’re not using user stories, but what would be, if somebody is, what, what would the difference between good and bad look like if, if one were to try to use the user story, do they need to use canonical so that.
Sam Falco: [07:25] You don’t have to. I have to, um, that’s the format that is typically used, but like anything else, if that framework helps you great. But if it doesn’t don’t and I see people get tied up in that, that’s another thing that I will see happen is, oh, wait, we have to use user stories because that makes us agile. And so you see things like, as a database, I need a new table so that I can store data. Oh my God, that’s not a user story. That’s a non functional requirement. You don’t need to do that. So, no, you don’t have to do that, but let’s talk about that. The idea of the frame of that framework of that format as a, some type of user, I want to do some sort of behavior so that I get this benefit out of it. The idea is to concisely, suggest to developers what a user might want to do with the system, but it, and it should go beyond as a user, what kind of user, what kind of behavior and why. So, um, you would think I would have come to this prepared with some examples, but I didn’t.
Dan Neumann: [08:35] I have one. We’ll see, uh, you know, as somebody who’s mobile, you know, I w I would like the, um, the grocery store loyalty program to just be available. When I go to the grocery store, I shouldn’t have to open my wallet and scroll through the crap. And yeah, I just want it to know.
Sam Falco: [08:59] All right. That’s a little vague. So you would bring that to developers and they would say, well, why, what store, what is Dan trying to do? What kind of user is Dan? Is Dan a casual go in and grab enough for the next couple of days, without much of a list person, or as Dan a, I go every Thursday when the new deals have listed, and I have my list and I stick to my list and I don’t buy new items, those are two different types of users. We would want to know what kind of user Dan is. So there’s one way to start.
Dan Neumann: [09:31] Yeah. And, and honestly, maybe the, the way I express, right? So I, I started with my, my, there was some how baked into mine. I don’t want this thing on my phone. Well, what if it, the grocery store just knew it was me and I didn’t actually have to do anything. Cause I’d give away my identity to the grocery store. So they could recognize me for, you know, throw me a bone once in a while as a coupon. Right. But why do I even have to pick a loyalty program? I can’t, they just know we’re in with the facial rec.
Sam Falco: [10:01] Um, because in this whole is cameras anywhere getting the whole majority report vibe where you’re walking down the street and the avatars pop up and say, Hey, Dan, come on in.
Dan Neumann: [10:10] Yeah. Well, I mean, if I like it.
Sam Falco: [10:13] I don’t want to live in your world, Dan.
Dan Neumann: [10:14] Yeah, that’s fine. Nobody does. Where were we? We were on stories. So trying to get the, to get a little bit in the mind of the person, right? So that you can better come up with some strategies for appealing to their need or fulfilling their right.
Sam Falco: [10:37] I built at one point an app for running lean coffees, lean coffee is a type of meeting where, uh, you, it’s an agenda-less meeting participants come up with the agenda. You order the, the list of topics you want to talk about. Typically it’s five minutes. Then when the timer goes off, people vote. Yes or no, they want to continue or they want to stop. If they want to continue. At two minutes, I built a timer for this. At one point when I was learning C sharp not, sharp programming what’s um, what’s Apple’s language, swift, objective C swift swift, um, the newer one swift. I was learning swift. I was teaching it to myself and I thought I’ll write an app. So one of my user stories was I had identified a couple of different types of facilitators, and one of them was as a fledgling facilitator. And I had identified that fledgling facilitators didn’t want a lot of bells and whistles because they needed to be able to focus. I want an easy way to indicate that the time box has been reached so that I don’t have to stop people from talking. There was my user story. Here’s what I want to do. Now that is that a timer? Is that a bell? Is that a visual indicator? That’s going to come out in acceptance tests, which we might add to the back of, I’m getting a little bit ahead, but part of the user story stories then, okay, let’s flush that out a little bit. What does that mean? And so what I tested was did the screen flash did a bell go off. Those were, those were part of the acceptance and it went off at their proper time and it didn’t run over, et cetera. But that’s just an example of a user story.
Dan Neumann: [12:18] Right. No, I love it. So using the user story to talk about what the actual needs are to help figure out generally what’s needed. And then you talked about acceptance criteria, um, conditions of satisfaction, I think is another way I’ve heard that or talked about that. How do I know when I’ve achieved this goal of easily letting the novice facilitator know that right at the time boxes have been expired, right? Flashes or dings, or, you know, yeah. The reset button shows up that might even be a separate capability easily for the next, right?
Sam Falco: [13:08] Yeah. Uh, this, this app was never released because I lost interest in it. And then I didn’t want to pay apple a hundred dollars a year to release a free capital world. So I said, no, I’m not doing that.
Dan Neumann: [13:18] But anyway, you could have done test first. You could have you in your first sprint, you could have gone all the way to production gone. Wait a minute. I mean, you could have saved yourself a lot of time. Probably. That’s a thought, where’s the fun in that. Yeah.
Sam Falco: [13:32] Anyway, let’s drag me back to the point again.
Dan Neumann: [13:36] So the idea behind the user story, misused, misused, sometimes like, here’s, like you said, as a, as a, as a developer, I want to do the thing, right? Put a task in your backlog. This is do the thing. Right. Don’t don’t twist it a new user story format, um, try to make it about what the user is trying to achieve with some conditions of satisfaction.
Sam Falco: [14:01] Right. Okay. And I don’t want to, I don’t know that I want to get too deep into how to write a user story today. Cause there’s tons of material has been written about that. Mike Holmes book is I think the best one I’ve ever seen user stories applied. It was written long ago in the early two thousands, but still has lots of valuable things to say. I think I can’t do better than Mike Cohn on user stories, but just know that this is.
Dan Neumann: [14:27] Telling myself I can’t do better than like Coda in most facets of my ad agility. I got big fan boy, but.
Sam Falco: [14:35] He did my original Scrum Master certification training. That was, it was awesome. He was, he was a great, great instructor. Um, but I want to call out, and this is something that I have highlighted in my copy of that book. It’s right in chapter one, software requirements is a communication problem. That’s the quote, right? The problem with, with software requirements is we’ve often thought that, well, if we just write everything down and hand it back and forth, and we will have understood the problem and communicated well, and that’s not true. User stories become a way of having a conversation around what it is we want the system to do, or what the users want the systems to do. And you have tried to break in and you’re you keep pointing at me. So I’m going to stop. So you can jump in.
Dan Neumann: [15:15] Thank you. Sorry. I got excited about something. And that was the biggest problem with the communication is the illusion that it’s happened. I believe that’s a quote that I right and same thing with software. Well, it was in the requirements. Well, yeah, but that doesn’t mean anybody. You knew what the hell you were talking about.
Sam Falco: [15:31] Right. Or read it, or understood it in the same way that you did just because it’s written down. Um, this is a problem, not just in software development, in any human endeavor. The, the idea that once we have written something down, we have a shared understanding. Oh no. The simplest example of this is if I tell you to go buy some blue paint, the paint you come back with is not going to match what I anticipated. We have some more discovery to do. I tell you to go buy me a chair, the chair you buy. The chair you’re thinking of right now is not the chair I’m thinking of. I was thinking of the chair behind me that you can see and see you still, weren’t thinking of the same chair that I’m thinking of. So this is the problem with the software requirements is that we think that if we just spend enough time writing them down and elaborating on we’ll, we’ll get someplace. And this is another way I see user stories sort of misapplied as, Hey, we need to write everything down. As we talk about it. If the story is small enough that we can do it in a short amount of time, maybe we don’t need to have so much written documentation. And the minute you find yourself needing to attach reams of documentation, maybe you’re talking about things in too broad, a scope, skinny it down a little bit, bring it down to just a little piece that you can build.
Dan Neumann: [16:54] Don’t we need to know all our stories ahead of time. So we know when we’re going to get the project done.
Sam Falco: [16:58] I hope the mic didn’t pick up my grinding teeth.
Dan Neumann: [17:04] I’m playing dumber than usual. How about that? Yeah. So that’s an innate desire I see from the backlog needs to be everything we’re going to do, which all of a sudden, then it looks a lot like a requirements, doc. You’d just call them user stories.
Sam Falco: [17:20] Right. And then we have, again, not only the illusion that what we’ve communicated at all we understand at all there’s well, we’re going to get all this stuff. Well, no, you’re probably not. You probably don’t even want all that stuff. So there’s nothing wrong with a large detailed product backlog, as long as we understand that, that’s just our understanding today. And it’s going to change tomorrow or next sprint, and we’re going to adapt it. And maybe we abandoned a large part of it later as realized that, Hey, there’s a lot of stuff written down here. We’re just never going to do get rid of it.
Dan Neumann: [17:54] There was a benefit of agility, articulated something like getting the system we need at the end and not the one we wanted at the beginning, something like that because of the learning journey. And another reason not to elaborate all the user stories, if you’re using them ahead of time, is because a bunch of those are just going to be wrong. You don’t know which ones are going to be wrong, or obviously you wouldn’t do it. It’s unknowable.
Sam Falco: [18:21] A large backlog, a large product backlog is essentially excess inventory. And anyone with some lean background will know that excess inventory is a form of waste. You’re maintaining this, you’re spending time and energy on it. Why so don’t fall for that. But again, there’s nothing wrong with creating that initial backlog, if, especially in a case where it’s a new relationship between a team and the business, and they were not quite sure if that they trust each other yet or that they can communicate well. So we, it’s fine. If you feel like you need that at the beginning, that’s fine. Again, recognize that it’s going to change, recognize that it may be waste and over time, maybe just let that shrink down to, Hey, we know what we’re going to, what we think we want for the next release, which is much closer in time than our old, you know, annual waterfall releases. And we’ll let the rest sort of emerge over time. That’s fine.
Dan Neumann: [19:20] Any parting thoughts on stories before we kind of stick our toes into story points?
Sam Falco: [19:26] Don’t take them too seriously. I think as what I’m going to say, remember that the, I don’t know if my cone was the one who originated this idea, but in, in the user stories applied, you mentioned that say card, actually. I think he sites somebody else, but the three Cs the card, because they used to be written on index cards, way back in the stone age, um, a card, a conversation and confirmation. So it’s a card with some stuff that is there to remind us to talk about this when we’re going to start developing it. Hey, well, what do you want here? Let’s develop a little bit and the confirmation being, how do we know when we’re done? What are our acceptance criteria or acceptance tests or confirmation tests, or however you want to phrase it.
Dan Neumann: [20:14] Yeah. When we’re done, how are we going to know? Right. Or an automated test or these, these specific things will be achievable.
Sam Falco: [20:24] Yeah. And the idea is always communication. Communication is difficult and we need to do more of it. Not less of it in order to be effective at it.
Dan Neumann: [20:34] Yeah. That’s where I see this interesting urge to, you know, sprint planning. How fast can we get out of sprint planning? How fast can we get out of a sprint review or a retro ironically daily Scrum never seems to fit when I spot anti-patterns. It’s kind of interesting.
Sam Falco: [20:54] I get that a lot. And I noticed it in many places where I’ve worked, where let’s oh, sprint planning. It’s a chore. It’s horrible. Well, okay. It can be a little tedious, but let’s talk about maybe what we’re going far off field, but what the heck let’s talk about maybe why is it tedious? What’s so tedious about it. And instead of, well, let’s just do less of it. Let’s find out how to streamline some of those things frequently. The problem is we haven’t had the conversations, we’ve just got cards. And so we don’t really know what this is. And now we’re trying to essentially refine it while we’re trying to do sprint planning. We don’t know how much time we’re you’re going to need to spend on this, how big this effort is. And, and then there’s the anxiety of, and we’ve talked about this previously of I’m being asked to commit to a scope, not a goal. And I don’t want to put something in if I don’t know that I can do it, et cetera. So maybe what you really need is to have those conversations more frequently and break things down into smaller pieces so that you have a much better ability to say, yeah, I, I think we can do this.
Dan Neumann: [22:01] Can story points help with that?
Sam Falco: [22:02] And that’s where story points again. Yes. Nice segue. Thank you. Thank you.
Dan Neumann: [22:11] How can stories? So story points.
Sam Falco: [22:13] So the first one I am, I was introduced to story points was before I had any training in it. And it was somebody who had had training, but didn’t have an in-depth knowledge. And it was just story points are how much time this is going to take. So put story points on it, but don’t use days. Oh, but you said it was how much time it was going to take. Yes, but don’t use days because that’s not agile. Story points are agile because they’re abstract, but you just said they were days. No, no, they’re not days. They’re just how long it’ll take. All right. I’m going to go hit the bar. Cause I’m in a lot of pain right now.
Dan Neumann: [22:51] Don’t know what you’re saying. Right. And that’s a pretty common, you know, story points, right. Using them sort of conflating them with days, but not really.
Sam Falco: [23:00] Right. And then they of course turned into velocity because you do this many story points. And we already talked about that in the velocity podcast about how that gets use to beat up the team, which is why story points get a bad rep. I actually stopped coaching them at all for awhile. And team said, oh, how can we do story points? I think you shouldn’t do story points because it’s just going to get weaponized against you. And I would have teams break things down into small enough that it can fit in a sprint with about 10 of its friends and make of them that, that makes it difficult to predict. But that was actually also partly what I was trying to go for was like, you shouldn’t be predicting that far out. Well, how are we going to know what we can deliver next quarter? You can’t, let’s talk about what we can do in the next couple of Sprints, and we’ll go from there. Um, but I then started seeing the value of them in a team that really super wanted to use them because they really super wanted to be able to give, uh, predictions about release dates. But, and this was why I relented was that they said, well, we don’t want to say it’s going to be due on June 2nd, but we want to be able to tell people, you might get it as soon as, but you probably won’t get it later then. Okay, now we can use this. So I relented and I saw this team, take them seriously, but not take them so seriously. I think that’s my approach to two story points, as well as user stories just don’t take it too seriously. Don’t think this is precision or means anything other than we’ve talked about it. And we think this is pretty tiny and we think we can do it.
Dan Neumann: [24:38] Yeah. I’ve seen that desire to so story points the way I think about them and coach teams are unitless measures of relative size bigness, ugliness size. And in sprint planning, we can worry about the finer level of detail or those tasks and hours or whatever, further, more granular approach. And then that always seems to spur, well, it’s a three point story, but we added up the hours and it looks like it’s two points. So maybe we should resize the thing. There’s no value on that.
Sam Falco: [25:12] No, there’s, you’re done move on. It’s close to them. Yeah, exactly. And that’s what it’s supposed to be. Um, it’s supposed to be a close enough an estimate, unless we’re talking about car repairs, an estimate is not supposed to be precise. It’s just, here’s what we think we can do software development.
Dan Neumann: [25:31] And then we can talk about, maybe we should touch on why car repair estimates can be more precise and why software development ones.
Sam Falco: [25:39] Yeah, absolutely. Because the nutshell answer and then we can, we can pick it apart. But here’s the thing. We have lots of data. The problem is knowable in advance. You know what parts you need. Now you may not know which parts are broken until you start digging into the thing, which is why there’s sometimes a range or we won’t know until we take it apart. But that information, most of what we need to know to predict is knowable. There are very few unknowns. There may be some, but the knowns outweigh the unknowns. And if you’re following the Kenefin framework or using the Stacey chart to kind of map this, this is the simple domain. These are cause and effect is very well understood. We know the steps we need to take more or less. We follow them. We’ll get there. Software development is not that. Software development there are tons more unknowns than there are knowns. And it’s almost fractal in its ability to generate unknowns. We look at one and we figured out, oh, we know something. Oh, but here’s four more things you don’t know. That becomes really hard to predict in the way that we can predict car repairs or housing costs had some work done on my house, years back, and the guys were working and they cracked one of the window panes and the, uh, the, the atrium that we have in the center of the house. And I said, oh, is that gonna, is that gonna make it cost more? And the contractor said, no, we build that in. So that’s how they deal with the unknowns they build in that there’s going to be some, some unknowns. Well, when we’re working with something where there’s more unknowns than knowns, we have to build in a lot. So our estimates can never be more than guesses. But when we break things down into smaller and smaller pieces, we can get a little more accurate. So a user story that is about a, a user can add a record to the system is a lot easier to figure out how long or how big that task is. Then a user can manage their entire portfolio on the system. Well, that’s, you can’t predict that.
Dan Neumann: [28:06] Yeah. The, the metaphor kind of keeping the car one and, and relating to software. It’s almost like looking at your annual budget for car repair and I don’t buy new cars. So there’s a, there’s some flexibility in what I’m going to pay to repair them. I don’t know. What’s going to break something will fail. I will need to spend money on this car this year and to pretend otherwise is just stupid. Right? Something’s going to break, I need some cash around for, you know, when the thing breaks and I hope it’s, you know, breaks or, you know, whatever things, keep the car on the road and not a blown engine because those are expensive. Yeah. So it’s just, uh, you know, you, you can estimate good enough, uh, in software as well, in not knowing for sure what’s going to be a problem, but leaving buffer because something’s going to go sideways.
Sam Falco: [28:58] Right. And again, it’s smallness break things down into smaller. The smaller, uh, a work item is the more likely we are to understand it. And the more likely we are to not uncover a whole mess. So one factor that I have seen teams, they’ll be doing story points somewhere along the line, we’ll have decided that a one is, you know, built, built, equated to days all, you can’t know how many days or something’s going to take, but what they discover is that their stories are actually much bigger than they really anticipate. There’s, you know, there’s five things hidden in there. Break those out into smaller pieces. Probably your problem is that you are calling something a one or a two, and it’s huge. And you’re thinking of it as being smaller than it really is.
Dan Neumann: [29:50] So Sam we’ve, we’ve had, uh, a ranging exploration of the complimentary practice of user stories, story points and car repair. What, what closing thoughts do you have on that?
Sam Falco: [30:03] Don’t take them too seriously. As I said, I think that’s, that’s really true about most of what we do. Don’t don’t think, you know, more than you do cut yourself some slack, cut your teams, some slack on these things and, uh, break things down into smaller and smaller pieces. The smaller something is the more easily it’s understood. The more we can know about the fewer unknowns are hiding to bite us. And, um, yeah, I think that’ll, that’ll do.
Dan Neumann: [30:31] I love it. You have that progressive elaboration breaking down the detail, but doing it as you go through in not all up front. So, yeah. Awesome. Thank you for taking some time to share with folks. And that brings us to the what’s Sam reading these days.
Sam Falco: [30:46] Well, I mentioned earlier, I, uh, well, I don’t know if I said that I’m reading it, but I’m rereading agile, a user stories applied to, because I’ll be doing some coaching specifically around that. And I wanted to refresh my memory, always good to kind of go back and find out that you’ve forgotten some things or, you know, misapplied that, and then you, of course, I’m always reading fiction. I’m going to be going to, I’m really excited to be going to a first, my first in-person conference since, uh, COVID. This is a writer’s conference called killer Nashville. Um, it’s in Nashville.
Dan Neumann: [31:21] That’s an unfortunate name with COVID.
Sam Falco: [31:23] Well, it’s a mystery writers conference. One of my favorite authors is Walter Mosley, um, who wrote the book devil in a blue dress that was made into a movie with Denzel Washington and, uh, 95. Really good movie and book. And I’m reading some of his more recent things so that I, if I actually get to talk to him, I can say something intelligent to him. I hope.
Dan Neumann: [31:45] And not about agile, not about agile. You know, why not?
Sam Falco: [31:49] You never know.
Dan Neumann: [31:50] Awesome. Well, thank you for sharing Sam and yeah, no, the user stories applied is one of the books that I keep laying around as well. So definitely insightful and worth folks exploring. So until next time, Sam.
Sam Falco: [32:04] Chao.
Outro: [32:07] This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions and information expressed in this podcast are solely those of the hosts and the guests, and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.