Planning Poker Baseline
- Planning Poker is a highly efficient agile planning and estimating technique which has become exceptionally well-known over recent years. It is based on a procedure known as Wideband Delphi that was made by the RAND Corporation between 1940 and 1968, the exact year unknown.
- Poker planning bring all such missing information to the table for discussion. Read my earlier posts on using story points to even out such differences. Even team finally agrees to go with higher number, scrum focus on honesty here. Say the team finished that story well before time, then they should pick-up something more.
- To estimate PBIs you need to choose an average story and assign it a number of points (for example 5). Then you compare all other stories to that story and assign points accordingly. My question is, are you really supposed to compare every single story to that original story from the beginning of the project?
- Planning Poker Baseline Games
- Planning Poker Baseline Rules
- Planning Poker Baseline Template
- Planning Poker Baseline Meaning
Planning Poker is an agile estimating technique which has become very popular in the last few years. It is based on an estimation technique known as Wideband Delphi which was created by the RAND. In Planning Poker, items are estimated one by one, and each of them should be compared to a baseline. But the problem is that session participants often try to figure out how many times bigger the given item is and here is where the estimation fails.
There are various ways to estimate app development projects. One way is by using so-called Story Points. While this type of estimation might not be the easiest, estimating with Story Points in Agile offers benefits to both app developers and clients.
The Story Points approach uses historical data to compare features of one project to features of a previous similar project to generate a precise estimate.
The gears in the image above are of different sizes and have unique attributes — just like features in a software development project. Imagine there were no way to measure the size of a circle. How could we determine the exact size of each gear? We could use Story Points!
Story points are extremely important for lean startup and Agile methodology. Here are the reasons why.
Let’s walk through each step of the estimation process with Story Points.
Step 1 — Identify a Base Story
Story Points in agile are a complex unit that includes three elements: risk, complexity and repetition.
To find our Base Story, we search for one elementary task that corresponds to internal standards of Definition of Done for User Stories and assign it one Story Point. This will be our Base Story.
Step 2 — Create a Matrix for Estimation
There are two types of scales used for creating estimation matrices: the linear scale (1,2,3,4,5,6,7…) and Fibonacci sequence numbers (0.5, 1, 2, 3, 5, 8, 13 …).
Here at RubyGarage we use Fibonacci sequence numbers. We do this because people are really good at comparing sizes, but not at estimating absolute values such as number of hours. The difference between 1 and 2 can seem insignificant. However, the difference between 1 and 5 is obvious.
When estimating using Fibonacci sequence numbers, we create a matrix with rows for each sequence number and their associated stories. Then, we gather all our stories and start classifying them into rows, comparing the stories to each other and to other completed stories. Notice that our Base Story is already in this matrix in the first row with a value of one Story Point.
Here is one of our matrices:
To assign Story Points to each story, we have a meeting where all specialists that will work on the project get together and play Planning Poker.
Planning Poker is a consensus-based estimation technique to estimate product backlogs. It can be used with various estimating units, but we use Planning Poker with Story Points.
Find out how we build Scrummer - an app for Planning poker.
Here’s how it works:
Planning Poker Estimation Process
Each estimator gets a set of cards;
All estimators select backlog items, discuss features, and ask questions;
When a feature has been fully discussed, each estimator privately (to make the estimate objective) chooses a card to represent his or her estimate;
When all estimators have made their estimates, they reveal their cards at the same time. If all estimates match, estimators select another backlog item and repeat the same process. When estimates differ, the estimators discuss the issue to come to a consensus.
By the end of Planning Poker, we’ve filled out the whole matrix. Our tasks are divided into rows by the number of story points needed to implement them. Finally, we place each backlog item in the appropriate row. There can be several stories in one row.
Step 3 — Planning the Sprint
Now that we have a size estimate, you may be wondering how we convert these sizes into man-hour estimates. Unfortunately, we can’t do this until the first sprint is completed. While the first sprint is in progress we can track the team’s velocity. As soon as the sprint is finished, we’ll know how many Story Points a team can complete per sprint. We use these numbers to forecast the team's performance for the next sprints.
When we have all backlog tasks estimated in terms of Story Points, we can understand how many sprints we’re going to need to complete the project. And finally, we can convert these abstract units into real calendar timelines.
RubyGarage estimates with Story Points in Agile because it’s quick and helps us understand the relative effort required for stories we’ve never faced before. Story Points help us provide our clients with more accurate estimates. Experience and reference points speak better than abstract man-hours.
Struggling with project delays and unrealistic estimates? Contact us and we’ll help you launch your product on time and within your budget.
Planning poker® is an estimating method used predominantly in agile environments. It brings together elements of comparative estimating and group decision making techniques such as Delphi.
In a project that uses agile development, a team will need to estimate the work involved in a number of user stories that they intend to work on within a given timebox (or sprint).
The team will involve people with different estimating styles, different levels of experience and different technical skills. To reduce the spread of estimates and enable everyone to contribute to the estimating process the first principle of planning poker is to estimate in ‘story points’ rather than hours or days.
A story point is a relative measure of size and complexity (hence the link to comparative estimating). The team will start off by selecting a relative simple story and assigning a value of 1.
A common example used is that of painting a wall. This is a relatively simple job and would be assigned a value of 1 – this is the baseline story. A novice painter and an expert decorator may take very different amounts of time to paint the wall but they would agree that it is a simple, straightforward job. They would also agree that painting two walls would be 2 story points. They may also agree that painting all four walls in a room would be only three story points because of the economies of scale.
Planning Poker Baseline Games
To continue with the decorating example, the team may also have to consider painting a window. This requires more preparation and careful masking of the glass. It is more complex than painting a wall and so may be given a story point value of 2.
Planning Poker Baseline Rules
The process now needs to garner opinions from all the team members without bias. This is where the ‘poker’ cards are used in a way that has similarities to the Delphi process.
Team members are given a set of playing cards that have values loosely based on the Fibonacci sequence (1, 1, 2, 3, 5, 8, 13…….). The reason that these cards are not a linear progression (1, 2, 3, 4, 5) is that the larger and more complex a task is, the more difficult it is to estimate accurately.
Planning Poker Baseline Template
The ‘infinity’ card may be used to indicate that the estimator does not think the task can be completed and the ‘?’ is used if the individual is unable to provide an estimate.
The process starts with everyone studying a user story (e.g. painting a window) and having a brief discussion about what this involves. They then privately assign a story point value (by comparison with the baseline story). It is important that there is no conferring at this stage. Everyone is then asked to reveal their estimate by placing a card on the table simultaneously. This avoids the discussion being overly influenced by the first estimate (a concept known as ‘anchoring’ where people adjust their opinion based on someone else’s opinion).
If all the estimates are within one step on the scale (e.g. all 3s and 5s or all 5s and 8s) then the story is assigned the higher value. If the range of estimates is greater than typically the facilitator will ask someone with a low estimate and someone with a high estimate to explain their reasoning.
It may be, for example, that the user story wasn’t precise about the type of window and different estimators made different assumptions about the complexity of the window based on their recent experience.
The estimate range may then be narrowed by clarifying the story (access to the originating user is necessary here) or reaching a common understanding about the complexity of the task amongst the team and repeating the process.
Each team that develops user stories within a timebox, will have a ‘velocity’. This is the number of story points that they typically complete within a given period (e.g. 2 weeks). Calculating velocity clearly needs some sort of conversion from story points to time (in hours or working days). Velocity is an inherent quality of a team and at the start of the delivery phase of a project this is, in itself, an estimate. As more timeboxes are completed the greater certainty there will be about a team’s velocity. This then enables higher level planning to be done by the project management team based on the story point estimate done by the delivery teams.
Planning Poker Baseline Meaning
Planning Poker® is a trademark of Mountain Goat Software