Effective estimating with estimation board

There are many arguments about estimating in the agile community. Do we need to use story points, man/hour, ideal man/day, or even #NoEstimation? Today most agile teams are trying to use the story points as the main unit for estimating.

What is the story point?

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values? A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

By Mike Cohn

But the main problem is how to assign a story point to an item? This is 5 story points, but how?

Planning poker is dead, Long live Planning Poker

Based on Mike Cohn’s article, Planning Poker is an agile estimating and planning technique that is consensus-based. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. The values represent the number of story points.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

The problem is exactly here. “Each estimator privately selects one card to represent his or her estimation”, But in the real world, estimators forget the relativity of points. In my experience, when somebody assigned a 2 story points to an item, He didn’t think to “Oh, It should be two-thirds of a story that is estimated as 3 story points”, Most of the time something goes like this “This is 1 hour for me and maybe 1 hour for front-end developer, so it’s 2 story points.”

As I experienced before, Sometimes Planning Poker is not an effective technique to assign story points on backlog items, because the development team forgets the relativity of story points and story points are useless without relativity. We need to tweak it and this article is about the tweaking Planning Poker technique.

At the same time, planning poker is an effective planning technique because it helps the team to have a conversation about the story and the user’s needs. In the conversation about the story, you will find a new idea or even change the story or….

However Planning is over Plans, Estimating is over Estimations.

Estimation Board

Estimation board is a practice based on my experiences to improve the relativity problem of planning poker technique.

In this practice, you will just add a board (whiteboard or …) to your planning poker process. After estimating any item, you need to put it on your board. Make it visual and transparent.

Something like the following image:

Estimation board — Image 1

Try to create columns for each category, like the following image:

Estimation board — Image 2

Keep continue estimation and planning process and update your board:

Estimation board — Image 3

After finishing the estimation, let finalize estimates based on relativity. Let team members check one column each time. For example, there are 3 items in category 2. “Are they the same size?” If not, you can move items to other columns.

This is a simple visualizing practice, but this practice will help you to improve the relativity problem.

Keep relativity all over the project/product lifecycle

You can’t change your estimation touchstone in each sprint. You need to keep this relatively all over the project’s lifecycle. So, easily you can keep the first row of this board and use it in the next sprints too. It will help the team to have balanced estimation during all over the sprints or releases.

This article published in this address too.

Maybe you like: 5 Steps to avoid Imposter syndrome for Agile Coaches

About the Author:

Asad Safari is an Enterprise Lean/Agile Coach. He works as an Agile coach for more than 7 years with several enterprises and startups. He has more than 14 years experience in the IT industry as a Software Developer, Tester, and finally agile practitioner. You can follow Asad on Twitter and LinkedIn.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store