Some time ago, while talking with our CTO, Simon, he told me about a way of doing task estimations that I had never hear about before, it was called Poker Planning, he said to me that the cards could be found online and that it is a fun and effective way of doing estimations. So I decided to try it myself with one of our teams.

The next day I had the sprint planning session for one of our clients, it is a typical two weeks agile sprint, so earlier in the morning I did a quick online search and download a printable deck of cards and printed 6 copies.

Then the team gathered in the conference room, we are 6 people on that team, so it was the perfect amount of people for the experiment.

In the past, I would do the planning and the estimations of each task myself. I believed that because I knew all parts of the project, I was the best suited to estimate everything, but after that day, I realize I was wrong.

The way Poker Planning works is each team member has one deck, where each card has one number, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100,∞ ?, then the Scrum Master go through each task of the sprint and explains it, then everyone discusses the task and ask questions until the task and its objectives are clear, each one selects a card and places it faced down in the table, and once all the cards are on the table, the cards are shown, here is where everything can happen. Sometimes everyone will pick similar cards, so if all the team have a similar idea we set that card as the estimated time, but more often than not there will be a notorious high card and a low card, what we do in that case is we ask the person with the lowest card, why do you think it will take that little time, and we ask the person with the highest card, why do you think it will take that much, there is the beauty of this methodology because maybe that person with the lowest card, found a way to solve the problem in a super easy and efficient way, or maybe that person with the highest card noticed a challenge that no one else saw. In the old days, without that input, I could have estimated the task without realizing those things. The last added value of this practice is that once the sprint starts, the number of questions about what a task is about is highly reduced, and everything runs smoother and faster.

I want to end this post with a saying I heard in one of the podcasts I listen to, “If you are the smartest person in the room… you are in the wrong room”.