The Estimation Net

"Scrum is easy; implementation is hard" — probably you've already heard that many times. The same goes for some particular tools, like planning poker. The practice itself is very straightforward, but how to use it productively over a long period of time is harder.

In this article I'll share a simple, lightweight technique that makes the sizing process a little easier in the daily life of a Scrum team.

Let's look at the challenge. As you know, story points are relative measures of size. So there's no way to estimate one single story in story points; you're always comparing one story to other stories via story points. That often works well in the very beginning of your Scrum project, when a team estimates a lot of new stories during a short period of time.

But later, during regular reestimations of existing stories or estimations of newly added stories, it becomes much harder because the calibration of one story point is forgotten: "What is one story point?" "Is this story really three times bigger than our gold standard? I'm not so sure. . . ." "These two stories of size 5 don't look similar to me." Recognize the challenge?

Suggested solution

There is a nice, easy solution for this problem, and I call it the "estimation net." The idea is very simple: Create a visual table, one row for each estimation size you're using. If you're using the Fibonacci sequence for estimations, you'll have separate rows for 0.5, 1, 2, 3, 5, and 8. And then for each size (each row), you put in a few story cards as examples for that size. Here's an illustration of how it should look:

Having such a net in front of your team during the sizing process makes it much easier, because you have a few real examples within each size and can compare your new story to these examples.

How to fill such a net in a first place? The general rule of thumb is: Add only "typical" stories, so there's a chance that you'll do something similar to them in the future. Preferably, stories need to be put into the estimation net after they're done, so we have some real-life experience with them. The estimation net tool is aimed to help you with future estimations, after all. Therefore, if a specific story was unique and you aren't likely to do anything close to it in the future, there's no place for that story on this net.

More hints on how to build the estimation net

Another hint that solves a lot of difficulties some team members might have is this: It's important to remember what some exact estimation values mean. Let's say 5 — what is that? Let's remind ourselves how we do estimation. If the team believes a story size is bigger than 3 and less than 5, it becomes 5. So, basically, 5 means all stories within the interval from 3 to 5. Remembering that makes it much easier to put into the same row, as equal, two fairly different stories (for example, let's say one story that's just little bigger than 3 and another that's just a little less than 5). I put those intervals close to size value in the first column (as you see in the picture above) to visually remind us of that.

And we review and improve this net over time (of course!). During each sprint retrospective, or once every few iterations, you could go through your network to check whether all present stories are still relevant and if it's reasonable to put in some new stories that you've just worked over.

It works best if you have two to five stories as examples for each size (each row). You should have some minimum as a basis for comparison. And you shouldn't have too many stories, because that would make the comparison process too complicated and lengthy.

Here are a couple of examples how this net might look like in real life:

There's no reason to have your net cover all possible size points (such as 20, 40, or 100). You need to focus only on those sizes that are relevant for stories small enough to come into iteration. That will depend on your size selection, and my suggestion for that is: all sizes up to 8.

Again, this tool is very easy to introduce and use. In my experience, it receives an extremely low level of resistance from teams — in other words, it's accepted very well, so you're not taking much of a risk by trying it out. As far as I'm concerned, it's an easy process experiment to discuss with your team during the next retrospective. Give it a try.

If you have any questions, feel absolutely free to contact me through my profile or via a comment to this article.