I've read in several places that story points are not necessarily linear.

i.e., an "8 point" task is not the same as two 4 point tasks and so on.

I totally get the argument about these being an indication of complexity rather than time taken.

But if they're not a linear scale, then how can you do arithmetic on them? If an 8 story point takes, say, 3 times longer than 2 x 4 story points, then how do burndown charts work from an arithmetic point of view?

If our velocity is, say, 30 a sprint then this means we could do 30 x 1 story point features. But these might be, 30 half an hour jobs. Equally if it was 2 x 15 story point features, these are probably monster tasks which seems equally unlikely.

Perhaps I am wrong in my assertion that they are non-linear?

Or can anyone explain this to me?


  • 1
    I would recommend that you read Mike Cohn's book on User Stories: mountaingoatsoftware.com/books/user-stories-applied this will give you a good understanding of what user stories and story points represent.
    – user32613
    Dec 10, 2018 at 11:30
  • You mean «"8 point" story». Dec 10, 2018 at 19:20
  • I afraid adding non-linear numbers would not allow to use additions to compute sprint size. It will make no any sense.
    – k06a
    Jan 24, 2022 at 14:27

4 Answers 4


Perhaps a more accurate way to put it would be that story point estimates are imprecise. If you have a 5 and a 3, that may or may not be the same size as an 8.

To make this less confusing, let's start with a non-numeric scale like T-Shirt sizes. XS, S, M, L, XL and so on. We can agree pretty easily that a small and a medium t-shirt do not get you a large t-shirt. Yet, a large is bigger than a medium and a lot bigger than a small, and generally smaller than an XL. Not always, of course. We all know that one company that we have to buy a different size in. User stories are the same way. It's possible I have a M that is actually bigger than some L, but this is the exception, so I can normally assume that a L is one step bigger than an M.

OK, now let's do this: XS-1, S-3, M-5, L-8, XL-13. Now, all of the same rules apply. It is possible in some edge cases that a 5 is actually bigger than some 8, but generally speaking an 8 is one step bigger than a 5.

Then there is the topic of velocity. Because the relationship between the sizes is generally consistent, we can add the sizes together and if we work at a consistent pace we will have a fairly consistent total. It won't be perfect - maybe 45 - 52, but that is consistent enough to be useful for planning. If you have 35 points in the sprint, it is probably too little in this case and 60 is almost certainly too much. This is also why most forecasts are a range, not a precise measurement.

  • 1
    OK. I think I understand. But in our mental-models we should be aiming for linear scale right? I mean, we know things are imprecise, but in an ideal world they would be perfectly linear? It would be wrong for a team to say "We believe that an 8 is 3 times larger than a 5" for example?
    – John
    Dec 10, 2018 at 11:52
  • Think of it the other direction. Think of it like a non-numeric scale. S-M-L are not strictly linear. It is more like that. The only reason to use numbers at all is that with enough data points it becomes consistent enough to be able to track velocity. Your team should think an 8 is two steps bigger than a 3, one step bigger than a 5. you can't divide them into each other.
    – Daniel
    Dec 10, 2018 at 13:01
  • I get it. I just don't understand how you can do things like burn downs, or measure velocity if they're not linear AND assignable to a number. Let's say that last sprint I did "5 x L, 3 x M and 6 x S". How can I estimate my velocity when I'm doing the next sprint which consists of "15 x M". It's comparing apples and oranges, right?
    – John
    Dec 10, 2018 at 16:58
  • 1
    @John it's always going to be comparing apples and oranges because (generally speaking) no two tasks are going to be the same. The idea behind the numbers is to get to a quick "gut check". Daniel mentions it at the end - "consistent enough to be useful for planning". You're not trying to make a precise statement "We will definitely do 15 x M next sprint", you're trying to put some science and proof behind the statement "We can do 15 x M next sprint" ie "The team is setting an attainable milestone"
    – Vlad274
    Dec 10, 2018 at 21:45
  • This is one of the things that #noestimates is all about. Once your team is experienced enough, you can move to just using shirt sizes (which only serve as a guide to see if a story needs breaking down, i.e. everything over a medium needs splitting). This excellent presentation from Allen Holub illustrates the point nicely, it's well worth the watch youtube.com/watch?v=QVBlnCTu9Ms Dec 11, 2018 at 11:19


