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

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.