Why Story Points cannot be starting from 10 , 20 , 40, 80 (higher number value)

Last post 07:15 am September 16, 2020
by Ryan Brook
6 replies
Author
Messages
06:39 pm September 13, 2020

Can Story Points start with higher numbers like 10, 20 , 40 80,160,320  and so on? 

Purpose : Just story pointing

Yes, the ask is different from our usual way of Story Pointing (1,2,3,5,8,13,20,40 , etc) but can a team decide to go with 10,20,40,80  way :)

 

 

04:46 pm September 14, 2020

can a team decide to go with 10,20,40,80

Would doing so improve their ability to forecast how much work they can take on in a Sprint?

04:47 pm September 14, 2020

Back when I was a developer, I used to (half-jokingly) threaten to not estimate anything for less than 1,000,000 points unless the manager would stop using velocity as a performance metric.

Actually story points are an optional practice, and there is no universally agreed way of using them. If a Development Team find it helpful to estimate with the numbers that you provide, then of course they can do that.

But what is the purpose of having every value as a multiple of 10? Wouldn't it be easier to just use 1,2,4,8, etc?

Could having such large numbers (and therefore large gaps between them) encourage teams to pursue the level of precision that story points are intended to discourage?

08:46 pm September 14, 2020

In reality you could use anything you want to estimate such as t-shirt sizing (extra small, small, medium, large, extra large, extra extra large, etc).  The modified fibonacci sequence was originally used to show that there are incremental differences but not necessarily doubling in size each increment.  Your suggestion of 10, 20, 40, 80, 160, 320 indicates that each increment is twice the size as the previous.  There is technically no problem with that since story points are nothing but estimates( i.e. guesses made based on the information you have available).  So whatever your team feels is best way to represent their estimates. But I do echo the same questions that @Simon Mayer

09:56 am September 15, 2020

As they should be relative sizing, I would not go with 10, 20, 40, 80... as it would always be double, but of course you could go with 10, 20, 30, 50, 80, 130... using Fibonacci multiplied with 10, if there is an issue going below the 10 points

11:18 pm September 15, 2020

Which is easier.

(1) Hello Developers. How many of these refined Product Backlog Items can you fit into the next one week Sprint?

(2) Hello Developers. I want you to use t-shirt sizes and Fibonacci numbers and assign arbitrary values to these user stories in [Insert Tool Name Here]. And if you cannot all agree, lets then use Fist to Five to figure out the outliers, and then we will talk to the outliers and convince them to switch their vote. And if any of you don't document this in [Insert Tool Name Here] we will need to have a chat.

07:15 am September 16, 2020

The simple answer to your question is that the team can estimate however they want! No one should tell the DT how to estimate. As long as the process chosen is understood by the team and supports a common language, you can do anything you like.

Why don't you try using the numbers you proposed, then evaluate it in the Sprint Retrospective? If it helped, great, if not, try something else :).