# If higher story points represent exponentialy more effort why are they allocated linearly?

This is a standard confusion I've always had with the concept of story points. I've always been told that the complexity of story points should go up roughly exponentially. Essentially a task pointed at 5 should be more then 5 times as complex as a task pointed at 1.

However, when tasks are assigned the discussion of story points assigned to a developer often seem to treat the story points as if they are linear. For instance when deciding who to assign a new 5 point ticket to I've had managers say they should assign it to whoever has the fewest points without further consideration. I've also had managers who stated they expected a specific number of points to be completed by each developer per sprint. These approaches, that look at total points assigned only, don't seem to consider the exponential increase in complexity higher pointed tickets may represent.

For example if I was assigned 21 1 point tickets I could theoretically complete them all in a week, but I would never be able to complete a 21 point ticket in a single week. A manager setting an expectation of developers completing 21 points in a sprint because he saw me doing 21 1 point tickets would be setting an unmanageable expectation to my colleague who is assigned the 21 point ticket.

With my favorite teams this was not too much of a problem, we recognized the difference and would assign more points to someone who had small 1 & 2 point tickets, and try to avoid much tasking to anyone taking larger pointed tickets, but these were smaller teams managed by the actual developers with little management oversight and generally a more flexible (one may even say agile) approach to tasking in general, we used Jira to assist our team in assigning tickets and tracking tasks but not for metrics, velocity, or any of those concepts.

On teams where management was trying to collect statistics, velocity, etc from jira and tried to force a more rigorous approach to story pointing I've always felt that the points were inaccurately utilized. In the worst case I've seen management expressing dissatisfaction for members who didn't meet a sufficient number of story points in a sprint without considering the type of tickets assigned to the developer, which penalized taking high pointed tickets and encouraged taking quick bug fix tasks to pad out number of story point's completed.

What is the 'proper' approach for handling story points from a management perspective? Can work assigned to a developer be measured by total points assigned in a meaningful manner? How does one avoid penalizing developers who take more complex tickets?

• I've never heard that story points should be interpreted exponential. Do you have a source for this? Commented Jun 26, 2018 at 16:00
• Scrum uses fibonacci sequence when assigning, so they can force allocating points in larger chunks while still interpreting linearly (with points having equal value). Commented Jun 26, 2018 at 16:10
• Points are for your team, not management. Velocity is a barometer of relative health, not an accurate measure of productivity. Commented Jun 26, 2018 at 18:14
• @joshp, some scrums use powers of 2, but it's the same principle. The only difference is that instead of 1, 2, 3, 5, 8 you have 1, 2, 4, 8, 16. I think most people find the Fibonacci series a better spread of point values. Commented Jun 26, 2018 at 19:56
• @BerinLoritsch Sure. I think Fibonacci was the original approach. But either way, the idea is to interpret the resulting numbers as 'linear' in OP's terminology, and the extra weight, or risk consideration is baked in when the numbers are assigned. Commented Jun 26, 2018 at 20:14

I've always been told that the complexity of story points should go up roughly exponentially.

Yes, that's generally why story points are Fibonacci'd (1,2,3,5,8,13,21) - an 8 isn't twice as hard as a 5, it's a little harder. But instead of a 6, we assume that bigger work is more risky. It's more likely to blow up into something that takes a lot more time/effort, so it's an 8 to account for that estimate risk.

Essentially a task pointed at 5 should be more then 5 times as complex as a task pointed at 1.

No. A 5 should on average take as much effort as 5 1's. Again, I say on average, because a good portion of points for big stories is risk. Sometimes a 5 will take less effort because everything went well. Sometimes a 5 will take more effort because unknowns turned into problems. That's partly why velocity only makes sense measured over time.

But more importantly, complexity in software doesn't correlate linearly to effort. If you double the complexity of the software, the effort will worse than double.

What is the 'proper' approach for handling story points from a management perspective?

Story points are at best a rough estimate. As a manager, if you see your scrum team commit to 2x their usual story points, maybe you should not expect that sprint to be successful. If you see their velocity slide downwards over 6 months, you might consider some morale issues or technical debt has accumulated (or other organizational drag).

Can work assigned to a developer be measured by total points assigned in a meaningful manner?

No. Because points are not the work. Different developers have different strengths and weaknesses. Different developers are at different points in their careers. Different developers work at different rates. Boiling that all down into one uniform number and trying to manage by spreadsheet is (widely practiced) ineptitude.

