Scrum Planning Poker Story Points
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.
What is Planning Poker in Agile?
If you’ve estimated with Planning Poker, you may very well have used cards with either the Fibonacci sequence, or a modified Fibonacci sequence. The traditional Fibonacci sequence is 1, 2, 3, 5, 8, 13, 21 and so on, with each number the sum of the preceding numbers. Planning Poker® is a consensus-based estimating technique. Agile teams around the world use Planning Poker to estimate their product backlogs. Planning Poker can be used with story points, ideal days, or any other estimating unit. While estimating story points, we assign a point value to each story. Relative values are more important than the raw values. A story that is assigned 2 story points should be twice as much as a story that is assigned 1 story point. It should also be two-thirds of a story that is estimated 3 story points. Story Points Story points measure the bigness or magnitude of a PBI from the development team's perspective. Points combine factors like complexity and physical size into one relative size measure, with the goal of being able to compare stories and say things like, “If this feature is a 2, the one over there is about a 5.”.
In the next step I’ll show you how to use Planning Poker (aka Scrum poker) to assign story points to each user story from the product backlog. Negotiate estimates with Planning Poker Planning Poker is one of the gross-level estimation techniques, using a modified version of Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100.
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
Scrum Planning Poker Guidelines
What is it?
Story Point is an arbitrary unit of measurement to measure amount of work in a Sprint. It’s a pretty abstract concept and can be very hard for people to comprehend. Is it same as hours? No. Similar then? May be.
What is it then? It is something that you can relate to Sprint to Sprint. If your team accomplished x story points in one Sprint, given the same amount of resources and time, team should be able to accomplish more or less the same next Sprints. Once you do it a couple of times, you should be able to get your team Velocity.
Other Industries
If you take a look into Construction or Manufacturing industry, the measurements are pretty accurate and pretty standard. Everybody know what an 1 mm drill is (if there such a thing :)). You go to Home Depot, every part has measurable characteristics: height, weight, width, color, etc. Why shouldn’t your Scrum Team be: Resources, Duration, Sprint Goal, Story Points, and Velocity.
Story Points are usually based a mathematical number series called as Fibonacci Sequence.
Fibonacci Sequence
Wikipedia has a good read on what they are. It essentially are numbers as 1, 2, 3, 5, 8, 13, 20. Note number on right is addition of last two numbers on left 8 = 3 + 5, 13 = 5 + 8.
Each PBI (Product Backlog Item) is supposed to have Story Points associated. This is done by a voting process (sounds funny, but it’s important). Only Pigs (Team members responsible for building the feature Dev, QA, UI/UX, Doc) are allowed to vote.
Voting is also referred as Planning Poker. Why Poker: Because Pigs don’t know what other Pigs have selected unless “Show” is called by.
Voting (Planning Poker)
During the Sprint Planning meet, the Product Owner spends about a minute explaining the PBI that needs to be have Story Points assigned. In the next minute or two Pigs ask questions to get clarity. Note: This is not a feature discussion meeting. Pigs and Product Owner should have a good idea about the PBIs prior to the meet. What you are trying to do is assign Story Points, so you can predict future Velocity.
Each Pig is handed over a deck of cards. There are seven cards in the deck with each containing one of these numbers: 1, 2, 3, 5, 8, 13 and 20. When asked to vote, each Pig should individually select a card and put it on the table face down. When asked to show, everyone should show their cards together. People on the phone are asked to tell first so they don’t get influenced by the outcome of physical cards.
Story Point Guidelines
This is the most important aspect of allocating Story Points. Every team member must know how to pick one of those Fibonacci numbers. It might be a bit easier if you think from an elimination point of view.
20 – Too big for the Sprint. You need to break the PBI into smaller PBIs. Ideally nobody should have selected this number in voting. If they have then be prepared to talk about it.
Scrum Planning Poker Story Points Redemption
13 – Something that will take full Sprint to accomplish. You should also be very clear what exactly does done mean for the PBI. Is it just Code Complete, or does it include QA and Documentation. Ideally PBIs should be created in such a way that the Product becomes releasable at the end of Sprint. However, this may not be very practical. I’ll table that discussions for a future Blog. For now keep in mind that you need to assign 13 if you think this will be going on through out during the Sprint by 1 person. In a 15 day Sprint: 8 days for Dev, 4 days for QA, 1 day for Doc.
8 – Something that takes half the Sprint.
5 – 5 days (in a 3 week Sprint)
Scrum Planning Poker App
3 – 3 days (in a 3 week Sprint)
2 – 2 days
1 – 1 day or less
less than 0 – Combine such PBIs into 1 or more
Again, your definition may differ depending on duration of the Sprint. The above is based on a 3 week Sprint. With lots of experimentation we’ve concluded that 3 weeks Sprint is the best. Perhaps another blog to talk about that.
What you really need is a framework to which your team members can associate these numbers to. A 5 may be 3 days in your company.
During the first few Sprint your team members may be asking questions as: What does 3 mean again? and 5..hmmm.. how about 13. I don’t have card for 10? That’s perfectly normal to ask.
Re-Voting
It’s unlikely that everyone will come to the same number on the very first voting. It may be possible that majority come with same numbers with a few on the extremes.
People voted on the extremes should be asked to explain their rationale. After listening to arguments and arguments team should vote again. Move on to the next PBI as soon as you hit a consensus. Again it’s not necessary that everyone has the same number. In the interest of keep moving in the meeting you may pick the number with majority of the votes and continue on to next PBI. With time you’ll get better with all this.
IMO you should not go beyond two rounds of voting (including the first round) for a PBI. If you need multiple rounds then there is a bigger problem. People should have a good understanding of the PBI prior to coming to the Sprint Planning meeting. Focus on solving that problem first.
Total Story Points
At the end of the Sprint Planning meet you should total all the Story Points of individual PBIs and find out what the total is. This total is very important. Total will dictate your Velocity. If you did x this Sprint, you should be able x next Sprint and so on.
Still not convinced
Well, you are not alone, I struggled for a long time. All I can say is keep practicing and you will get it.