Agile Estimation and Story Points

Agile Estimation and Story Points Story points are a way of estimating the effort required to complete a user story or any other piece of work in agile software development. A user story is a short description of a feature or functionality that the customer wants from the product. - [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠ https://www.agiledad.com/ - [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠ https://www.instagram.com/agile_coach/ - [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠ https://www.facebook.com/RealAgileDad/ - [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/ https://www.linkedin.com/in/leehenson/

• 0:15Speaker 00

  I didn't think I'd be talking about this topic again so soon. But someone sent me an article. Now, the thing about this article that blows my mind is that this was published days ago. Okay, so I'm prefacing with this is a days old article, not a years old article. And here's how it starts. Story points are a way of estimating the effort required to complete a user story or any other piece of work in agile software development. A user story is a short description of a feature or functionality that the customer wants from their product. Let's stop there.

• 0:50Speaker 00

  I'm not trying to get on this person who wrote the article. But anyone at this stage in a game who's still trying to figure out what a story point or story is, is a little behind on what they're trying to do. But I do believe that simplicity sometimes is best. And in this case, this is definitely premier simplicity. It's, it's just, it's explaining it in such a way that you can't go wrong. So, so let's continue. Important to mention, as many development teams members misunderstand, story points are not related to time. Hold on a second.

• 1:24Speaker 00

  You've earned my applause. There it is. But rather to complexity. I don't even know that it's about complexity. More than it's about the size of the opportunity or job that they're about to take on. The amount of work. There you go. And they couple in risk or uncertainty. Now here's something that I've learned. If you try to combine, because I'm gonna read the sentence to you one more time. It says, story points are not related to time, but rather to the complexity, amount of work and risk or uncertainty of the task.

• 1:54Speaker 00

  What I found is anytime you're asking somebody to say, okay, in order for you to understand a story point, you need to understand the technical complexity. You need to understand the true scope of the work. You need to understand the amount of risk involved. Technical risk, business risk, social risk. And you need to determine the uncertainty of the task. No one person is going to know all that. And even if they did, it wouldn't stay consistent from viewpoint to viewpoint. So I think in order to solve this, you almost need to make the story point a T-shirt size and relate to the size of the job that's being asked to be done. Even though for one person it may be complex, for another person it could be super simple. Even though for one person it could have a high risk, for another person it might be no risk at all.

• 2:38Speaker 00

  So I think that you have to take some of those other factors out in order to get a true representation, but let's continue. One story point is a unit of measurement that represents the relative size of a user story. It's not an absolute value, but we're comparing different user stories and prioritizing them. For example, a simple task might be assigned one story point, while a more complex task might be assigned five story points. Okay, let's stop there. So a story point is a measurement of volume. I use this example in class a lot of time. For those of you who are just listening to the audio, I'm holding a Coke bottle. This Coke bottle happens to be a 20 fluid ounce Coke bottle. This Coke bottle, we're going to change the name. Now it's a two week sprint. Inside of this two week sprint, it holds 20 ounces.

• 3:23Speaker 00

  But if you've ever flown in an airplane before, their bottles of water are closer to eight ounces. What I'm trying to say is it's likely close to a third of what this one can hold, but they're each two weeks sprints. The difference is on the smaller one, you may have people with less experience who are only able to take on a smaller amount of work. Where people with more experience are able to take on a larger volume of work. So the container is the sprint, the work is the number of fluid ounces or whatever unit of measure you're using. The quantity of work it needs to be consumed. And then the skill level of each person helps determine the size of the container or how much work fits inside of that container, if that makes sense. They're both two weeks sprints. They just may be holding different things. The second thing that I noticed was you use the word task and story interchangeably.

• 4:08Speaker 00

  And that's starting to bother me. So a task is something simple that any developer could achieve to work towards building out a story. Where a story is the unit of measure that requires story points. That's why they're called story points. They're done at the story level. The benefit of using story points is they allow the development team to estimate the work without getting bogged down by the details of implementation such as how long it'll take, what technologies will be used, or what dependencies might be involved. Story points also help the team to plan and track their progress, as well as to adjust their estimates based on their experience and feedback. To estimate story points, the development team usually uses a technique called planning poker. Okay, let's stop there. So the benefit of using story points is they allow the development team to estimate the work

• 4:52Speaker 00

  without getting bogged down by the details. I agree with that. I don't care how long it's gonna take. I just care whether or not it's gonna fit in the sprint. Okay, and beyond that, the other thing that they said that,

• 5:07Speaker 00

  this was interesting, I'm trying to find it, it says, let's see.

• 5:12Speaker 00

  What technology is used between our story points can also have seen the plan and track their progress as well as to adjust their estimates based on experience and feedback. I got that. Let's see.

• 5:22Speaker 00

  Yeah. This is just, there's something about the way this is worded that's throwing me off. Um, yeah, okay, I'm just gonna continue. To estimate, oh, here it is. To estimate story points, the development team usually uses a technique called planning poker. It is 2026. I have not used planning poker since 2016, 15? Uh, and I think part of it is just, planning poker's great, but planning poker uses numbers. And anytime you use a number, here's a tip or a secret. An executive or leader is automatically gonna say, three what, five what, eight what? And then you have to explain that it's not, it's not, it's not anything. It's a unit of unitless measure.

• 6:04Speaker 00

  And when you start getting into that conversation, people get upset by it. So for me, it's easier just to use a T-shirt size and then tie the T-shirt size back to a number in a Fibonacci sequence, where one is extra small, two is small, three is medium, five is large, and eight is extra large. Nothing ever goes in this bigger than eight. If it's bigger than eight, it needs to be broken down.

• 6:23Speaker 00

  That makes it easy and that adheres to your relative measure that can vary depending on team. Well, it doesn't vary depending on team. It can vary based. Oh my goodness. Here we go. So this article, and maybe this is why the first one I'm going to review it. One story point is not a fixed amount of time or work. I agree, but a relative measure, I agree. That can vary depending on team, project and context. I disagree. I think that if you get all your teams together at a release planning session and you have them work to choose a one point story, then you have some consistency across the teams as far as what a one point story is. It won't be perfect and each team have a little bit of a variation, but it should be fairly consistent. The important thing is that the team uses a consistent and transparent

• 7:05Speaker 00

  method to estimate story points and that they review and refine their estimates regularly. I teach my team to keep in mind the following parts of a story point.

• 7:15Speaker 00

  Volume. How much is there? Complexity. How hard is it? Knowledge. What's known? Uncertainty. What's unknown? Let's pause.

• 7:23Speaker 00

  This exercise alone, if you did this walkthrough for each story that's going to be in a single sprint, you're going to hit a three to four hour meeting pretty easy. And what I can tell you is the disappointment is that people will lose their attention span. It's just the way it is. I'm not trying to be ugly about it. People just don't care. Right? And I think based on that knowledge, team members can be more precise in their estimations. That's true. Moreover, they can suggest the estimates to less experienced team members. This,

• 7:55Speaker 00

  I want less experienced team members to understand that the story points aren't going to change because they're less experienced. The size of their job remains the same. If you think about painting a wall, the size of the wall doesn't change. The size of the wall stays exactly the same. The dimensions do not change. The skill level, the painter changes, which in essence should not change in number of story points because the story points are based on the size of the job. In my example, if I had a team of painters and the most experienced painter starts on the harder or the easiest wall and the least experienced painter starts on the hardest wall, the most experienced painter will finish their work and meet the least experienced painter on an easy wall to get things done. If I had the least experienced painter, easy wall, most experienced painter, hard wall, they'll meet somewhere in the middle, but nonetheless, they'll still finish painting

• 8:40Speaker 00

  the same exact number of walls. Now, will the quality be consistent? Maybe not for the first few sprints, but over time, they will pick up knowledge that will help them gain experience so that they can become better at doing the work. A general use a story with one story point is usually a simple, straightforward task. Not again, it's a story that does not involve much complexity, work, or risk. Okay, I'm just going to pause here. They go on to give some examples. They want to talk about a sequel query and how it's large. Okay, but let's, let's just skip. I'm, I'm going to skip the rest of this and, and I want to make sure I say this out loud to the author of this article. I'm not going to say your name because I appreciate where you're going with this to try to explain this to beginners. I really do.

• 9:23Speaker 00

  But I also feel like if you are trying to explain this to beginners and you're using the terms that you're using in the article, that you're going to be giving them misguidance. And I don't know that they'll be able to do their job well. So my advice is maybe, and I'm inviting you, Mr. D, I'm going to call you because that's your first name.

• 9:45Speaker 00

  Why don't you come on over to one of my classes and I'll let you in the entire story point section where I explain it and maybe you'll get some insight on what I use to explain it. Because I think if you heard it using the examples that I use in class, it would make a lot more sense to you and it would be easier for you to teach other people how to do the forecasting estimating. Unfortunately, at this point, I feel like it's articles like this that misguide people and cause people much confusion when they come into my classes. That's going to do it for this one. I hope you enjoyed it. If you have a topic you want us to discuss, learn more at agiledad.com. I'd love to hear from you. And as always, we encourage you to stay healthy, stay well and stay agile, my friends. Until next time, do take care. Bye now.