Effective estimating with estimation board
There are many arguments within the agile community about estimation. Should we use story points, man-hours, ideal man-days, or even #NoEstimation? Currently, most agile teams use story points as their main unit for estimation.
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.
However, in reality, estimators often forget the relativity of story points. In my experience, when somebody assigns 2 story points to an item, they don’t always think “Oh, it should be two-thirds of a story that is estimated as 3 story points.” Most of the time, it goes something like this: “This is 1 hour for me and maybe 1 hour for the front-end developer, so it’s 2 story points.”
Therefore, Planning Poker is not always an effective technique to assign story points to backlog items because the development team forgets the relativity of story points. However, Planning Poker is still 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 can find new ideas or even change the story.
However Planning is over Plans, and Estimating is over Estimations.
Estimation Board
To improve the relativity problem of the Planning Poker technique, There is another practice called the Estimation Board. In this practice, you add a board (whiteboard or other types) to your planning poker process. After estimating any item, you put it on the board, making it visual and transparent. Create columns for each category, and keep updating the board as you continue the estimation and planning process.
Something like the following image:
Try to create columns for each category, like the following image:
Keep updating the board as you continue the estimation and planning process:
After finishing the estimation, finalize the estimates based on relativity. Let team members check one column at a time. For example, if there are 3 items in category 2, ask “Are they the same size?” If not, you can move items to other columns. This is a simple visualizing practice, but it helps to improve the relativity problem.
Keep relativity all over the project/product lifecycle
It’s important to keep relativity consistent throughout the project/product lifecycle. You can’t change your estimation touchstone in each sprint. You need to keep it consistent throughout the project’s lifecycle. Therefore, you can keep the first row of this board and use it in the next sprints too. This will help the team to have balanced estimations throughout all the sprints or releases.
Maybe you like: 5 Steps to avoid Imposter syndrome for Agile Coaches