On today’s episode, we’re talking story points, story sizes, and story planning. What happens when you’re working as a team, and find out that a two is actually secretly a five? What happens when stakeholders come in and add additional scope creep? Today we discuss how to derive those story sizes and some of the things that happen when the point system that you used gets used (and perhaps misinterpreted) by humans. From scope creep, to edge cases, to Planning Poker, sandbagging, and YOGONY – How do we handle external pressure and continue to ship it real good? Take a listen!
Key Points From This Episode:
Transcript for Episode 26. Story Points and Scope Creep
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea Manhattan. I’m your host, Michael Nunez. I have my co-host today.
[0:00:10.6] DA: Dave Anderson.
[0:00:11.7] MN: And our producer.
[0:00:12.0] WJ: William Jeffries.
[0:00:13.3] MN: And today we’ll be talking about story sizes. I imagine as a team, when doing story planning, you have to pick a number or a T-shirt size for your stories. How do you define those story sizes?
[0:00:26.9] DA: Yeah, and when do they creep up? When do you find a two, that actually is secretly a five or three two’s or what have you? Yes.
[0:00:37.3] MN: Or a 13? Or the huge number, we don’t know. Today we’ll be talking about the, how do we derive from those story sizes and how we can keep that consistency going forward?
[0:00:48.1] DA: Also just keep delivering.
[0:00:50.2] MN: Yeah, at the end of the day, you’ve got to ship it all the time, regardless of those numbers.
[0:00:54.3] WJ: Ship it.
[0:00:55.4] MN: Oh yeah. Before we continue, I imagine there has been situations on a team where you receive the story and you mentioned oh no, that is a big story, that is your number 13, that is your double XL T shirt. I imagine William, you may have used dogs before, I don’t know what big dog would be considered.
[0:01:18.4] WJ: Great Dane baby.
[0:01:19.0] MN: A great Dane.
[0:01:20.0] DA: I don’t know. If we’re doing planning poker, I guess, if you have the cards throughout the 13, that’s like the king in the deck or something. But normally if you’re doing hands, you only have 13 fingers, what do you do?
[0:01:35.0] MN: You slam your foot on the table, just slam your foot on the table, get your hands in the air.
[0:01:39.7] DA: Yeah, we talked a bit about that in was it episode three?
[0:01:43.6] MN: Yeah.
[0:01:43.5] DA: In planning meetings, all the crazy ways that you can assimilate stories but regardless, you know, a big story is a big story and when is that big story too big?
[0:01:55.9] MN: Right. I think over time, as the team get more familiar with what is a one or two or three or five. I’m using Fibanaci in my particular example. You then start to realize the things that make it a 13. It could be a lot of like unknowns in the midst like doing a research on a particular third-party API.
There is maybe a whole ton of knowledge transfer because one developer had designed this whole thing and now, this co stack would be – the knowledge needs to transfer to amongst multiple people. That may be first iteration of working on this piece of code could be a 13.
[0:02:38.1] DA: Man, I don’t know. I’ve never worked on a story that’s a 13. It may as well be Infinity as far as I know, which seems like the scope is so broad that you know, you might need to take a breather and think. If you can’t break it down into multiple tasks like if you’re doing the knowledge transfer from the guy, maybe there’s a story just to get the knowledge and then you can work from there and figure out where to go.
[0:03:01.3] WJ: The only time I’ve seen people pull a 13 is when they either A, are pulling it to split it up into like smaller parts or B, they’re pulling it to make a point to show that it was over estimated.
[0:03:13.4] MN: Yeah. I mean, those cars get really good reach but when they do, it’s probably one of those two bullets that you mentioned William.
[0:03:20.1] WJ: Yeah, then sometimes they get burned and it was not over estimated.
[0:03:25.3] DA: Oh no, it’s a one. Hold on.
[0:03:27.1] MN: All along. I mean, if you do get a 13, I’m going to call an honest 13. I think what you mentioned earlier Dave about potentially getting – breaking those stories down to do that might be helpful. An example would be, if you had to do a research on a particular API, you can probably spend time box like a half day on this particular thing.
[0:03:49.5] DA: Yeah, spike it out.
[0:03:50.5] MN: Yeah. I imagine that 13’s are definitely variants between teams.
[0:03:55.7] DA: Yeah, like the teams that I’ve worked on, I don’t think we’ve ever thrown out a 13 but maybe there could be a team where 13 is a regular occurrence and it could be our three or five or what have you. It’s like who’s line right? The points don’t matter in a way.
[0:04:13.2] WJ: On my current team, we adapted a base four system so the smallest point value is four and then it goes eight, 16, 32, 64.
[0:04:23.4] MN: Interesting.
[0:04:25.2] WJ: 64 is equivalent of a 13.
[0:04:27.0] MN: Right.
[0:04:27.6] DA: I kind of like the base too, it makes me nostalgic for gaming. Also just nerdiness in programming in general.
[0:04:35.0] WJ: Yeah.
[0:04:35.8] MN: That is at PlayStation 2, that is a at Nintendo 64.
[0:04:41.3] DA: Right, yeah. It’s a Dreamcast.
[0:04:45.1] MN: That is a Gameboy, retro Gameboy, the one you can throw and hurt someone.
[0:04:51.6] DA: It’s a toaster.
[0:04:51.7] MN: Yeah, exactly. Yeah, I think most teams will have different variants, like you guys mentioned before. I don’t think, if you threw out a 13, you would try to make a point, that’s how heavy that hand was. I mean, it’s two digits, right? It shows that it is a significant amount of time but like usually, if someone even throw out an eight, we would try to discuss how can we break that down to maybe like a three and a five or into smaller parts.
But a 13 is an indicator that this must be broken now.
[0:05:22.2] DA: Have you ever worked on a team that basically refuses to estimate a story above a certain number? Like has a cap for the estimation?
[0:05:31.4] WJ: As in like if it’s above a 13 you just pretend it’s a 13 or as in if it’s a 13 then we have to break it down?
[0:05:40.0] DA: I think the ideal situation is that if it is above a 13 then you break it down. I guess that could be a side effect of having a maximum number, like if your maximum number is five, then maybe there’s like a six or a seven in there. But you’re like, “Well, maybe it could be a five” and then you kind of try to work with that.
[0:06:01.1] WJ: Yeah, it’s like lazy, it’s being lazy, breaking it down.
[0:06:05.6] DA: Right. Although, a lot of cool kids these days are working on single point stories all day.
[0:06:12.7] WJ: Or just not estimating it all, #noestimates.
[0:06:14.5] MN: Hey, watch out, hold on a second. We’re going off a tangent on the topic of the podcast right now.
[0:06:21.4] WJ: That’s right, bring it back.
[0:06:24.5] MN: No, we need stories, stories are the way to go, no. I’m kidding but I do like the idea of just like knowing how much effort is going to happen before the work gets done because you don’t want to be surprised but there are times where you are surprised.
[0:06:40.0] DA: Yeah.
[0:06:41.0] MN: That is, could be, you know, catch you off guard. You kind of wasn’t the all these known became unknown unknown’s. It’s just like ridiculous so you get these crazy scope here where a two point story became a five. Then what? What did that mean? What does a two mean now to the team? It gets really weird at that point in time.
[0:07:06.3] DA: I think the thing that happens when a story, a two becomes a five is that there’s additional features or things that you didn’t account for. If you’re trying to make a feature that’s based off of day times, maybe you’re like “Okay, there’s a base condition here.” Where you know, it’s a Monday through Friday but then you know, what about Saturday?
What about like Monday on a holiday, on a leap day, and like daylight savings time and then there’s all these like little sub things that kind of keep on coming up the edge cases.
[0:07:43.9] MN: Right.
[0:07:44.0] DA: That you have to consider and maybe you could break those off into different stories or maybe you could continue with the same story and expand it.
[0:07:53.0] WJ: I think the trick is having the self-restraint to break it off and do it separately, this is really tempting as a developer. You think, “I have all of this context loaded up into my brain, it would be easier for me to just do it now than it would be to make another story and potentially have somebody else do it later.” And that’s 100% true.
The problem is that you may end up spending so long working on all those edge cases that you end up putting your time and energy into low value work at the expense of how far you work.
[0:08:27.9] DA: Right, it’s not work that was prioritized or promised on something in the week necessarily. Like you may have a certain understanding of what’s important and you may have accomplished that thing. But now you’re going down into like, the land of perfection, you’ve really polished everything, every possible edge case, all but different features.
[0:08:46.5] WJ: Gold plating.
[0:08:47.0] DA: Gold plating, so shiny.
[0:08:49.8] MN: Do you feel like there are teams that kind of have external pressure to estimate a certain story and like how does the developer have the ability to ensure that they’re not being pressured to do so?
[0:09:05.2] WJ: I’ve seen that so many times, I can’t even count.
[0:09:11.4] MN: It happens where it’s like, yeah, it’s like a two, yeah. Put it two down, we’ll deal with that later and then like I mentioned before, two becomes five.
[0:09:21.0] WJ: It’s like, often not even intentional but you just have a senior person who is in there like, “Oh this is definitely a two.” And everybody’s embarrassed to say that it’s not even, when the senior is wrong.
[0:09:29.8] DA: Right, yeah, that’s true. I mean that’s why I like planning poker is like I guess, interesting because then everyone can actually have a say without really sticking their neck out too far or like being called out on it. Then people can explain why they feel that way.
[0:09:50.0] WJ: You’ve got to be strict about not letting people poison the well by saying what their estimate is. Or you know, generally what the estimate ought to be before the cards have gone out.
[0:09:57.8] MN: Right.
[0:09:58.7] DA: Got to do a one, two, three, shoot guess and then everyone could then throw it out at the same time. Yeah, I never realized that they work hard for planning poker until today, that’s a today I learned.
[0:10:11.3] MN: Today you learned that there were planning poker cards, actual cards.
[0:10:14.7] DA: Yeah, that sounds like a lot of fun and like it’s actually, keep it confidential because I know when you’re like throwing out numbers on your hand, it can be easy for people like kind of subtly morph their estimate.
[0:10:28.6] MN: Yeah.
[0:10:28.9] DA: As they say, kind of look around, maybe two.
[0:10:33.9] MN: Using your fingers right? Now, when you have to throw a card down, you can’t – you look like you’ve changed the number.
[0:10:41.4] DA: Unless you’re like David Blaine.
[0:10:46.8] MN: David Blaine, if you’re listening, don’t bring the cheap cards to planning your poker, it doesn’t help anyone.
[0:10:52.5] DA: Stay out of my planning.
[0:10:53.9] WJ: We actually just made some custom planning poker cards at my client today, me and my pair, it was super fun. My drawing skills are direly lacking.
[0:11:05.5] MN: You wrote them on index cards?
[0:11:07.3] WJ: We didn’t have index cards so we folded stickies.
[0:11:10.1] MN: Nice. You just wrote one – what was the planning poker phase?
[0:11:15.0] WJ: Well, we’re using games.
[0:11:16.3] MN: The four, right? Okay.
[0:11:18.9] WJ: There was like – go would be the equivalent of a 13 pointer in our case of 64 pointer and then it goes, chess, checkers, tic tac toe and then hungry hungry hippos. It’s the simplest game. You just smash.
[0:11:33.9] MN: You just smash till you get all the beads. Yes.
[0:11:40.3] DA: Those folks who just want to do story, size one, all the time, every day, they just want to play hungry hippos.
[0:11:46.5] WJ: So you think.
[0:11:46.9] DA: To smash it.
[0:11:48.1] WJ: I’m so hungry.
[0:11:48.9] DA: Just crushing it.
[0:11:52.3] MN: I have a deck of the – I think mountain goat software, planning poker and it’s like a full deck of cards and you can pass out cards amongst your team. I think it comes for six people and each has a one, two, three, five, seven – no, one, two, three, five, eight, 13 and then the Infinity symbol. So if you got something bigger than an Infinity then probably you are going to have two cards but then you shouldn’t get to that. 13 should be max and then Infinity is like if you want to make that point that we’ve discussed earlier, you slam that Infinity card but –
[0:12:27.8] WJ: Is this just create Infinity or continuous Infinity?
[0:12:30.7] MN: It’s just the Infinity logo and it’s bigger than 13 and it is bigger than all the cards in the deck and it is bigger than any number I guess.
[0:12:38.8] DA: I feel like Infinity if you’re throwing that down, it’s like I refuse to just – it is physically impossible, if you are breaking down a 13 sure. You can theoretically break it down into six two’s and a one but you can never break down Infinity. It is always Infinity.
[0:12:56.8] MN: Oh yeah.
[0:12:57.3] DA: It is mathematical certainty.
[0:12:59.6] MN: Right, I mean that is probably why that card exists just to like, “Nope, there is no way you can break down this” where it’s feasible for the MVP that we currently have.
[0:13:09.7] WJ: Or there is no way to do this ever, no matter what. This is an impossible task.
[0:13:15.0] MN: Yeah, so I think one of the ways that developers can communicate with the product owner or the project manager is when go creep occurs because it happens. We just have to ensure that we use the following word or acronym, YAGONY, which is I believe is, You Ain’t Going to Need That or You Ain’t Going to Need It. Someone help me, I forgot what it is. I can’t say it all.
[0:13:43.8] DA: Come on just say it like you’re from the Bronx.
[0:13:46.7] MN: “You ain’t gon’ need it” that’s why you don’t need it. So I never spoke to my project manager in that way, “Yo Bobby you ain’t going to need it, don’t worry about that.” So I guess I should start using that phrase in that accent that will work out for me.
[0:14:01.7] DA: Yeah, drive it home.
[0:14:02.6] MN: Yeah, if you ain’t going to need it, chances are you can cut down this scope creep very drastically and that you just build exactly what you estimated and if something comes along, you can create stories later on to that, add to that.
[0:14:15.2] DA: Yeah.
[0:14:15.7] WJ: There’s two sources of scope creep right? One is us which we’ve talked about but then the other is the stake holders.
[0:14:23.2] MN: Right, yeah.
[0:14:24.6] WJ: Sometimes the stakeholder looks at what you’ve delivered and says, “Well but it is missing these four things that weren’t actually in the original story.”
[0:14:32.9] MN: Yeah.
[0:14:33.5] WJ: And then that I think is where it gets hard to push back.
[0:14:36.9] MN: Right, you did have to mention that there needs to be some consistency when planning for these stories that these features are there when they get to see it and I think part of like – I mean this maybe bleeding until like sprint planning and like how sprints are helpful. but if you get to show that to your stakeholder with one week iteration sprints, then they can definitely make that change a lot earlier than if you had three months to build this thing and then they have changes suddenly.
[0:15:10.2] DA: Yeah, you’re right. There is a lot of chance to be like ‘you’re not going to need it right at this moment but maybe next week, you know? You might need it lets figure it out then not now.”
[0:15:22.9] MN: So suppose the team has been dealing with a lot of scope creep related issues, right? A lot of stories of twos have become three’s or five even eightS, what are some ways you have seen teams kind of handle that particular situation?
[0:15:39.3] WJ: Well you could sandbag your estimates and just pretend that everything is a bajillion points.
[0:15:44.8] MN: Right, you may like if the story is a two then you would say, “Oh that’s a three” just covering you an additional point to ensure that you can get your work done in a three?
[0:15:55.3] WJ: Yeah but it’s like inflation and then your velocity goes up and then people expect you to be able to deliver more and you got to just keep on sandbagging harder and harder.
[0:16:03.8] MN: I see.
[0:16:05.2] DA: It seems like a winning strategy.
[0:16:08.9] MN: It’s like, “Yes we delivered 250 points today, thank you.”
[0:16:14.5] DA: You don’t need that Infinity card. It’s like money in Zimbabwe.
[0:16:18.2] MN: Exactly.
[0:16:20.0] WJ: This is a one trillion point story.
[0:16:22.2] MN: Yes, yes. We did three Infinities in this sprint session. Yeah, so imagine sandbagging is like a short way of solving the problem but at the end of the day, you want to ensure that you are not sandbagging too many times because it will hurt you in the end.
[0:16:40.0] DA: Yeah, how do you broadcast escape crew to stakeholders? Do you guys think it is a good idea to re-estimate a story mid-sprint or just breaking off into a different story? What do you guys prefer?
[0:16:54.8] WJ: I like to break it off into a different story even if somebody insists on it being done that sprint. Then at least if it is in a separate story then you can point to it and you say, “This wasn’t pointed and it got brought in.”
[0:17:08.4] MN: Right. Yeah, I think a way to ensure that transparency in the work that is getting done is very helpful when you have that system where you can create another story and then say, “Oh we have this. It didn’t have this particular feature so we are going to pull that story into this sprint,” to ensure, we could bring all of that together.
I personally would like to if possible to put it in the next iteration. That way the project manager is aware that these features didn’t exist in that one card. Then do the extensive research to asking the product owner and figuring out what else needs to get done in these stories and then prioritize those.
[0:17:47.0] DA: Yeah, I like that and there is some visibility. You’re shining a light on what is going on rather than sweeping it under the rug.
[0:17:55.7] MN: Cool, speaking of shining light, I will turn on the light in this room.
[0:18:01.8] DA: Blinded, yeah. Actually like to the opposite point of sandbagging. It’s interesting where maybe you underestimate a story just to be like, “Okay I don’t want to expose the scope to do.” The stakeholders will be like, “Okay”, there are these edge cases that I really want to cover too preferably to polish this feature and you don’t want to call attention to other people who might be paying attention. That I am going to be doing this work in addition to what you’ve asked us to accomplish for this week.
[0:18:42.1] MN: Oh so you are saying to actually estimating lower than what?
[0:18:46.3] DA: Or like working on a story and then coming to a point where you should be making it out of your story or increasing the estimate and then being like, “Well no. I don’t want people to know about this so I am just going to work on this.”
[0:18:57.3] MN: Oh I see but then it messes up what is that particular number, right? Because if you have a two and two’s have been known to take a day but then suddenly you have this two that takes three days. It’s like “Oh whoah, whoah, whoah.”
[0:19:11.6] DA: Right, it’s the two that took a sprint.
[0:19:13.4] MN: Yeah.
[0:19:14.0] WJ: But now you are getting back into converting points into time.
[0:19:17.4] MN: Yeah and you want to avoid doing that. You just know that a two is bigger than a one.
[0:19:23.5] WJ: Yeah, I mean I guess like a two could consistently start taking more time and energy than a five. If one person consistently picks twos and sandbags but you’d think that it would be actually pretty hard to pinpoint if somebody is doing that. As long as it is only one person.
[0:19:41.2] DA: Right, yeah. That makes sense.
[0:19:45.1] MN: Cool, so I think that was just a little bit of a story points and what are some of the things that happened when the point system that you used gets used by humans, who may then misinterpret certain things. What happens when stakeholders come in and add additional scope creep, how to handle that and continue to deliver. At the end of the day, you still got to ship. You got to ship it. Always got to ship it.
I think we mentioned earlier today, our teach and learns was Dave, I think you mentioned the planning poker and using that, that was pretty cool.
[0:20:21.7] DA: Yeah, I learned about that and –
[0:20:23.2] MN: About the fact that they’re a real thing, a real –
[0:20:25.6] DA: Yeah, I love it. I love the physical objects in the real world. That’s always nice. Actually I had another thing that I learned about recently as well, or learning more about. So I had seen really nice demos of Graph UL, how you can use it as core language to get out your database from the front end without relying upon a structured end point and I’ve been digging with that a little bit more and it’s been pretty fun.
[0:20:56.3] MN: Nice.
[0:20:56.8] DA: Yeah, there is this nice graphical, Graph IQL interface that you can use. You just do bru install at bru cast install graphical and then you get a little client and you can put the name at the end point and then start hitting it out with queries and get back with results and look at the data dictionary of what all things are out there. It’s pretty nice. It’s a good tool for iterative to the element of queries against your database without using a structured end point.
[0:21:29.6] MN: Nice, yeah. I think I have heard a lot of good things about Graph IQL. I think I have to learn that sooner than later.
[0:21:35.1] WJ: Yeah, it’s the new hotness.
[0:21:37.2] MN: Yeah, all the cool kids are using it and this is why Dave is learning it.
[0:21:41.9] WJ: He’s the coolest of all cool kids.
[0:21:43.5] MN: They say you are the coolest of all kids.
[0:21:45.7] DA: I’m a cool baby.
[0:21:47.5] WJ: What’s up you cool baby?
[0:21:50.6] DA: Trademark.
[0:21:51.1] MN: There you go, awesome. Yeah just going to close it out. I like to thank my cohost, Dave thank you.
[0:21:58.9] DA: Yeah, it’s always a pleasure being on the show.
[0:22:01.4] MN: Awesome and our producer, William thank you so much.
[0:22:04.3] WJ: Anytime.
[0:22:05.2] MN: And you can reach us at twitter.com/radiofreerabbit. I am Michael Nunez and this is The Rabbit Hole. We’ll see you next time.
Links and Resources:
