 | Request for Demo Session |
| Watch Our Intro Video |
Last updated on November 21, 2019
20 mins
4074
Planning poker is a game used to estimate the efforts and hence find the product backlogs. It is consensus-based and used to estimate the user story size in a scrum. A decade before in 2002 James Grenning named this game as estimation poker after some time officially Mike Cohn made this technique popular through his Agile book. He also created planningpoker.com allowing people to play for free and make the best use of the tool.
Welcome to working on agile projects. You are performing great in stand up meetings and planning for sprints. Your retrospectives are working just fine. In short, you are delivering your product to the end-user as expected. However, these are wishes all of us have when we work on projects and can be accomplished with proper planning and estimation techniques using scrum poker or planning poker or pointing poker.
In this blog, we would want to provide you with all the details about Agile planning poker and the right way to use this estimation tool to execute your sprints per the plan devised.
Before starting get an idea about absolute and relative estimation as well as point vs man-hour estimation that will make you understand the need for planning poker agile. Basically, we engage in planning poker as it is a size estimation technique.
Do we have to use this technique after writing the first product backlog? According to us, the answer is no. Can you guess why? It is because, we are well aware that poker planning is a size estimation technique and if it is done just after writing the first product backlog, then there will be additions of user stories which will lead to estimates again. Therefore we suggest using planning poker at the end of every iteration. This will save time and re-estimation efforts as well. It is better to do this in few days prior to the completion of iteration and then follow it up with a daily standup. This will allow the entire team to participate.
Planning poker online tool was offered to the world by Mike Cohn. This can be used by distributed teams and thus it is greatly promoted by the agile coach and trainers to all people in the agile community.
Scrum poker online tool fosters teamwork as it engages all the team members from the distributed team. It makes an estimate in consensus and not just one person drives the estimate. The issues are highlighted well in advance for every story point by allowing the team to discuss constructively. A distributed team is basically a team that is located in a different location. So it is now easy for all teams to connect with this one tool.
This is an agile planning poker scrum activity. Every estimator will have a deck of cards and begin with the exercise.
The very word estimation in simple English is guessing. With experience and knowledge senior people in the team estimate the time required to complete any particular work. In case, if you are new to the work, then what experience you will have? How can you guess the time or plan a work? Then you need some references and they can be obtained from the previous works. For this, you don’t need experience. We can always quickly relate and come to a conclusion.
Therefore understand relative vs absolute like this. Relative is to compare with and absolute is beyond comparison defined theoretically which is the actual. You cannot be rigid and define a time frame as absolute cannot be possible always. Relative can happen by comparing several past work and estimate on the time and efforts.
I call relative as arbitrary and absolute as real. Not everything is possible in reality and thus absolute may or may not happen. On the other hand, relatives can always be fine-tuned and attain closer to accuracy.
| S.No | Relative Estimation | Absolute Estimation |
| 1 | Comparison is done and there is no room for isolated estimation. | The means estimation is done and there is only item isolation but no comparison |
| 2 | Relative value | Absolute value |
| 3 | Value is decided upon comparing with another value | It is decided one time and there is no comparison |
| 4 | No tools to measure but an arbitrary value | Measured using tools and accurate |
| 5 | May or may not be accurate | Accurate |
Is it a good estimate with hour value or story points? Let us understand the difference between both to conclude the best technique.
| Story points | Hours Value |
| Time taken to complete each user story is measured | Time taken by the individual and team in completing an action is the hour's value. |
| Experience or skill of the estimator is not correlated | Based on the skills and experience only the time varies |
| Velocity is tracked | Velocity is not tracked |
| No re-estimation is required | Re-estimation is needed when man-hour is estimated as it tends to change based on the time and person who completes a task |
From the above table, it is understood that in man-hour estimation not all tasks are easy to estimate. If the developer who estimates and the developer who completes are two different people, then the estimate may not be correct. On the other hand, irrespective of who estimates the task, keep user story as the measurement will provide accurate results. It is because completion of user story is the key and not the person. Thus the skill level and experience of the individual do not matter.
It is an estimation technique and a discrete scaling method. It is played using the cards that are represented as modified Fibonacci series.
Lets us explain with an example. When a task requires 2 weeks for completion, then the estimator will choose either a card with 13 or 20. Each estimator will open their cards and come to consent on one card either 13 or 20 and work towards achieving the goal.
We suggest you split the user stories for more effective estimation. Use the “?” card and gather information before choosing the right card.
Wall map the stories by taking the smallest story as a reference which can be coded and tested in one day. Arrange the stories from left to right and split the bigger story into small to estimate them effectively. Choose only relevant cards and ignore estimates that are high and reveal false accuracy.
Use this game for effective estimation and start at the zero sprints which are the release estimation planning. Here you can construct the estimates for each feature request which is called a task in simple words. This will size the project. Also, use it during the estimation of the new story to recognize the iteration process.
The product owner or the analyst who plays the role of a moderator is the key player in the planning poker estimation technique.
Next comes the estimators who participate to select the cards and check them to come to a final consent. These estimators include the developers, database engineers, testing engineers, and user interface designers. Basically, this tells you that all involved in the agile project needs to be an active participant to plan using the poker cards.
We believe that it is the best estimating technique and accurate too. Planning poker estimation technique helps to bring the collective opinion of different experts from all cross-functional team. Therefore, the estimate is done from a different perspective and thus looks perfect.
1. Do a detailed review of the software literature is done before estimation.
2. It works effectively is estimated by the competent team.
3. Engage in a lively discussion with the team and the estimator should involve their peers and confirm their estimates. This will enhance the accuracy of the items with uncertainty.
4. All missing information is collected to justify the estimates
5. Average every single estimate and then planning to estimate for the best results.
Before you order for planning poker cards, know them.
In summary, planning poker estimation is the best method used to not only estimate the ideal time for task completion but also allows the team to correlate the user story properly. But, remember to bring the team to consent for each estimate. Have a healthy discussion but don’t dilute the details. Avoid using a coffee cup card often to prevent monotony in the process.
Finally, we would like to reiterate that this is an effective technique used to estimate the time taken to complete each user story. It is an influential technique too.
To understand more about planning and estimation attend StarAgile Certified Scrum Master training, for upcoming schedules please call us at +91 – 95133 93880
04 Jan 2024
20 mins| Name | Date | Place | - |
|---|---|---|---|
| Certified Scrum Master | 01 May 2024, weekend | United States | View Details |
| Certified Scrum Master | 01 May 2024, weekend | New York | View Details |
| Certified Scrum Master | 01 May 2024, weekend | Washington | View Details |
| Certified Scrum Master | 01 May 2024, weekend | Chicago | View Details |
professionals trained
countries
sucess rate
>4.5 ratings in Google
