Planning Poker relies on relative estimating, in which the item being estimated is compared to one or more previously estimated items. It is the ratio between items that is important. An item estimated as 10 units of work (generally, story points) is estimated to take twice as long to complete as an item estimated as five units of work.
An advantage to relative estimating is that it becomes easier to do as a team estimates more items.
- Planning Poker is extremely simple to play while also being accurate enough to use for agile planning. The basic rules are as follows: Planning poker is based on a list of features to be delivered, several copies of a deck of cards and optionally, an egg timer that can be used to limit time spent in discussion of each item.
- Planning Poker was created by James Grenning in 2002 and seems to be a simplified version of another popular estimation method — Wideband Deplhi (although Grenning himself claims he would have.
Estimating a new item becomes a matter of looking at the previously estimated items and finding something requiring a similar amount of work. This is easier to do when the team has already estimated 100 items than when they’ve only estimated 10.
Agile Planning Poker Rules I posted earlier on planning poker, and since it's a popular post, I thought I'd post again on it. One item that came up in a recent sprint retrospectives (in the 'Where do We Need to Improve?'
But, relative estimating like with Planning Poker suffers from a bootstrapping problem: How does a team select the initial estimates to which they’ll compare?
My recommendation is that when a team first starts playing Planning Poker, team members identify two values that will establish their baseline. They do this without playing Planning Poker. They do it just through discussion. After the baseline is established, team members can use Planning Poker to estimate additional items.
Ideally, the team is able to identify both a two-point story and a five-point story. There is evidence that humans estimate most reliably when sticking within one order of magnitude.
Identifying a two-point product backlog item and a five-point item does a good job of spanning this order of magnitude. Many other items can then be more reliably compared against the two and the five.
If finding a two and a five proves difficult, look instead for a two and an eight, or a three and an eight. Anything that spans the one to 10 range where we’re good estimators will work.
Avoid Starting with a One-Point Story
I like to avoid starting with a one-point story. It doesn’t leave room for anything smaller without resorting to fractions, and those are harder to work with later.
Additionally, comparing all subsequent stories to a one-point story is difficult. Saying one product backlog item will take two or three times longer than another seems intuitively easier and more accurate than saying something will take 10 times longer.
I made this point in my 2005 “Agile Estimating and Planning” book (now also a video course). In 2013, it was confirmed by Magne Jørgensen of the Simula Research Lab. Jørgensen, a highly respected researcher, conducted experiments involving 62 developers. He found that “using a small user story as the reference tends to make the stories to be estimated too small due to an assimilation effect.”
Why Use Two Values for a Baseline?
Establishing a baseline of two values allows for even the first stories being estimated to be compared to two other items. This is known as triangulating and helps achieve more consistent estimates.
If a team has established a baseline with two- and five-point stories, team members can validate a three-point estimate by thinking whether it will take longer than the two and less time than the five.
Citing again the research of Jørgensen, there is evidence that the direction of comparison matters. Comparing the item being estimated to one story that will take less time to develop and another that will take longer is likely to improve the estimate.
Don’t Establish a New Baseline Every Project
Some teams establish a new baseline at the start of each project. Because this results in losing all historical velocity data, I don’t recommend doing this as long as two things are true:
- The team members developing the new system will be largely those involved in the prior system. The team doesn’t need to stay entirely the same, but as long as about half the team remains the same, you’re better off using the same baseline.
- The team will be building a somewhat similar system. If a team is switching from developing a website to embedded firmware, for example, they should establish a new baseline. But if the systems being built are somewhat similar in either the domain or technologies used, don’t establish a new baseline.
Whenever possible, retain the value of historical data by keeping a team’s baseline consistent from sprint to sprint.
How Do Establish Your Baseline?
How do you estimate your baseline and initial estimates for a new team? Please share your thoughts in the comments below.
Scrum card game
Planning Poker is a way for Scrum & Agile Development teams to estimate the effort to reach their goals.
It is a fun game in which each participant uses cards to give his estimation about the time to complete a certain task. The main advantage of using cards is that the first person to provide an estimation will not influence the estimation provided by the next person. This eliminates bias and ensures every persons opinion is heard.
Here are 4 steps to help you playing planning poker in a fun and effective way.
1. Put the participants at ease.
If it is the first time to use the planning poker, have a little Chat. How are you doing today? Engage in a small talk. Ask if anyone already had played planning poker before. If not, ask if they are willing to try something new this time. If the majority is willing to try, then you can introduce the playing cards. It is important to create an relaxed environment where people can allow themselfs to try and make mistakes. Remove the pressure for results and introduce the game in a joyful way.
2. Explain the rules.
After everyone agreed to play the planning poker, hand out the cards and start explaining the rules. It is important that each person thinks for himself on how long a certain task will take. Choose the appropriate card and place it face down on the desk. Only when all the players placed their cards on the desk, these can be turned. If the estimations are close to each other, it means that the subject is well known. If the range of estimation is high, that means there is still a lot of uncertainty related to the task.
3. Find consensus
Wherever differences in the estimation exist, allow the player to explain the reason for the estimation. Through this dialogue try to reach consensus. If no consensus is found, write down the range of estimation and move on. Use a timer to keep track of the time spend for discussing the estimations.
The question mark is ment for those who can not provide an estimation. Alternatively, small, medium and large can also be given as estimate.
4. Experiment and adapt
As you move along, find out what works for you. Adapt the rules and content to fit your needs and your team. Find creative ways to keep the game engaging.
Here is a nice video from Mountain Goat Software explanaining how to play the planning poker. This gives all the details on how to proceed.
Agile Planning Poker Rules How To Play
And here you can get some cool cards if you are willing to try this approach.
Agile Planning Poker Rules For Beginners
Hope the information provided here helps you making your next planning meeting full of joy and bring you even better results.