In today's episode, we dive into the subject of estimations and pointing. For most teams, there needs to be a way to communicate the size, complexity, and difficulty of any task or project, and the different frameworks that have gained popularity have degrees of utility, strength, and weakness. To get to grips with these, we discuss, planning poker, t-shirt sizes, dog breeds, board games, and the interesting case of gummi bears! So to hear all about some ideas that you may find useful, or completely useless, tune into the Rabbit Hole, today!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 225. Estimations and the different variations of pointing
[EPISODE]
[00:00:00] MN: Hello, and welcome to The Rabbit Hole, the definitive developers podcast, living large in New York. I'm your host, Michael Nunez. The producer today –
[00:00:09] WJ: William Jeffries.
[00:00:11] MN: Today, we'll be talking about estimations and the different variations of pointing. I think, William and I have been in various software engineering teams. We have seen the many different ways that people do estimations. We'll talk about the ones we like, the ones we thought were weird, and some new discovery to me, at least.
[00:00:33] WJ: To me as well. There's just some weird facts.
[00:00:36] MN: Yeah. These are weird facts. I don't know where it came from. It might have been in the industry for some time. If this is not weird to you, and you were aware of this, I would love to hear it, because A, I'm going to think you're lying. B, I love to hear if you actually used it before. Because it'll be really interesting to know that this was out in existence, and people actually use it on purpose.
We'll go right to it. We're going to jump right to the first one on the list, which is A, the best way to estimate is to not estimate. What do you think about that one?
[00:01:12] WJ: Just don't do it. Friends don't let friends do story points.
[00:01:16] MN: Friends don't let friends do story points. Now, I don't think I've ever been in a team, where we didn't do story points. I know of it existing though. Have you ever worked in a team that did no estimates?
[00:01:30] WJ: Oh, yeah. Definitely. I think, they fall into two categories. Extremely low-performing and extremely high-performing. Those are the two places where you tend to see no estimates. It's like, either nobody knows what they're doing. They've never heard of story point estimates. They're working off of some garbage to do lists that's full of tasks, some of which aren't even really tech related. Nobody really knows how long anything is going to take. They're just sure that they're behind schedule.
Eventually, somebody comes along and it's like, “You should maybe have a process here. Why don't we try and come up with a velocity, rather than trying to just guess how long things take?” Then, we have a little more leeway, and we can do some better planning.
[00:02:11] MN: Yeah. Then, that's like the, I guess, the no estimate in that aspect is the gateway drug to start estimating points, if you will. Eventually, a high-performing no estimate engineering team is one that still has that planning process. You have your, I think you mentioned before, you have your iteration planning meeting, you have your refinement meeting to make sure that the stories are well crafted, and everyone knows what is expected of the work that gets done. At the end of that description of that story, you don't point. That's just the only difference, right?
[00:02:47] WJ: Yeah. I mean, I think that if you're talking about the expanding brain meme, you got pea brain is like, we don't do story points, because we've never heard of them. Then, you have a glowing brain, which is like, we do story points, and we have a sense of our velocity. Then you're like, mega brain, it’s like, we do story points and we have a really stable velocity, and management doesn't even really care anymore, because they trust us. The galaxy brain is like, we don't even bother pointing anymore, because our process is so good. We just always write great tickets.
[00:03:25] MN: Exactly. Eventually, you can fall out of the no estimate, once your process is well-crafted and well-rounded.
[00:03:34] WJ: I think, well, part of it is like, you do the points so that you can estimate your velocity and have a sense of what you're going to complete in a given time period. That's usually because management cares, because management wants to do some long-term planning with that. Really high-performing teams, they get value out of the grooming, and making sure that the tickets are easy to pick up and good. Once you have the muscle memory and you are writing stories well, generally speaking, and there's really high trust, you don't need these reports to show to management with all these estimates, like all this estimate. It becomes waste and you can eliminate it.
[00:04:13] MN: Right. If no estimates is something that your team does, I think that you're at a point in time where you are mature of a group enough to be able to move forward without estimates. Definitely an interesting way to do your estimations. The best way to do it is to not do it, I guess.
Next up, we have something that's a little bit more familiar to some folks, to me, especially and it's planning poker. The idea of planning poker is you legit have a deck of cards. I remember, I don't know if you've actually used – Have you ever used cards, William, like physical cards?
[00:04:45] WJ: Yeah. Mountain Goat software had a deck that they put out. I think, it used to be, you could order branded decks of planning poker cards for your company.
[00:04:54] MN: Yeah. Kevin Thomas from the show got me a deck of cards that I used at the company that I was consulting in. We used it to do it one time, and it's a great experience. The cards have numbers on them. 012-358-13-20-40 and 100. People will read the story, get an understanding of what it is. You 3, 2, 1 shoot, and you throw your card, and whoever has discrepancies can have a conversation and you talk about it with the cards that are there.
I think, that is the most standard way of doing estimates I've seen, which I thought works at every team. Anytime that it's introduced, everyone seems to like it, enjoy it and it leads to a healthy debate, why someone may have thrown a three versus a five and what that means.
[00:05:45] WJ: Yeah. There are apps online you can get that will do this as well. Or, you can just have an anonymous Google Doc. It's really helpful if you can have the reveal happen at the same time for everybody, so you don't have that thing where everybody looks at the most senior person on the team, or the person who's most familiar with that corner of the codebase and they just copy whatever number that person feel was.
A lot of teams would just hold up fingers. Invariably, that's what you see. Or you do it over a Zoom call and people are just posting into the chat. It's like, people wait until somebody else goes in and they just copy.
[00:06:21] MN: Yeah, exactly. I think, that software, definitely can help, so that it is revealed all at the same time, which I think definitely works, versus a Zoom chat, where everyone's spamming three. Because that's usually the number that gets thrown out for every story. Planning poker is good and it's standard. I imagine, if I had to introduce estimations to a client, that's probably where I would start.
We're going to take a turn into something a little bit more interesting in terms of what items, or physical objects we use for estimations. The one that I've seen in a team that I worked at and was introduced to, is t-shirt sizes. Everyone knows a particular t-shirt size. They start from extra small, small, medium, large and extra-large. A story can only be comprised of those five things. People will estimate what they believe the t-shirt size of that story is. Have you ever worked on a t-shirt size team before?
[00:07:28] WJ: Mostly, I've used t-shirt sizes for epics. Then, you reduce the range to just small, medium, large, with the idea being that epics are so hard to estimate, that you can't get as granular. Whereas, with an individual story, you could do Fibonacci.
[00:07:48] MN: Right. Oh, so you mean segmenting the different parts of a particular feature, you use one type of system?
[00:07:57] WJ: No. For an epic. If you have an epic that's like, we're going to build, I don't know, a payment system for the app. That's a five. I have no idea, man. That sounds like a very large t-shirt. It's definitely not a small t-shirt. Probably not a [inaudible 00:08:10]. To try and get as granular is the difference between a five and an eight, implies the degree of understanding of the problem that you don't have.
[00:08:21] MN: Right. Then as I was saying, so if you use t-shirts are use for the larger scope of a particular feature set, while using planning poker can be something where you can be more granular about it.
[00:08:35] WJ: Yeah. I hate t-shirt sizes as a metaphor, because I feel the difference between a medium and a large is not that big. There's not that much, when I'm visualizing t-shirts. I feel like, I can buy the wrong size t-shirt and still wear it. It’s fine.
[00:08:52] MN: Exactly. I just buy the large now. I don't even care. I just buy large t-shirts. Yeah. No, that makes sense, though, right? Because maybe a small to a large, you can see a difference. A medium to large look very similar. You'd have to wear it and see where it fits on you. I don't know who's wearing the t-shirts, now that I'm saying that. When we're estimating stories, the t-shirt size is for who? We put it over the epic, or the computer? Is that what's happening?
[00:09:21] WJ: Have you done dog breeds?
[00:09:22] MN: No. I mentioned before, I am not a resident dog person. I'm terrified of dogs. I need to know more about these dog breeds, though, because you mentioned that you have done estimations in terms of dog breed points, and I need to get a list of those breeds. How did that work in your team?
[00:09:39] WJ: I mean, I think there are a bazillion potential dog breeds that you could use. One thing that I like about dog breeds is that they're so far removed from math, that I think it discourages people from trying to do any kind of summation.
[00:09:53] MN: Interesting.
[00:09:54] WJ: Which is an interesting approach. Yeah. I mean, I think if you're converting it into Fibonacci, then that's cheating. Also, I like the idea of a chihuahua is a lot smaller than a Great Dane.
[00:10:05] MN: Yes. That is correct. I mean, I don't know anything about dog. I just know those are two very different types of dogs. Chihuahuas are very tiny and Great Danes are huge.
[00:10:15] WJ: Chihuahuas getting vicious. Just because they're small, doesn't mean they're not going to bite you.
[00:10:19] MN: I mean, those are the dogs I'm terrified. All of them. I mean, but I'm terrified for that very same reason. Chihuahuas don't play.
[00:10:26] WJ: Well, it's true.
[00:10:27] MN: Do you remember, like, did it range from Chihuahua to Great Dane? I know of pitbulls and bulldogs. Did you all have a favorite five, or was it people were just more familiar with dog breeds and was able to share what dog breed that particular story felt like?
[00:10:45] WJ: I think, the only time I did this, we had some dog breeds picked out there. I think, it would be fun to just name whatever dog breed you find. I think, it really gets at that the randomness and unpredictable nature of story pointing. It’s like, I don't know. Is it that small chowchow, or a big chowchow? A chowchow can vary a fair amount in size. Also, how much is there really in the chowchow? Because it's like, a lot of it is just the fur. That’s a very fluffy dog. Not a lot of meat on the chowchow.
[00:11:18] MN: Exactly. I mean, but it's definitely is different from say, a Siberian Husky right? You know for a fact that that is completely different dog. I do like, if I had to look at a dog on images on the internet, Pomerania Husky, my favorite. Siberian Huskies, I think they're a beautiful dog. I know that I'd be terrified if I own one. It would own me. A Pomeranian Husky is cute. I like those guys. If I was working on a team that did dog breeds, though, I probably would research dogs every day. Then always randomize them if possible. Just so that I can get them – It's like this, or that and they'll be more – that'll be one step closer to losing my fear towards dogs. I think, that's the goal.
Well, you mentioned before another use of estimations was games. When I thought that this was really, really interesting, where you select your team, select the five different games, right?
[00:12:14] WJ: I thought this was a good idea. The guy who came up with it had a list of games of varying degrees of complexity. The idea was to capture the fact that what makes a story difficult isn't a question of volume. It's a question of complexity. It was like, Tic Tac Toe is a pretty basic game. There's not a lot of complexity there. You can count the total number of permutations relatively easily.
Go is a super complex game. We don't have computers that are powerful enough to brute force a Go game. Whereas, a human being could brute force Tic Tac Toe. There’s a tremendous difference in the degree of complexity in a problem, even though the board might be a similar size.
[00:13:06] MN: I see.
[00:13:07] WJ: Pick up sticks, I think, was the most basic and then Tic Tac Toe and then checkers and then chess and Go were the five.
[00:13:15] MN: Right. Then, it's very similar, even the example of checkers and chess. You can play those games on the same board, to my knowledge. I think, there's black and red in the checkers board, and black and white, but I think it has the same size, so in order to play a game, please correct me if I'm wrong. The rules of the game are different and it is more complex, checkers versus chess to mind, if I recall.
[00:13:36] WJ: Yeah. In checkers, all the pieces are the same. In chess, every piece is different and they have their own rules. You're right. It’s an eight by eight grid, for both of them.
[00:13:45] MN: I think, that would be a very interesting way of – I think, as you mentioned before, this also takes away from the mathematics of trying to put a game to a amount of time that someone spends on a particular story. Because you can play pick up sticks and the length of pickups sticks depends on how many sticks you need to pick up. It's like, it's very, very different and far removed from math.
Okay, so this is the one that we were doing research on this particular topic. The one that was very, very strange to me, and William, please let me know if it's something you've done before, was gummi bears. Have you ever heard of the gummi bear system?
[00:14:32] WJ: I've never heard of this. This is some news to me.
[00:14:35] MN: This is very, very news to me. I was trying to look up the – if you haven't checked out the agilealliance.org, they have a glossary with all sorts of different words and meanings and definitions and pitfalls about certain things. I was looking up. We were looking up the points and found that in extreme programming, a standard that was used in the early days of extreme programming was gummi bears, which A, first off, I love to hear those folks who are doing the gummi bear system and their health and whether they're diabetic now or not. It was just very, very odd way of estimating stories.
I will do my best to do a reading from c2.com for actual gummi bears for estimation. It goes something like this. "Each programmer gets a bag of real physical gummi bears at the computer to munch on while programming. The contents are counted out before and after a programming session. Programmers should be instructed to eat them at least a certain baseline rate representing work done, while motivated and yet, not required to think, say one per 15-minute of perfectly in the group work. I guess, that's the talk about when they're in the zone and stuff. Without an upper limit.
A programmer who notices a sharp increase in his or her own, or partners in the case of pair programming, gummi bears of complexity intake should treat this as a thought smell and step away to think about the task at hand, or switch roles. The idea is you take a bag of gummi bears and you set them down. As you're working on the story, you pick up a gummi bear and eat the gummi bear. If you are working efficiently and in the groove as it says in this little passage, you may complete the work in X amount of gummi bears that you're familiar with. Does that make sense at all to you, William? Have you ever had done that with a snack, like with M&Ms, or with gummi bears, or gummi worms?
[00:16:52] WJ: Yeah. I find snacking during programming to be super dangerous, because you can just consume a huge volume of gummi bears, or whatever the snack is.
[00:17:00] MN: Exactly. Who eats one gummi bear at a time? Don't tell me how to live my life now. I'm going to take a handful, if I have to, if I need to, especially if I'm anxious about a problem. I think, that's what this is trying to capture.
[00:17:10] WJ: It feels like Japanese water torture or something. You have to wait another 15 minutes before you get your next gummi bear. Try and focus on work with this gummi bear right next to you. You're not allowed to touch it for 15 minutes.
[00:17:22] MN: Yeah, exactly. As the gummi bear is staring at you, “Please, eat me. I am delicious.”
[00:17:27] WJ: It's like the marshmallow test for kids, for programs.
[00:17:31] MN: Yeah, exactly. For adults, programmers, right? The resulting context according to the article is each programmer develops his, or her own metrics for task complexity. Based on past history, he or she can expect to eat X many gummi bears while completing the next task, following the usual practice. Based on current load conditions, he/she can then translate that into time estimate, if need be.
You look at a story. Let's try this thought exercise. While you're looking at this story, say we need to, I don't know, suppose we were working at Facebook and we had to create the thumbs up feature. I don't know. It just comes into mind. Wait, how many gummi bears you think that would take for you? The fact that you would know a number and you'd be like, “Yo, Bobby. This will take me 12 gummi bears to eat.” I’m like, “Cool. 12. Let's put that on the board. Get to 12 gummi bears. Let's go.” Could you think of a scenario in your past where you would have thought in terms of gummi bears?
[00:18:33] WJ: No, definitely not. I mean, I think that this is getting at the idea of uninterrupted quality work hours, which is a metric I've always hated. Where they're like, you should have five quality work hours during the day. It's like, you're getting too precise with your time estimates is unrealistic. You can't guess that.
[00:18:55] MN: That's the point of estimates, because we can estimate the amount of time something's going to take, but it's not the actual amount of time. I think, this might lead to it's just, you're avoiding the question of why did it take so long, to why did you have to eat so many gummi bears? I mean, this gummi bear thing is pretty interesting. There are some drawbacks. I'm not going to read through those.
[00:19:19] WJ: Diabetes. It's one of the drawbacks.
[00:19:22] MN: Yeah. No. One of the drawbacks here in this list says, you'll kill any diabetics on your team. I'm guessing, they were aware that people who are using the gummi bear system for estimating points are more likely to A, kill any diabetics. Or B, introduce diabetes to a developer's life, which I don't think that is a good thing we should do. We should be building healthy –
[00:19:48] WJ: Celery sticks.
[00:19:50] MN: Celery sticks. The celery stick system. Yes. We should definitely think about more healthier ways of estimating. If you would change, I think celery sticks is a great addition. I'm curious to hear, what are some other ways we would change this food estimation system? For celery sticks. I had M&Ms in mind. Again, that'll lead to diabetes for sure. Almonds, maybe? I don't know. That seems like –
[00:20:19] WJ: Almonds are like, those pack a punch. Those are calorically dense.
[00:20:23] MN: Yeah. I mean, yeah. Then you’d feel full at a day's worth of work, if you have – if a story takes 10 almonds, then you might be like, “Okay, and I'm done for the day. I'm good.” Yeah, I'd be curious to hear what other kinds of food you would use to estimate, and if you actually use gummi bears. If this is a thing you've done in the past, I would love to interview and talk about how this system worked out for your team. Did everyone get diabetes? Did they find it effective? I'm just really curious, because this came right into our laps, and I wanted to share this with individuals.
[END OF EPISODE]
[00:21:02] MN: Follow us on Twitter @RadioFreeRabbit, so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into The Rabbit Hole. Never miss an episode. Subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries, and my amazing co-host Dave Anderson, and me your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