Some story point systems do use linear values, but such systems are rarely used by experienced agile practitioners as the numbers are usually misleading. Non-linear systems deliberately expose the imprecision of the estimation process, and rely on smoothing functions to arrive at reasonable planning values for team capacity.

Understanding Relative-Effort Values

In common usage, linear means “sequential.” (NB: there are mathematical and scientific definitions that are more complex.) However, most story-pointing systems are not sequential.

The most common story-pointing system is arguably Mike Cohn’s modified Fibonacci sequence, where each value is a non-linear function of preceding values. The core idea is to have a reference story equal to one or two story points, and then to size all stories relative to the reference story.

Central to story pointing is:

  1. The notion that they represent effort or complexity, not time.
  2. An acknowledgment that estimation becomes less precise as stories get larger.

An 8-point story is therefore somewhere between 4..8 times the effort of the reference story, and roughly falls between 5..13 on the point scale. Any attempt to treat one 8-point story as exactly equivalent to eight one-point stories misses a core principle of the system, which is that estimates are imprecise by nature and get more so as the size (and therefore the cone of uncertainty) of a story increases.

Story point metrics like velocity can provide a range of values for expected team capacity during Sprint Planning, especially when using a smoothing function like a trailing average. Attempting to wring high precision out of the velocity metric, or treating story points as linear time values, would be a misuse of the methodology. This is a common anti-pattern, so just don’t do it.


I have never heard of this. Story points are linear (otherwise it would be impossible to use them as a measure of velocity). However the scale is non-linear, to stop people arguing over whether something is a "5 or a 6" - by using a psuedo-fibonacci sequence, you automatically account for the vagueness of estimation.

  • 1
    This makes more sense to me. I think that maybe people have conflated the non-linear choice of numbers (the Fibonacci system) with having the numbers themselves be non linear
    – John
    Dec 10, 2018 at 11:48
  • To me, as with most things in the world of project planning, "story points" and "velocity" are useful ideas "up to a point," but ... "reality always gets in the way." Therefore, I think of story-points as "marks which you need to hit." I prefer to select the number and mix of points that the team will strive to hit, and then measure the percentage of points that they actually do hit. Story points aren't the same and therefore are only loosely comparable. Therefore, "velocity" will naturally vary from sprint to sprint even when the same "amount of work" gets "done." May 18, 2020 at 14:35

So... here is what I used to teach when I talked about Story Points in my CSM classes (I don’t talk about it in my CSMs anymore, unless under request). An estimate with story points carry a “confidence interval” around it - which means, its level of precision. And that’s THE reason why we use Fibonacci numbers. You see, we can imagine the estimate is actually between the number before and the number after. The bigger the number, the lower its precision, because the interval increases.

Remember Fibonacci sequence: 0, 1, 1, 2, 3, 5, 8, 13, 21... right? So, an estimate of 3 points means we believe (implicitly) it will be between 1 and 5. But an estimate of 13 means we believe it will be between 8 and 21. See the larger interval there, and therefore the lower precision?

Therefore, one story of 13 points (implicitly from 8 to 21) won’t necessary be sliced into stories that add up to 13 points.

Another factor is, when the team slices a story with a greater estimate into smaller stories, it is because they have learned more about it. It could, for example, mean that the uncertainty around each of the slices has been reduced and thus, it also has reduced the uncertainty around the set of sliced stories together. Or the team could have found out there is something else they hadn’t thought about. And that will of course affect the sum of the estimates.

  • Just for clarity, you don't teach it that way anymore or you don't teach CSMs anymore?
    – Daniel
    May 16, 2020 at 2:05
  • I don’t talk about Story Points in my CSMs anymore, unless requested. Thanks, just edited it. :) May 17, 2020 at 4:55
  • I've never really cared for things like "Fibonacci" because frankly "using numbers and math" can give the mistaken impression that the math is useful and that the things we're counting are "countable." I'm always nervous about making projections or reports to management that I consider might be misleading. Or, that might cast the team in a needlessly bad light. May 18, 2020 at 14:38
  • oh, don’t get me wrong. Neither do I care about Fibonacci... nor I care about estimates. We just slice it very thin and that’s good enough. Anything more than that is pure guess or, worse, BDUF. I just hope that people who still use estimates do it in a less harmful way. And, with time, evolve and drop it. One step at a time. :) May 18, 2020 at 18:21

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.