# A good guide on choosing the point scale to use with Agile/SCRUM?

We're using Pivotal Tracker for our project, which lets us choose from these three point scales:

``````0,1,2,3
0,2,4,8
0,1,3,5,8
``````

And I'm looking for a resource to help guide our decision. (After using 0,1,2,3 for two iterations, we can see where one of the others would be a lot more useful or meaningful.)

• Could you explain more, it's unclear what you are asking. Commented Dec 12, 2010 at 11:28
• Sure: We're looking for a web site, article, page, or document that addresses choosing a point scale. Commented Dec 12, 2010 at 11:32
• Google is your friend. Seriously. It's not hard to find (try google.com/search?q=agile+ideal+days+points). What is hard, is finding an approach that suits your team and for that, we need more info from you. Commented Dec 12, 2010 at 11:46
• Ah hah - thanks. My "team" is micro-sized. One part time programmer (me), one part time project manager who's new to software dev, and another part time programmer who's just getting started. We're all good friends and there's no stress between the players. Commented Dec 12, 2010 at 11:47
• @Dogweather: if I was you (the only programmer in the "team"), I wouldn't use Scrum at all, but simple productivity techniques like GTD. IMHO, you are wasting your time with Scrum.
– user2567
Commented Dec 12, 2010 at 12:28

"Fibonacci" story point scale is very popular: 1, 2, 3, 5, 8 etc. Popular planning poker card decks (by Mountain Goat Software and Crisp) are based on it: question mark, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.

Mike Cohn notes in his Agile Estimation and Planning book that using 1-2-4-8 instead of 1-2-3-5-8 is okay.

It is important to remember when applying story points on "micro-sized" teams: limit the maximum story size, don't "mix pebbles with boulders" (see more at Agile for the Solo Developer)

I think what you want is something that offers enough difference with the smaller points and not that many options for larger stories, based on the fact that anything over 20 or 40 needs to be broken down anyway. This makes sure that you support finer differences for small and regular sized stories and only rough differences for larger sized stories.

When we were doing Scrum we did fine with the Fibonacci based points with 20 being the highest number that we thought would realistically fit into a sprint. If something was 40 or 100 it was basically the developers saying that the story was too large.

Other than that I don't think it makes such a great difference. I'd prefer the Fibonacci based sequence because I've found that it works. However, what works for the team and the product you're developing is fine.