Planning Poker Baseline
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.
In the early days of agile estimation and planning, T-shirt sizes were used to schedule the poker to assess the relative size of a feature against a baseline. Though this is a very successful way to decouple time from the degree of effort of the features, this was not the most effective way of assigning user storey points. If we look at items like team velocity and product backlog and re. One pitfall of Planning Poker resides in making “convergence to consensus estimate” an obligation rather than a natural result of the conversation that follows a round of play. Doing so runs the risk of erasing useful information, i.e. The degree of uncertainty conveyed by a wide spread in the initial estimates.
An advantage to relative estimating is that it becomes easier to do as a team estimates more items.
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.
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.
Planning Poker Baseline Games
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.
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 Baseline Meaning
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.
Planning Poker Baseline Rules
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.
Planning Poker Baseline Template
Struggling with project delays and unrealistic estimates? Contact us and we’ll help you launch your product on time and within your budget.