Planning Poker

One of the coolest things on teams as we do team level estimates is this idea that estimation is a whole team activity. It's not just one person's opinion, like the lead developer sort of gets to decide. No, everybody gets a voice, everybody's voice gets to be heard. And the way we do that is with an activity called Planning Poker. Now, we're not really playing poker, we're not really doing that, but we call it Planning Poker because it is done with a set of cards, typically a deck of cards. And each person has their hand and in it a are the numbers that were going to be used to represent story points. So Planning Poker is this idea of getting consensus from the team on user story estimates. And remember, these estimates, they need to cover every phase of what we're working on, including design, build, test, and potentially deploy. In other words, there's not separate stories for tests, separate stories for development. And so testers estimate testing stories and developers estimate development stories. It's not that it's a team based activity. For this estimation, these estimates need to also include all of the volume, complexity and risk or uncertainty inherent in the thing where we're estimating. And remember, this is sort of the beauty of using story points. The first thing we do is we find a baseline, our baseline story. What's the smallest, most well known, well understood piece of work in the backlog that we're going to commit to in this sprint? And we call that a one. That's our baseline of our one. That baseline is very much like the espresso cup in our earlier example of how we do relative estimation. Every other story is going to be relative to that. Okay, so Planning Poker kind of then begins like this. The product owner, she'll, she'll read the highest priority story from the backlog, answer any questions that the team may have about that, and each team member then from their card selects the estimate that they think represents that story. They don't show that until everybody's ready. Scrum Master is facilitating this event. And the Scrum Master will say, okay, everybody's ready, let's go ahead and vote. 1, 2, 3. And everybody lays their card down. Or if you're doing it electronically, everybody selects their number. Or if you're doing it like in a chat window, people type in the number and send at the same time. We do it all at the same time because we want everyone's opinion to count. You don't want to end up in a situation where one person says, this is easy, and then I see theirs and go Well, I don't want to seem stupid, so I'm going to make it a little lower number. That's called anchoring. I think this is an easy job. We want to avoid that so we all show our cards at the same time. So if there's consensus, we move on to the next story. That's it. Like, that's it. It was a three point story or a five point story. Whatever it is, we're done. If there's not consensus, then the scrum master will ask the outliers to share. Why do they think that? Why do you think it's a lower number? Why do you think it's a higher number? We'll hear from both sides and then we'll revote. 1, 2, 3. Show your cards and we'll see if we can get closer to a number. Maybe the high number comes down, maybe the low number comes up. Maybe new information was shared that the person with the low number realized, oh, this is more complex, or there is more unknown, and so their number goes up. Maybe the person who has the higher number hears, no, we actually have this. We can reuse this. This is easy. And their number comes down. Whatever the case is, I've seen it happen, you know, hundreds of times where just that shared understanding from the act of, you know, planning poker helps us get more clarity. So we'll vote again. Boom, we've got consensus. We move on to the next story. We walk through all the stories until we're out of capacity for the sprint. The capacity, the amount of story points we think we can complete, and when we're out, that's it for planning poker. Remember, the stories are written in a way that they describe all phases of design, build, test, and potentially deploy. So it's a whole team activity. In other words, the lead developer doesn't get to say, okay, well, it's a five because I'm going to do all the coding. Well, hold on. We've also got to test it and we've got to do documentation. And maybe there's release notes and maybe there's peer review. So the whole team has a voice in this. Be careful not to, you know, allow one person to sort of say, well, you know, they're most suited for this story, so they get to estimate it, and then the next story is, you know, better for me, so I'll get to estimate it. Well, watch out for that. It's a common. It's a common anti pattern on teams where the person who estimates it is the person who pulls a story. It's a team based activity. So make sure you allow the team to have their voices be heard. So, planning poker, yet another activity, another tool for us to use to get to shared understanding.