When planning a product, Project Managers, Software Developers and Product Managers face a common hindrance. The hindrance is nothing but the estimation process. Here, they will have to estimate or presume the level of effort required for finishing a development task. Estimation is a double-edged sword, in reality. However, it helps teams to break their long-term projects into short-term and manageable tasks. Nevertheless, a bitter reality here is that a wrong move can collapse long-term project planning.
In most cases, the management in any organization pressurizes the teams engaged in software, product or project development to improve how accurately they predict things. However, this is something easy to say but not easy to do. The teams face trouble when they have to select the right technique to estimate. They also face trouble with picking the right time to do it. Thanks to Planning Poker. The purpose of this technique is to help product, process, project and software development teams that follow Agile methodology by simplifying the estimation process.
Origin of the Term Planning Poker:
Before the launch of Planning Poker by James Greening in 2002, organizations followed the estimation approach named Wideband Delphi. James Greening found that this technique takes a lot of time and it has other restrictions as well. Initially, this technique aimed at solving the issue of individuals in a team talking too much to ensure that their ideas alone are implemented. This term gained popularity in the Agile world when the Co-Founder of Scrum and Agile Alliance Mike Cohn explained its effectiveness in his book Agile Estimating and Planning.
Planning Poker is widely accepted as a consensus-based estimation technique. Agile teams from across the world use this technique for estimating the Product Backlogs. This estimation technique can be used with ideal days, story points and other estimating units.
Planning Poker – The Meaning:
Let’s understand what Planning Poker is. Planning Poker is planning and estimating technique in Agile that is based on consensus. To instigate a Planning Poker session, the customer or Product Owner goes through an Agile User Story or explains a feature to the people estimating.
Every individual engaged in estimation called an estimator will hold a deck of Planning Poker cards. The value of these cards will be like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The value of cards denotes the number of ideal days, story points or similar values using which the estimators estimate.
The group of people engaged in the estimation will discuss the feature. In this process, they put forth any queries that they have to the Product Owner. Once the feature is thoroughly discussed to the satisfaction of each estimator, he/she will individually select a card for denoting the personal estimate. Finally, all estimators together reveal their cards at once.
In case, all those involved in the estimation select the same value, it turns out to be the estimate. If they select different values, they discuss, where those estimated the highest and the lowest value share the reasons for the estimation. After discussion, all estimators again get a chance to select an estimate card. Again, all of them, together reveal the value of their cards simultaneously.
The group of estimators repeats the process again and again until they reach a consensus. Otherwise, they continue to follow the process until they decide on deferring the Agile Estimating and Planning of a particular item.
Working of Planning Poker in Agile:
Planning Poker estimation in Agile associates stakeholders from across different departments in the organization. They meet so that they can reach a consensus on the judged effort required for different items in the backlog. When it comes to Agile software organizations, the stakeholders can encompass Product Managers, QA testers, UX Designers, Developers and a Product Owner to name a few. The process is explained here:
Step 1 - Handing Out of Cards
Each estimator participating in the poker will get an identical deck of cards. Some organizations also use chips in the place of cards. Even though the deck will be identical, the numbers in each card or chip will be different. However, there will be a common format in sequencing like doubling each number as follows: 1, 2, 4, 8, 16, 32 and 64. However, Mike Cohn, who made Planning Poker popular, as mentioned earlier, recommends the following sequence: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100.
However, an important point should be remembered here. The decks are limited and carry a considerable number-jumps. The reason is that the aim is to ensure that all those taking part should reach the consensus number for every story. In turn, every participant will get too many options say every integer from 1 to 50 would make the procedure inefficient.
Step 2 - Story Reading
When this step is reached, the Product Owner or the Product Manager will read every story out loud to all the Developers.
Step 3 - Discussion
Now, everyone is aware of the story. So, the group of Developers are ready to talk about the story. Here, every Developer will get a chance to explain how he/she visualizes handling the work. They will share their idea on the number of people to be involved in the work and the skills required. Further, they will talk about the obstacles that can come in the way, thereby slowing the process. At this stage, the group will also use this time for asking any queries they have on the story.
Step 4 - Estimating and Sharing
After everyone has expressed their thoughts and got their questions answered, each Developers will get a chance to select a card from the deck without showing it to others. They will use the card to denote the estimate of story points. When all Developers are ready, they will show off their cards simultaneously. The higher the card of Developers, the more hard they estimate the story will be to complete.
Step 5 - Work Towards Consensus
As mentioned earlier, if all those taking part show the same number on their respective cards, then that number will turn out to be the consensus. Now, all Developers can together go towards the next story.
On the other hand, if the cards differ, the Developers will engage in an ongoing discussion on the story. Particularly, those with the lowest and the highest number on their cards will explain the reason for choosing the numbers they showed. Their goal will be to convince the other Developers of their stand.
When this discussion and convincing by Developers with the highest or lowest number is over, the Developers will again review their cards. Now, they get the chance to either choose their new card or keep their previously chosen card. Again, they all will show their respective cards simultaneously.
In case, the difference still prevails, the discussion will continue again until all of them reveal the same number.
Agile Estimation – Absolute Vs. Relative:
An estimate is nothing more than a well-thought guess. Project Managers use their experience and knowledge to make the right guess of the time a task may take. Therefore, rather than seeing every new work item individually, things would become easier when comparing the present work in hand with the previously completed similar work to estimate the time. For humans, it is simple to relate to similar items rather than freshly making guesswork. For instance, you can compare the work in hand with a similar size of work completed last month. The good thing about comparing before making any guesswork is that it will considerably reduce the time required for estimation. Above all, it will increase the accuracy of the present estimation to a great extent. Natural human tendency is to put any new thing that needs estimation about things that we already know.
Why is Planning Poker Used in Agile?
Knowing what is Planning Poker in Agile is important. Let’s discuss why is it used in Agile. With the help of Poker Planning, it will be possible for software teams to pinpoint accurate and realistic timeframes. Also, this technique will help software teams strategically plan the workflow of the team. They can build a consensus among the cross-functional team members.
As most Project and Process Managers know, the best way to handle a huge task is to split it into different sub-tasks. When they do this, they can focus on a single small task at a time. Thereafter, they can repeat the same process with every task until they complete every task at hand. By following this approach, it will be easier to complete a big task. Team members using Planning Poker break a project into such small tasks so that it will become simpler to estimate the time required to complete every part. In short, Agile teams use Planning Poker to accurately estimate the time they need for completing an entire story.
References
- https://www.atlassian.com/blog/platform/a-brief-overview-of-planning-poker
- https://www.mountaingoatsoftware.com/agile/planning-poker
- https://www.productplan.com/glossary/planning-poker/
