Poker Method In Agile
- Poker Method In Agile Scrum
- Poker Method In Agile Methodologies
- Poker Method In Agile Project Management
We are glad that you have started 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. But there are pitfalls and don’t worry as they can be handled with the help of proper planning and estimation techniques. Yes, that is where we talk about the scrum poker. Does it look like a new word? Then call it planning poker that is how it is popularly known to the people in the agile world. We also call it 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.
But in 2007, we began printing Planning Poker Cards, which we sold at cost, distributed at various agile events, and that I use in some in-person courses. To keep printing costs down, I had to choose between these two sequences. At the time, I just slightly favored the modified Fibonacci sequence. And so I made the call to go with that. Planning Poker is an agile estimating technique which has become very popular in the last few years. Planning Poker is extremely simple to play while also being accurate enough to use for agile planning.
What is Planning Poker in Agile?
In simple words, it 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.
Best time to employ Planning Poker?
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.
Poker planning and distributed team
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.
Agile Estimation – Relative Vs Absolute
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 |
Point vs Hour Value in Estimation
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 |
What is planning poker estimation - Tips for using planning estimate effectively?
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.
When to use?
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.
Who should participate in planning poker in scrum?
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.
Planning Poker – Does it work? Yes, follow these tips
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.
Order Planning Poker cards?
Before you order for planning poker cards, know them.
Figure 1: Planning poker cards
• These are the deck of cards and each deck contains 4 sets of cards namely the 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100…. You guessed it correct, it is Fibonacci series with slight modifications.
• Zero cards confirm that the story is completed; it may also be not a worthy one to be discussed. For either situation, it is marked as zero.
• The card that is a ? will confirm that the estimator is clueless about the task.
• There is a coffee cup that indicates a need for a break.
Now, know that these scrum poker cards are available online in Amazon for sale. The brands include Bee, Bicycle, or World Poker Tour cards.
How does planning poker work – Steps in detail
This is an agile planning poker scrum activity. Every estimator will have a deck of cards and begin with the exercise.
Figure 2: Steps involved in a planning poker game
The participants are the moderators in the scrum poker. The session initiator in the agile poker is the moderator who can cancel any item estimated and choose per their wish. The final result can be edited by this person and also allow voting to restart the item.
1. First, the moderator will read the details. This is usually the product owner and he does it for every user story/theme which needs estimation.
2. Then the discussion starts and the PO will address the answers for the estimator’s questions. The goal to be kept in mind is not to arrive at an estimate but make a value estimate in a cost-effective manner.
3. Now the estimators will individually select the card based on the discussion to represent their estimation. After the selection is completed by all individuals, everyone will simultaneously turn the card to reveal their estimate to all participants. Don’t expect them to be the same and they will differ.
4. The extremely different estimates require explanation by the estimators. If required a re-estimation is done. This process is repeated until the team comes in consent with one estimate to be implemented for a particular user story.
Conclusion
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 – 80502 05233
There’s a lot of chatter about whether or not agile estimation techniques are reliable and realistic. However, they have undoubtedly been popular in the past, and are still very much in the scene.
Traditional vs. Agile Estimation
Poker Method In Agile Scrum
Let’s begin with what agile estimation is. These are simply estimates for any particular project in hand. Whilst traditional estimations make use of time, some agile estimations prefer to use story points.
Instead of assigning a time estimation for a project, story points are assigned as measures of relative effort. This allows the team to consider other work they know they have to complete simultaneously in their estimations, and the skills of the team relative to each task. Story points don’t measure time-efficiency – they measure problem-solving abilities.
Traditional estimation is a different ballgame and uses methods that follow ‘bottom-up’ estimating. This means that teams inspect each element of a project, estimate the hours or days required to complete, and then use this information to develop a schedule for the project.
Agile estimation techniques use a ‘top-down’ process. This encourages teams to propose a gross-level estimation for how long the project should take, or how much effort it will take. This is then broken up and applied to different elements of the project. Teams drill farther into those elements, uncovering more and more details until the task level – which is looked at through a just-in-time lens.
In this article, we’re going to run through five of the most used agile estimation techniques. We’ll also briefly look at any pros and cons that are worth mentioning.
Agile Estimation Techniques
1. Planning Poker
Planning poker is an agile estimation technique that makes use of story points to estimate the difficulty of the task at hand. Based on the Fibonacci sequence, the story point values that can be assigned are 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. Each of these represent a different level of complexity for the overall project.
Planning poker starts with the team members involved in the estimation process sitting together for the session. Each member holds cards with the story point values described above. The next step is for either a leader figure or the customer to read out the ‘user story’ (which is essentially the project), and describe all the requirements and features.
The stakeholder reading out the story will engage in discussion with the team members who are estimating, who will, in turn, discuss with one another. In this phase, they can ask the customer or owner questions for clarification and express any reservations they have.
When the discussions are finished, all of the estimators will select a card with the story point they believe needs assigning to the project. If the story point estimations match up – then that will be the final estimate. However, if they do not match up, then estimators who gave the lowest and highest points can voice their reasoning, and more discussion will ensue until there is a consensus.
This technique is not good for large teams, or when there are a large number of items that need estimating. If you only have a selected number of items (between 2 and 10) and a small band of teammates, then this is a good technique to use. It’s also one of the most popular estimation techniques.
2. T-Shirt Sizes
If you think about T-shirts, there are multiple sizes to choose from. More specifically – there is extra-small (XS), small (S), medium (M), large (L) and extra-large (XL). This technique uses these sizes as story points for the size of the project, and it is a useful way of thinking when estimation needs to occur.
This is a useful method for being time-efficient. It can give a quick and rough estimate for how much work is expected for a project. The sizes can be converted into numbers at a later stage – when the team assigns a relative size to the project on hand. This is decided through discussion and collaborative efforts to understand everything that needs to be done.
If estimators propose sizes that do not match up, then the team voices their opinions on the topic and must eventually reach a consensus.
This is a pretty informal method that is great to use for a large number of items. Unfortunately, story points can be tricky. What might seem one size to one person could be perceived as another by someone else. Whilst this can create some confusion, this method is based on open discussion, and everyone should get the chance to have their say.
3. Dot Voting
Sometimes it can be hard to order the items in the product backlog. This ranking method enables you to sort these items from highest to lowest priority, so you know where to focus your efforts. To do this, you need to select the most important user stories.
Start by posting all of the stories you need to deal with on a wall somewhere (or a board, if you’re feeling more conventional). The posts should contain the story description and should look unique so that they are easily distinguishable to voters.
Team members involved in the process are all given 4 to 5 dots to dole out. The use of stickers or markers can be effective for this process. Team members place these dots on the user stories that they would prefer to start working on and distribute them throughout the options.
A leader then orders the stories from most preferred to least preferred (most preferred would be the story with the most marks or dots on it). If there is any stakeholder who is not happy with the order, then the items are divided into three groups – high, middle and low priority. Team members vote on the high priority stories again until they reach a consensus.
This is not necessarily an agile estimation technique – it’s more of a decision-making tool. But if you have a small number of items – it can be very efficient. It’s also really simple and is a good visualization tool.
4. The Bucket System
This method relies on placing different values on a table. We call the placements ‘buckets’, but you can just use cards. The values are generally 0,1,2,3,4,5,8,13,20,30,50,100 and 200 – although these can be expanded if necessary.
Estimators need to take stories and collectively choose which buckets each item falls into. To do this, place cards with the items written on them into the buckets. Before placing each item, it is important to have discussed the features and requirements of each with the estimator team. All items must be assigned and placed in the buckets upon consensus.
The buckets can also be changed and rearranged if the group feels it necessary to reassign an item. There is a ‘divide and conquer’ phase after assigning important items. Estimators get the remaining items and can place them in buckets that they believe the items should sit in – without consensus.
If a participant does not understand a story, it can be transferred to someone who does. If someone does not agree with a certain item placed in a specific bucket, further discussions takes place to agree on where to place the item and why. This ‘sanity check’ is critical to this process.
This method is more time-efficient and reasonable than Planning Poker. It is a great agile estimation technique to use if you have a large number of items and a big team.
5. Affinity Mapping
Firstly, silent relative sizing needs to occur. To prepare for this, place two cards on opposite sides of a wall. One should say ‘small’ and the other should say ‘large’. The leader (or product owner) needs to provide each estimator with a subset of items and should remain present during the process to clarify anything. Estimators then place the items on the wall, relative to each item’s perceived size. The size depends on the effort expected to complete them. There is no discussion at this point.
Team members can then change the location of wall items, discussing as they go. Once teams finish editing the wall, they can finalize product backlog items in their positions. However, just before this, the product owner may step in if they spot a discrepancy between what the team members have estimated in comparison to their ideas.
Using a project backlog management tool can help ensure that the finalized estimations are saved. This is a good technique to use for a smaller team. Also, if you have a large number of backlog items, this is a bad choice. You might find it to be time-consuming with too many items.
Join 60,000+ Subscribers
Poker Method In Agile Methodologies
For latest blogs, industry updates and exclusive tips.
Poker Method In Agile Project Management
*Your email is safe with us, we also hate spam