Ragrding estimating user stories size

Update:

Also, I didn’t what he means by point #2?

Does he mean when the team creates each sprint, the sprint is to be ((SMALLER OR EQUAL TO 10)) user stories?

The team follows two rules: (1) The development team should not allow any single user story larger than an 8 to be pulled into a sprint, and (2) scrum teams should be able to complete roughly 6-10 user stories in a sprint

I don't know what book you're referring to. Also, you may read/interpret it incorrectly or the book itself provides inaccurate information.

Q1: If the reference is made to story points aligned to the Fibonacci sequence (FS), then 8 would seem rather high (compared to 1, 2 or 3), hence the likely suggestion to break large stories down to more edible numbers, and avoid stories with 8 points to be pulled into sprints because it means such stories are rather large and/or complex and/or not understood well enough and/or there are external dependencies for it to be completed, etc.

Note however that teams can use any variations they want and have, for instance, 10 as the bottom scale (1 if FS), followed by 20, 30, 50, 80, 130, and so on. Or they could use 10, 20, 30, 40, 50, 60, 70...

Q2: There's no rule or scope in itself. Each team has its unique characteristics. A small team may complete two, three, five or just one user story. A larger one may complete two, three, five or forty. 

Eugene M

Many Thanks for reply

I Agree with you 100%

Really, user story of 8 size is so big, and need to be decomposed to some userites

Best wishes

I firmly disagree that a story of size 8 is too big to be done in a sprint.  I have teams accomplish multiple 8's in a sprint.  But then I have other teams that cringe when they point an 8 because it is big.  I will also say that I had one team that would frequently pull in 13s or 20s but they would be very wary of pulling in anything else. It is entirely up to the team to decide. They are the ones that are responsible for what ever scale they use and how to interpret it.  

I also don't agree with the "...6-8 story..." statement for reasons I stated above. 

I do not know what book you are reading but if it is telling you "exactly how to use story points and how many stories a team can do" then I firmly believe it is a fiction book.  There is no right way to do it.  There is only a right way for a specific Development Team to do it and that is decided by the Development team and no one else. And every team is different so what applies for one is not what fits for another. 

These are relative estimates, and whatever values the team uses to help them plan are 100% germane to that team.

Any book therefore that claims a universal understanding of what an 8-point story is should be thrown in the trash.   A huge red flag, in my opinion.

RippleMan Al-subaiee, look at Daniel's and Timothy's replies for extra depth.

Really, user story of 8 size is so big, and need to be decomposed to some userites

Note I didn't say stories estimated at 8 are so big they need to be broken down into smaller ones. What I said was "If the reference is made to story points aligned to the Fibonacci sequence (FS), then 8 would seem rather high (compared to 1, 2 or 3), hence the likely suggestion to break large stories down to more edible numbers".

In my current setup, my colleagues and I take a plethora of stories in consideration, regardless of whether they are a 1 or a 13.

Again, read the preceding two comments for better understanding

@Eugene, point taken and after rereading I can completely understand your stance. 

I agree with @Timothy. If I read this in a book, that book would quickly find it's way to the trash bin or be saved with a big note written across the front of it in Sharpie that says "Book of how to do it wrong". 

@RippleMan, I think you get the point here.  There is no "right way" to do it as provided by all of our discussions and disagreements. Anyone that tells you otherwise is going to be wrong. 

If I can comment further, and perhaps provide a little more context around the book's assertions.

There is inherent benefit, both from a flow and understanding perspective, to working with smaller items.   I can see where the author of the book sees benefit in pursuing this, but he frames his argument very poorly.

Also, there is plenty of empirical evidence supporting the fact that individuals have difficulty ranking items at more than a 5-scale.   Consider how you respond to a survey question where you rank something on a 1-5 scale, and then compare that to a similar situation where the ranking is on a 1-10 scale.   People have a very difficult time effectively differentiating whether something should be a 6 or a 7 on a 10 scale, for example.

To bring this back to the issue at hand, Scrum Teams usually find their estimating "sweet spot" by choosing from 1 of 5 values, whether they be part of the Fibonacci sequence (1,2,3,5,8), or t-shirt sizes (xs, s, m, l, xl), or animals, or whatever they decide to use.   I often coach my teams to think of placing an item into one of 5 "bins", and that helps them relatively estimate in a very lightweight fashion.