Agile teams are creative, innovative, and above all have fun while they work—the perfect recipe for enabling project success! By doing away with rigid processes, dull documentation and inefficient practices, Agile teams are nimble and quick to react to changing project conditions.
One of the fun ways in which they work is by using Planning Poker to plan estimates and create schedules. In this blog, you will learn all about Planning Poker; what it is, how it works and what are its benefits and pitfalls.
‘Planning Poker® is the secure, fun way for agile teams to guide sprint planning and build accurate consensus estimates.’ - planningpoker.com
This game-based estimation technique injects playfulness into what could otherwise prove to be a dreary, monotonous activity. Easily integrated into Jira and other Agile software tools, Planning Poker takes into account the opinion of every member on the Agile team and smoothens the process of creating accurate estimates, laying the foundation for planning and executing a sprint planning session.
So, let’s get into what is Planning Poker in Agile and how it works!
One of the most important meetings for an Agile team is the sprint planning meeting. The team members will sit together to deliberate on the amount of work that they believe is possible to complete during the upcoming sprint. This falls in line with the spirit of Agile, which allows for greater accountability and ownership of tasks. When the members themselves decide on the quantum of work that is possible, they are far more likely to get things done!
The Planning Poker game uses numbered cards to help estimate the effort or size of tasks in Agile development. It pools in the estimates of individual team members to arrive at a shared consensus, which results in a fairly accurate estimate of the project duration.
Here’s how to play:
Each member of the team is given a set of playing cards that are numbered in sequence. Mike Cohn, founder of Mountain Goat Software, put forward the sequence list that is widely in use today: 0, 1, 2, 5, 8, 13, 20, 40, and 100.
The Product Owner reads out the Agile user story or may describe the feature to the estimators. He or she lays out the functionality that is required to be developed.
The estimators hold a conversation with each other, discussing the user story and fleshing out the details. As they brainstorm, they might need to ask questions to elicit information. The Moderator, who could be the Product Owner, will record the proceeds of the discussion for further elaboration.
Once the discussion is completed and all doubts are clarified, each estimator will select one Poker Card and place it, face down on the table. All members will then reveal their cards at the same time. In the event that all the values match, that is taken as the value of the estimate.
In most cases, the values will not match as each team member will have their own reasons for selecting an estimate. Any outliers are discussed, and the estimators with the highest and lowest values must share their reasoning behind these choices. There is another round of estimation held after this discussion, where every estimator re-selects a card. This process goes on till the team members arrive at a consensus.
This estimating technique has its origins in the year 1970 when Barry Boehm proposed ‘Wideband Delphi,’ an adaptation of the Delphi method which was already in use at the Rand Corporation as an estimating tool. It was called ‘Wideband’ as it built upon the earlier method to enforce greater interaction and open up more communication between the estimators. This was a forerunner of Planning Poker.
Planning Poker was first defined in 2002, when software entrepreneur, James Grenning was looking for a simpler and more accurate way to cut out the confusion when creating estimates. Later on, in the year 2005, Mountain Goat Software’s Mike Cohn wrote a book ‘Agile Estimating and Planning’, where the technique was explicitly laid out in its current form, and the term was trademarked.
The rationale behind Planning Poker is that estimators are not influenced by the other participants, and apply their own thinking to creating their own estimates. There are a number of benefits that arise from using this technique, the most important being the following:
This technique is not without its share of pitfalls. Here are some of them:
Agile is, by its very nature, fluid and dynamic and each team must figure out what works best for their project. While Planning Poker is a great method of estimation, some teams may find that they can create better estimates using other methods like Affinity mapping or T shirt sizing. If you are looking to create better collaboration between team members and nurture mutual understanding, Planning Poker is a good method to try. And as always, with practice and over time, you will find that your team’s estimation techniques will improve!