Most agile teams estimate relatively. This means they estimate items in comparison to other items. With relative estimation, a team doesn’t have to decide exactly how much effort is involved in developing a given product backlog item. Instead, the team only has to compare the item in question to other similarly sized items.
For example, I don’t know how long it will take to develop this particular user story, but I think it will take twice as long as that other user story. As another example that's closer to home, I think pruning the trees in my yard will take twice as long as mowing the lawn.
In the figure below, item B in the figure below is estimated to be twice the effort of item A. And item C is then estimated to be twice that of B. Put another way, C is four times larger than A.
To ensure they are being accurate, the team should consider that ratio, asking themselves, “Does C seem like it will take four times the effort of A?”
It would be ideal for a team to compare each item being estimated to all previous items. But doing so would mean that a team’s 100th item would be compared against all 99 previously estimated items.
This is too inefficient to be seriously considered.
Triangulate User Story Estimates
A more efficient strategy for relative estimiation is to compare an item being estimated to two previous estimates. This technique is known as triangulating. (Triangulation is also an effective way to prevent estimate inflation.)
The two items used in the comparisons should not be randomly selected. Instead, team members should pick one estimate that is slightly smaller than what is being considered and one that is slightly larger.
For example, if a team is thinking of estimating an item as 5 story points, team members should compare it to items previously estimated as 3 and 8, if using the Fibonacci scale. It’s also a good idea to occasionally compare against an item thought to be of the same size rather than one lower or higher. So when considering a 5-point estimate, team members might compare against items estimated as 3 and 5 or 5 and 8.
When I do this on, let’s say, a 5-point item, I ask team members, “So, if we estimate this as 5 points, we’re saying it is around 50% bigger than this three-point item. Does that seem right?”
If it does, I’ll ask a similar question comparing the item to one with a larger estimate, an eight in this case. I’d say, “And we’re saying it’s about half the size of this 8-point item. Does everyone agree?”
Build a Reference List of Good Comparisons
It’s important to select good backlog items for the comparisons. If your team feels like a particular item was incorrectly estimated, you should not use that item in future triangulations. Doing so would lead to incorrect comparisons that will lead to bad new estimates.
What I’ve found most useful is compiling a list of good items to use for comparisons. I can then refer to that list any time I need to find a good comparison item of any size.
While compiling this list of good backlog items to compare against, I find two criteria important:
- Team members still agree with the estimate after the item has been developed
- Most team members understand the item
The first point eliminates anything that was poorly estimated, such as a 5-point item that team members now think should have been estimated at 13 points.
The second point excludes esoteric items that were understood by only a small subset of the team. For example, a story may have been well estimated (the first criterion) but if it was only worked on and understood by two team members, it’s not a good item to add to the list.
The Right Number of Comparison Items
A good list of favorite comparisons will contain 15–30 estimated product backlog items. Fewer than that and you’ll struggle to find appropriate comparisons and will have to reuse the same items over and over again. That’s dangerous because if one of the selected items wasn’t well estimated, any small error is compounded by doing frequent comparisons against it.
You can’t have too many items on your comparison list. But most people fall back on using their few favorites over and over again. When manually selecting items for comparison you’ll most likely choose from the same 15–30.
Age Old Items Off the List
It’s useful to remove items from the list as they age. A three-year-old item might have been well estimated and understood by the majority of team members back then. But by the time it’s three years old, the team may have many new members with no understanding of the old item. Even those who stayed with the team won’t remember the item with sufficient clarity for it to still be a good comparison item.
So remove old items from your comparison list as they age.
Auto-Triangulation in Planning Poker™
We have made triangulating your estimates easier with our auto-triangulate feature inside the Agile Mentors Community Planning Poker tool. A 1-year membership in Agile Mentors comes wtih every Mountain Goat course. If you want to join, sign in, or resubscribe to Agile Mentors, visit the Agile Mentors community page.
How Auto-Triangulate Works in Agile Mentors Planning Poker
Here’s how it works: When a team is estimating, anyone on the team can click the auto-triangulate button. Normally this will be done by a Scrum Master, coach, or whoever is facilitating the Planning Poker session.
Whoever clicks auto-triangulate will be asked the number they want to triangulate around. After entering a value, the system will automatically and randomly select items with the next lower and higher values. So if, as in our example above, I want to auto-triangulate around 5, the system will display items that were previously estimated at 3 and 8 points.
Your Favorites in Planning Poker
The items that are shown as comparisons are randomly chosen from a set of items that have been previously marked by a player as “favorites.”
In Agile Mentors Planning Poker, you can easily identify an item as one you’d like to use for future comparisons. To do that, simply click the star that is shown on the top left of any current item being estimated, as shown in the following image. A yellow star indicates the item has been marked as a favorite. Items not selected as favorites are shown with an empty outline of a star.
You can see a list of all marked favorites by clicking the Items button in the top right of the window. That will display the Items window with a Favorites tab showing selected favorites as can be seen in the following image. From this page you can remove any item you no longer want favorited for use in auto-triangulating.
How Comparisons Are Selected
When someone clicks auto-triangulate, Planning Poker prompts them for the value they want to triangulate around. Planning Poker will then select the closest item below that value and the closest item above it. If multiple items have the same value, one is randomly selected. To see how this works, suppose you have favorited the following items:
| Item | Estimate |
|---|---|
| A | 1 |
| B | 5 |
| C | 5 |
| D | 8 |
| E | 13 |
If you tell the system to auto-triangulate around 8 points, Planning Poker will randomly choose to display one of the two items estimated at 5 points. And it will show E, the one favorite that was estimated as 13.
If instead you request an auto-triangulation around 5 points, estimators will be shown the 1-point story and the 8-point story. This team was presumably using the Fibonacci sequence but no items estimated as 2 or 3 points had been favorited. Planning Poker, therefore, selects the next lowest number, which is 1 in this case.
Your favorites persist between sessions, of course, so you can compile a list of great backlog items to compare against.
Whether you use an automated tool like Planning Poker or derive your estimates some other way, you'll get better estimates when you triangulate.
