Forgive me f this has been asked before, I read some similar questions (linked below), but didn't find the answer I was looking for.

Our team is fairly new to them and trying to figure out how to best apply them?

Here' the problem, per sprint;

  • A developer who is dealing with small tickets and requests might complete;

250 x XXS (1) = 250

  • The same developer who is working on a large feature might complete;

1 x XL (20) = 20

How can you measure a teams velocity when this is the case? There is a 10 fold difference in a given developers velocity.

Our sizing chart (Fibonacci-ish)

| XXXS | XXS  | XS   | S    | M    | L    | XL   | XXL  | XXXL |
| 1    | 2    | 3    | 5    | 8    | 13   | 20   | 30   | 50   |


  • 1
    Who told you that the large story has to be 20 points? If it makes more sense because your 1 point stories are really tiny, maybe the big story is more like 100 points or more?
    – nvoigt
    Commented Feb 14, 2019 at 11:07
  • Offtopic - I understand the reason, but can't help but be triggered by the Fibonacci with 20 / 30 / 50 :)
    – Tiago Cardoso
    Commented Feb 14, 2019 at 11:11
  • @TiagoCardoso updated :)
    – Blowsie
    Commented Feb 14, 2019 at 11:37
  • Much better! Now I can die in peace, lol :D
    – Tiago Cardoso
    Commented Feb 14, 2019 at 13:18
  • This is nonsense. The question has been written specifically to cause controversy and the premise is completely flawed. "My developer does 250 x 1 point stories." Sure. If you want to argue about the effectiveness of some patterns there are forums for that. Commented Feb 15, 2019 at 6:44

4 Answers 4


The official answer to the problem is:

There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to.

However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your definition of done?

Assuming a default 40-hour work week and two week sprint length, it would mean that the person took less than 20 minutes per ticket. That already includes the fact that that person took no breaks, no coffee sips, no restroom, not a single meeting for the whole sprint. In reality, it's probably closer to 10-15 minutes per ticket.

With our DoD, I would not be able to close a ticket in 20 minutes. I have to open it, read and understand it, do a checkout of the current code, change it, write tests for the change, prepare the data for the review/demo, commit, push, merge-request and install my code somewhere for review/demo. Even for a single character typo it takes 15-20 minutes just typing, clicking buttons and waiting for the results.

With 250 stories that are that small, I would question whether having story points for them at all is useful. Of your 251 stories in the sprint, 250 are faster done than estimated. Maybe you're better off to organize differently.

Maybe let people work on the stream of seemingly small tickets and only if they hit a particularly large one, that is elevated to a backlog item for the team. What normally happens is that a company has two teams, one for daily operations (aka 250 super small tasks) and one for development that has the focus to work on the big stories.

  • Also: is that big feature really one unit? Might it be better broken into several digestible parts?
    – mattdm
    Commented Feb 14, 2019 at 13:44
  • I could imagine coming up with 250 tasks for, say, 250 points of data to be entered into a database. In that case, the more sensible approach would be to combine them all into a single task and estimate that instead.
    – Llewellyn
    Commented May 9, 2020 at 19:06

Try to divide big user stories to more manageable pieces(less than one day to be done), it can solve your problem. If you increase the user story hardness, the hardness of solving can increase non-linearly, as you can see on your story points.


The basis of relative estimating (which is what story points are used for) is that 1 point always represents roughly the same amount of effort. This must be independent of the size of the task.

This means that a 20 point task must be about 20 times as much effort as a 1 point task (although the actual effort spent can easily vary between 10 times and 40 times as much due to the uncertainties of estimating).

In your example, if a single developer can finish either 250 XXS tasks or one XL task, then the XL task is approximately 250 times as large as a XXS task, not the 20 times that your story point values suggest. This means that either your story point allocation to the t-shirt sizes is incorrect, or that the XL task is grossly underestimated.


Ok, I will give you a better sizing chart. I think the problem is that you set up the wrong system.

Before anything, you have to:

  • educate your team to give technical estimation and
  • take an average for a user story.

Better sizing chart

0                   (-)
1/2                 (<1/2 h)
1                   (1/2 - 1 h)
3                   (1  - 2 h)
5                   (2 - 4 h)
8                   (4 - 8 h)
13                  (8 - 16 h)
20                  (16 - 24 h)
40                  (24 - 40  h)
100                 (40 - 80 h)

Note: team estimate is average of all estimate

  • 6
    A fundamental principle of relative estimation is that it is not tied to time. Any relationship to time is a correlation for that particular team and circumstance.
    – Daniel
    Commented Feb 14, 2019 at 14:36
  • It is in the perfect world true. Dear Daniel, have you ever estimate the price for your customer? This is a framework and you can make some changes for your team, My Dev team always make a great and precise estimate with this sizing chart. Commented Feb 14, 2019 at 15:26
  • 2
    So you have roughly tied story to hours with a conversion factor of 10 story points = 1 hour (give or take). I feel this answer needs a disclaimer of sorts. The general use of story points is not tied directly to time. That's what velocity estimation is for. I wish your answer pointed out that your approach is a special case: the degenerate case where story points and hours are the same.
    – Cort Ammon
    Commented Feb 14, 2019 at 17:20
  • 2
    If they are able to make precise estimates with this sizing chart, why not just use hours? I won't argue that all work needs relative estimation - it doesn't. Some work is known and can be estimated in actual time in which cases it is far simpler to just estimate with real-time units. Story points are used in relative estimation which provides value in complex and unfamiliar work where precise time estimates aren't possible.
    – Daniel
    Commented Feb 14, 2019 at 19:24
  • 1
    This is nonsense and your account must be a parody with that name. Commented Feb 14, 2019 at 22:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.