• And to expand on the comment about not measuring developer output using story points, if your makes a habit of breaking stories into concrete developer tasks, you could end up with two or more developers working on a story. Related buzzword: Swarming. How can you possibly attribute story points to an individual's output? You can't. Commented Jun 26, 2018 at 23:38

All the estimates, no matter how you make them, will automagically include all three components:

• effort (just work)
• risk (that you will break something), and
• uncertainty (unsure how much we have to learn)

Bigger numbers tend to indicate that the last two are greater factors than the first. Sometimes a one-line change is super uncertain and risky. Sometimes a 100-line change is trivial.

I think of a one-point story as one die worth of work -- where the dot on the die is some time period (maybe 90 minutes, maybe 25, maybe 1/2 day).

A two-point story has a two-dice spread: between 2 and 12 time periods.

A five-point story has a five-dice spread -- most likely between 5 periods and 30 periods.

The analogy is to help us think of variability. A 21-point story has absurdly high variability, and maybe we should not do it at all if predictability is important to us. We need to break it down into spikes and small stories which have lower variability.

This is why a lot of organizations have gone past story points and instead break all stories down to be low-variability to begin with; this way they are more predictable and can deliver more continuously.

It is the basis of many new trends in software development.

You can do your own measurements and see variability by story points. It sounds like you've already reached the same conclusion intuitively. Then, maybe adjusting the story point scale isn't the best answer.

Peace, Tim

• It is unfortunate that these techniques boil everything down to a single number. A larger task can become lower risk if someone does some research or prototyping prior to the grunt work. Commented Jun 26, 2018 at 16:45
• @FrankHileman Using a scalar for estimates is indeed a sub-optimal practice. Any proper estimate needs at least two things: an expected value and a measure of precision. When we limit to one number the precision gets lost so we can have an estimate for something routine and an estimate for something exotic and new that are the same value. These are wildly different estimates but call them the same thing. Typically what people do is increase their estimate in these scenarios which is a poor solution. You can't blame them though when no alternative is available. Commented Jun 26, 2018 at 17:19
• I'm not sure if using dice is a good analogy here - one die is more random than ten dice. One die has equal chance of getting a 1 or 6 (a 500% increase), but 10 dice will almost certainly end up between 25 and 45 (less than a 100% increase)
– Erik
Commented Jun 27, 2018 at 8:04

What is the 'proper' approach for handling story points from a management perspective?

Managers shouldn't know about points, and points should never be used to measure the performance of an individual.

The points are a tool for the development team, and development teams don't have managers. A Product Owner will know about the points, but they should be communicating with managers in something even less precise than points (typically, in the number of sprints before the work will be ready).

The numerical value of the point is meaningless, and only exists because humans are used to quantifying things with numbers.

The reason for story points is to provide a rough, relative estimation, nothing more. The actual value is irrelevant. The fact that the number 3 is three times larger than the number 1 has no relevance in story points. A three simply means that it's more complex than a 1, and has a larger amount of uncertainty. Is it three times as much? Two times? 5 times? It doesn't matter. All that matters is that we know it's more effort, with more uncertainty.

One of the best explanations I've heard is that point values are simply buckets. If you have a pint bucket and a quart bucket and a gallon bucket, where do you put something that is slightly more than a quart? You put it in the gallon, not because it is four times as much as a quart, but because it's simply bigger than a quart.

Can work assigned to a developer be measured by total points assigned in a meaningful manner?

No. For one, scrum has no concept of assigning work. Points shouldn't be used as a measurement of the performance of an individual.

How does one avoid penalizing developers who take more complex tickets?

You avoid that by not baseing there performance review on points. Period.

Points are strictly a measurement tool for a team as a whole, not an individual.

I think there is some misunderstanding.

A task takes time from start to completion. And once it is completed it takes more time because the spec wasn’t quite right, or there are bugs, or anything else that causes extra work.

For a one point task the extra work happens long after you thought the task was completed. So you have one unit of work planned, and two days later there is another unit of work that just falls through the cracks.

For the 21 point task, the extra work becomes visible before the point where you think the task completed. So you account for the extra work within the task. The task takes twice as much time as you thought. Just like the one point task. The only difference is that you see the extra time spent. So for one-point stories, your view of the total time is more distorted.