Playing Planning Poker

Doug Rose
A free video tutorial from Doug Rose
Publications, classroom and online training
4.5 instructor rating • 3 courses • 11,194 students

Learn more from the full course

Advanced Agile and Scrum (PMI 8 Contact Hours)

How to become an effective Scrum Master and Scrum team

08:08:26 of on-demand video • Updated September 2019

  • Learn how to use Scrum to deliver software or information technology (IT) products with a more agile mindset
English [Auto] So that's why a lot of teams use something called story points, this is how you can create your affinity estimate. You come up with a point system and say, OK, we're going to sign this this number of points and then we're going to figure out how many of this story that we don't know compared to this story, how many of those fit in this. So you're creating an analogous estimate on the work you've already done. But the key thing to remember is you're measuring size and complexity. I've seen a lot of teams that use story points just like a measurement of time. They'll just be like, well, eight story points equal one day of work because it's eight hours or four story points equal four hours or each story point equals a day. And that only sort of gets you into trouble because if you're going to do that, you may as well do actual estimating and then you run into some of the challenges with actual estimating. You sort of you have trouble estimating as a team and you're more likely to add padding, which makes it difficult to deliver at a predictable pace. Now, typically, to assign story points, the team will do something called planning poker. Now, there's a little bit about playing poker in the exercise packet. It's a great exercise. Playing poker is one of my very favorite activities that you have in a scrum team. It's sort of like a great practice. And so you start out with playing poker, you can get a deck of cards and they have the Fibonacci sequence of numbers on them. So now the planning poker decks typically have a zero one half of one two three five eight, 13, 20, 40, one hundred. And sometimes there's an infinity sign. So now you might notice that the Fibonacci sequence, you kind of add the number before it and then you sort of added onto the number for it at first. And so now most scrum decks modify the Fibonacci sequence slightly to give you a little bit fewer numbers. But typically they'll be a slightly modified version of the Fibonacci sequence. And so the reason they do it that way is they find that it's easier for teams to come up with relative estimates using these numbers. So typically what will happen is that you'll see in the exercise packet that a developer or a scrum master will ask the product owner, what's the top, the highest value user story? And then they'll throw it down in the middle and everybody will pull out a card to give the user story a high level estimate. Now, the scrum master is key in this meeting because they help facilitate it. They make sure that it doesn't break the time box, but they also make sure that people aren't cheating. Sometimes this meeting can go a little long. This event can run a little long. And so people just throw it on a car and they say, well, you know, Sharon knows way more about this than I do. So I'm just going to go with Sharon. So in this planning post, you want to make sure that each team member looks at the user story and then puts their card down, face down so that they're not influenced by everybody else and everybody flips it at the same time. So the scrum master should make sure that everybody's putting their card down, that they're giving a real estimate. And if there's a lot of discrepancy, then you have the people discuss it with each other. One of the key things to keep in mind about playing poker is that it's based on wideband Delfi. Now wideband data is not a estimation technique, it's a group discussion technique. So in a lot of ways, the output of the planning poker meaning is almost inconsequential. What's really important is having the discussion is having the team understand what is involved in delivering the user story so they create a relative estimate. And that's the first time that the team sort of has a discussion. The development team has a discussion about what it will take to deliver the user story. But they always have to think about the user story in terms of effort and not time. And that's often the consequence of many years of coming up with estimates and patting them and thinking about these things. In terms of time, how long will it take you to develop that website? It'll take me about two weeks, even though it'll probably take them only about eight days. But you pad it because you might run into something. So people who estimate with time usually are thinking about things as an individual. They're just like, OK, this is how long it will take me to develop this thing. And you don't want the team to think that way. You want them to think of this group. And so that's why you want the relative estimate. Everyone should reach consensus about how difficult it is to deliver that user story and what kind of relative effort it will take to deliver that user story. Now, one of the key things to remember about planning poker is that it combats groupthink. Now, groupthink is the classic we all agree. So we must be right. And so when you get together with a bunch of developers and you start talking about the product, then you might have a couple of people. That don't say anything, you know, there's there's something out there called the Dunning Kruger effect where sometimes the quietest people are the ones who actually are most likely to be right. And so you have a couple of people in there who are stronger personalities and they say, well, this is an eight and everybody sort of the quieter voices in the room might be like, well, I actually think that that might be, you know, actually a five. But I'm not going to you know, I'm not going to cause too many problems. I'll just go with an eight because let's just get this meeting moving. So you as a scrum master, you want to make sure that everybody puts the card face down and when they flip, they have a real discussion. So don't think about the estimation session. Don't don't focus on the importance of the estimate. Think of this as an anti groupthink activity. Everyone needs to discuss what it takes to deliver the product. And the reason I like this practice so much for scrum teams is because it is it's the first time that the development team will look at the user stories and really talk with each other about what it will take to deliver that user story. Now, a lot of times during this estimation session, they'll break down that user story into smaller user stories because everyone will kind of reach consensus that this is much more difficult than they first thought. Or they'll just say, OK, it's much easier than we first thought. So, but the important part there is the scrum hesters to make sure that people aren't sort of just trying to come up with a number so that they can go to lunch or whatever, just so they can end this meeting. You want to make sure that they have the discussion. I've seen many, many scrum teams that say, OK, well, we just give this. Of course, we can move on or, you know, give this or whatever so we can move on. And that only frustrates the purpose of this of this practice, of this meeting is because you want the team to discuss this. You want to avoid groupthink. You don't want you want to give the quieter voices in your team a chance to advocate for what they believe, because a lot of times those quieter voices are more likely to be right. And you don't want strong personalities in your team sort of guiding how long it will take to deliver each user story. So don't think of this as an estimation session, even though it's called planning poker relative estimation. Think of it more like a.. Group. Think a good time to have a very good group discussion. Everyone should have their cards face down. They should flip it over as the scrum master. You probably want to someone who has the largest number talking to the person who has the smallest number and then have them discuss it and then flip. So you see a little bit more of this in the exercise packet. But put a lot of time into this planning poker because again, if you do a good estimation session, it's going to keep you from having a lot of problems once you get into the sprint. So if you can't figure out if everyone can agree on what it takes to deliver, how are you going to deliver this user story? It's not going to get clear once you enter the sprint. And so you want to make sure that everybody's much very clear about how they're going to deliver this user story before they start working in the next sprint. So once you go through your planning poker meeting, you're going to have a bunch of user stories written on the tops of the card. Now, this will help the product owner prioritize. So if there's something that's a high value, that's relatively small effort, they might move it to the top of the backlog or if there's something that's relatively low value. But the development team says this is a lot of effort and they might move it down. So it kind of helps the product owner figure out what they should request goes into the sprint backlog. And so they might just prioritize things based on the level of effort so that the team comes up with in these planning sessions. Now is a development for the development team. It might help them kind of guide through their sprint and it might help them, as I said, get rid of this groupthink. So that product remember, the development team is thinking about the product in terms of tasks and chunks. And so every time the development team has a planning poker session, they understand the product a little bit better. They understand how to communicate and create a shared vision of the product a little bit more, because remember, they're going to have some discussion and you'd be surprised how many times you have a planning session and you think that there's a lot of consensus about certain major parts of the product. And only when they start throwing down cards and start talking about how they're going to deliver the product, you realize that there's actually a lot of disagreement that some people have a different idea in their head about what the product will look like. So these planning poker sessions really help hash that out for the development team. Now, there is a trend to completely skip estimating because of some misuse from management. So a lot of times you'll have managers come in and try to bump up the estimates or something like that, or they'll try the team will try to bump up the estimates. So it looks like they're getting more work done or you'll have the product owner that will create a lot of user stories so that the team is creating lots of estimates and it starts to get to be something that you really can't do within 10 percent of a sprint. And so the product owner is creating a lot of user stories and the team is just spending too much time estimating. And there's also the danger that if all of this work is estimated out, that it might encourage sort of the product owner or someone else to do something that's closer to planning. You might say, OK, well, since we've estimated out all this work, why don't we just sort of deliver all of this stuff in one sprint and then it starts to look like phase delivery? Now, I think that getting rid of this estimates the challenge with that is that you lose a lot of this collaboration and communication you get from these planning Coaker meetings. Like I said, I think of the estimate as sort of a byproduct of the discussion. It's almost inconsequential. The number that you put on the card is especially at the beginning. It's only moderately helpful figuring out what you're going to put in each sprint. Over time, the team will get so much better at estimating that you could probably figure out what to put in the sprint without even putting numbers in the card. But it's the discussion that's important. It's the getting rid of the group think it's making sure that the quieter voices have a time to sort of discuss the product with some of the louder voices in the team. And it's a scrum master. You want to make sure that some of the quieter people really are able to communicate where they think, what they think the product is and what they think how long they think this user's story will take. And keep in mind that a lot of times these quieter voices, even though they might sound like they're less authoritative, a lot of times they're right now times of people who sound authoritative, who really sound like they know exactly what they're talking about and say with a high degree of confidence. A lot of times they're more likely to be wrong. So even though there's a little bit of a trend to kind of get rid of estimates, I still think that there's a lot of value just for like the entire group think for the group discussion, there's a lot of value in going through something like planning poker. Another thing to keep in mind is that if your team is getting a little too hung up on the numbers, you know, they have trouble. It's very common for teams to have trouble sort of thinking of the planning poker numbers. Not as time. Sometimes you can go out and like what I once bought at a toy store, a bunch of animal cards which just had little animals on them for like there was an aunt and a cat and a dog and a horse. And you can get the team to estimate using animals until they can sort of get the swing of this idea that they're not using numbers to figure out days and hours, but instead that they're thinking about things in relative effort, his relative effort. So if you're the scrum master for the team, you might want to pick up a deck of animal cards. If your team is having a lot of trouble not thinking of user story points as time. If they're having trouble thinking of them as a metric for relative estimating, remember that you're doing you're creating something like a two if you go into the exercise packet and then you're creating other user stories based on how many twos fit within that user story. So you'll see a little bit more in the exercise packet. But if you're a scrum master for the team, you might want to go out and get yourself a set of animal cards just in case your team is having trouble with this technique.