# The Estimation Net

29 January 2013

"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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

### Article Rating

Current rating: 5 (1 ratings)

### Comments

Rex Lester, CSM, 1/29/2013 6:46:45 AM
I like this idea a lot. Even with experienced teams cards can be a bit of a dry experience. This should help increase the participation and debate (Reminds me of the Top Gear cool wall?)
I will definitely give this a try.
Tara Garrison, CSM,CSPO, 1/29/2013 12:15:40 PM
I like this idea, thanks for sharing. I will give this a try too.

Curious on more about how to get stories within the 'size selection'. We are finding it difficult to get stories split vertically from 20 & 13 to do-able/manage-able 8 & 5 sizes. Any tips or feedback would be greatly appreciated!
Bill Ambrosini, CSP,CSM, 1/29/2013 6:21:16 PM
What I like most is that it's easy to put into practice and provides ongoing value for the team during estimation sessions. I can't tell you how many times my team asks each other "how big is 3 points again". They always try to recalibrate and gravitate towards time based estimates. This can help keep them from drifting. Good idea, thanks.
Stanislav Kalkanov, CSM, 1/30/2013 1:47:51 AM
Thanks for short and useful description with examples. It's really very simple and powerful technique. I've used it in couple of projects.
Kirill Klimov, CSP,CSM,CSPO, 1/30/2013 12:43:33 PM
Tara,
Yes, splitting stories is known challenge that a lot of teams are facing. A lot written on this topic already, probably still a lot of space for additional information. Don't think I could provide complete quick tip, but I'll try.

It is important to split stories vertically, as you already mentioned. Few ideas on vertical splitting:
ΓÇó by user role. If your user is too generic, you could split it to few more specific users and develop separate stories for those new roles. Each such story could be less in size than original one (though all of them probably would be bigger);
ΓÇó go through your acceptance criteria. Usually there is a good chance to split by removing some of criteria from stories;
ΓÇó split away NFR part (Non-functional Requirements) from original story so separate US.

Hope this helps. Here are couple links which could also help:
ΓÇó http://www.scrumalliance.org/articles/87-writing-the-product-backlog-just-enough-and-just-in-time
ΓÇó http://www.mountaingoatsoftware.com/blog/non-functional-requirements-as-user-stories
Tara Garrison, CSM,CSPO, 1/31/2013 2:54:30 PM
Thanks Kirill! Appreciate it...
Steven Arthurton, CSPO, 2/1/2013 7:45:12 AM
Good article - this will definitely add to the teams debate when we have our next estimation session.
Olexiy Chernovolod, CSM, 2/1/2013 8:48:31 AM
Good article. I made such "estimation net" for my teams. But 1 more challenge appeared that is not mentioned in the article. My teams said that story really took 8 story points when we did it half a year ago, but today with our new framework that we use and with more knowledge about the system the same story can take us 3 or even 1 story point. And it was hard sometimes to find the user stories that are similar to new stories and would "cost" the same story points before and today.
Kirill Klimov, CSP,CSM,CSPO, 2/1/2013 2:06:01 PM
Olexiy, great comment, thank you.
This tool is aimed at the future ΓÇô to help us with future estimates. By any means it is not historical evidence. Therefore, if some story was 8 at time you developed it, but now for your team it is just 3 - put it under ΓÇ£3ΓÇ¥ on your net. So that next story, close to this one would be sized correctly.
Jim Rice, CSM, 2/1/2013 7:37:49 PM
Great stuff Kirill! And now in my bag too.Thanks!
Kirill Klimov, CSP,CSM,CSPO, 2/6/2013 10:33:05 AM
Russian translation is now available at Habrahabr:
http://habrahabr.ru/post/167983/
Manish Gupta, CSM, 2/27/2013 9:34:23 PM
Cool. Liked it. I faced this situation many times, when team says it is more than 3 but not 5. Easy - put it in 5. Simple and effective.
William Asch, CSM,CSPO, 4/5/2013 9:03:50 AM
Thanks for the tip, I really like this. I've heard similar suggestions before, but I especially like how you laid it out. Thanks!
Gurpreet Singh, CSP,CSM, 5/11/2014 6:55:32 PM
Nice one Kirill. I really liked your idea. This would also break the 'large' stories into smaller sub-stories which also means easier UAC, DOD, Scope much clearer, etc.

Keep it up!

You must Login or Signup to comment.