How to convert (volume of work, risk, complexity, uncertainty) to story points?

Question

Disclaimer: I'm a developer, so I don't claim to be thoroughly knowledgeable of agile practices, thus I may not always use the correct words and terms. Please correct me if needed.

Agile teams often use the "story points" metric for estimating a task's effort. However, I noticed that I don't feel entirely comfortable giving a "story point" estimate, because it seems too speculative. Instead, I prefer first to disaggregate the story points into volume-of-work, risk, complexity and uncertainty (e.g. as mentioned here) and then to combine these four into a "story point" estimate. Unfortunately, I don't have a clear-cut way of doing this (simple average seems too... simple), so I came up with a bunch of questions:

• is there a "theoretical" approach to aggregating these four metrics into story points? If yes, what is it?
• if you describe a task's effort with these four metrics, how do you then combine them into story points?
• in your practice, do you use the aforementioned disaggregation? Why or why not?

Answer 1

in your practice, do you use the aforementioned disaggregation? Why or why not?

I encourage teams to focus on estimating consistency rather than on having a complicated estimating approach.

There are a number of reasons for this, including:

• Complicated estimates encourage people to believe that their estimates are more accurate and when they prove to be wrong the consequences may then be worse
• A simpler estimating process is quicker and so less time is wasted - this time can be spent on building the product
• Needing a complicated estimating method is an indication that the stories being estimated are too big and too complex - look to reduce story size and to use spikes to reduce lack of understanding

Answer 2

Relative estimates (points) are useful because they tend to give a better approximation than absolute estimates and tend to be easier to work with. Points are just an approximation however, and they make most sense when looked at in aggregate and over a period of time. I wonder if you are making too much of the details. Some suggestions below.

I certainly do take account of all the factors you mentioned but I tend to do it by relative comparison to previously completed stories ("this one is about as big/difficult/uncertain as this one"). Having a few familiar "baseline" stories in mind for comparison makes the estimation much easier.

Use Fibonacci or a modified Fibonacci series for estimates. For the bigger stories you don't need to be so precise because the intervals between the numbers are large. For smaller stories a point or two either way hardly matters.

Estimate as a team (wideband delphi / planning poker) and aim for a consensus. The team's estimates act as a sense check for each other. Teams tend to arrive at a common understanding of what point sizes mean.

Estimates really only have to be accurate enough for you to decide whether a story will fit into a sprint or whether it needs splitting.

Answer 3

Actually "story points" is exactly for not doing what you are trying to do :) The idea behind it is this;

1. Estimations aren't accurate. Here's an article of mine about this.
2. Trying to estimate takes a lot of effort.

There's a misunderstanding that, every story point should match with an effort-based metric like hours, minutes, days, etc. That's wrong. "3" story point can take 5 hours to complete this sprint, but the same point can take 2 hours to complete the next sprint.

All we try to do is to try to size the stories according to each other, relatively. We trust our senses and say "Hey, If ISSUE-1234 is 3, then ISSUE-4321 should definitely be 8!"; that's it.

Answer 4

I don't think there's a mathematical function to take in effort, risk, complexity, and uncertainty in order to return a single value in story points. I also don't think that approach makes sense.

One way to think about it is to reduce the factors. Uncertainty is one form of risk, so you don't need to identify both. At worst, you'd look at three factors - effort, risk, and complexity. I also suspect that there's often (but not necessarily) a relationship between effort and complexity since complex work takes more effort to make sure that everything is right. We can work with three factors, though.

I believe that underestimating work is far worse than overestimating, so an increase in any of the three factors results in an increase in story points. If I look at the description and I think it's about a 5 to account for effort, but there are still a few open questions that may impact the work, then it goes to an 8. If there are known risks that haven't been mitigated, it could go up to a 13 or 20. It will take work (effort) to work through questions to get answers or to mitigate risks, so this conceptually makes sense. The amount to increase depends on how many questions, how much work it will take to answer those questions, and how many unmitigated risks there are.

However, if there are too many open questions or too many unmitigated risks, the item should go back in the Product Backlog and not be considered ready for selection in a Sprint. If you're using Scrum, there's a minimum state that is necessary for a Product Backlog Item to be selected for a Sprint - the team believes that they can complete the work described within a single Sprint. If the team is uncertain if they can bring in the item and answer all of the unanswered questions or handle any risks that are likely to emerge by taking on the work, it needs more refinement. Refinement can be used to answer those questions or mitigate those risks.

In the end, though, there's a single value for the estimate of the work. This is true for story points, ideal hours, or any other way of measuring. The team is making a statement about the effort needed to complete the work.

Answer 5

Story Points are not based on any kind of tangible formula, and they are not the point of estimation.

During Sprint Planning, the team must agree on the work that is to be included in the Sprint Backlog. This is based on two things:

1. What items the Product Owner has put at the top of the Product Backlog, meaning they are the highest priority to complete; and

2. How much work the Developers believe they can comfortably deliver within the Sprint.

Resolving 1 comes from the PO talking with stakeholders and understanding what will deliver the greatest value. Resolving 2 comes from the Developers understanding their own capacity and capability.

Story Points are a tool to make that understanding easier by providing a point of comparison between work the team has already done and work that's still on the Backlog. They do not translate exactly to measures of time or effort, and they are much more useful in aggregate - two members of the team might disagree on whether a PBI is 1 or 2 Story Points, but they're more likely to agree on whether a collection of PBIs is 40 or 80 Story Points (and more importantly, they're likely to agree on whether the latter is too ambitious for a Sprint).

As such, Story Points will always be speculative, and they'll always be measured relative to other PBIs, and they will always be subjective, but hopefully there will be general consensus in the team about how many PBIs can fit into the Sprint before it starts looking shaky. If there isn't consensus, then you don't need a more accurate measure of the scale of work, you need to put effort into understanding and resolving the differences (e.g. by having a discussion to unravel some of the complexity, breaking off parts with higher uncertainty, using practices like pair programming to share knowledge within the team, etc).

To use an analogy, if I want to copy 1000 files of varying size from one server to another via multiple paths then I don't necessarily need to know that one file is 1.44 MB and another is 1.43 MB, but it might help to know that the biggest file is about 1 TB and the smallest is about 1 MB. I also don't need to know that the 1 MB file takes exactly 0.5 s to transfer on connection A but 0.6 s on connection B, but I probably do want to know the total bandwidth is around 20 Mbps. And even better if I can set up the file transfer in blocks so I don't accidentally try sending the 1 TB file through the slowest connection and have to wait for it to finish long after everything else is already transferred.

Answer 6

What you are feeling is normal whenever a new team starts off or you enter a team freshly.

The current (2020) version of the Scrum Guide does not even mention story points or effort anymore; the closest it gets to this topic is a short blurb in the Sprint Planning section:

Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

IIRC, this was different in the past. When I did my Scrum Master certification many years ago, there definitely was some talk about story points, we got our Planning Poker cards and much was talked about how to achieve an actual number for each story. I do remember that much importance was placed on the fact that the story points are not to be directly scaled to effort (i.e., time or money), but it was unclear what they are, then.

In every Scrum or otherwise Agile (i.e., kanban, scrumban, zombie-scrum, scrum-but, ...) project I ever was involved in, the teams used another methodology and scale for the effort for each story. T-Shirt sizes, fibonacci numbers, etc. There is no magic behind this. For me, the only significance of the fibonacci numbers is that they reduce the amount of numbers to pick, i.e. removes discussions of whether the story is "worth" 11 or 12 points, while being a little more granular than straight exponential numbers 2, 4, 8, 16, 32...

At the end of the day, it does not matter. After a few sprints, each team member has a mental image of what the numbers mean. In one of my current projects, we think that 13 or 15 points is roughly the amount of work one member can do per sprint; we avoid having any stories with more than 8 points (if we think they are larger, we split them down into several smaller ones). In other projects we use S, M, L, XL with no particular mapping to actual time.

The Agile Manifesto mentions effort, time, money or story points not at all and also may serve as an inspiration why this may be so in an agile context.

There is no particularly useful way to convert story points to the other dimensions you mention (volume, risk, complexity...), it is perfectly fine to leave it slightly nebulous. If your PO or someone else happens to be a PL in disguise, he is free to divide the cost of the team in man-hours/money by the velocity to arrive at a €/point rate if it makes them happy, but these kinds of discussions better not take place where any of the team members hear it as it only confuses matter and is a step back to the "good old" pre-agile times.

TLDR: by experience, a team expresses the difficulty or complexity of a task with story points. A possible point of having story points is to get a rough measure of whether a sprint backlog is reasonable given the capacity in that sprint; and for the team to communicate these things back to the product owner without bogging anyone down with time or money. It's not that important, considering the official Scrum Guide has all but removed them altogether from its central pamphlet and the Agile Manifesto and other more pure agile schemes try hard to get these things out of the process.

Answer 7

I noticed that I don't feel entirely comfortable giving a "story point" estimate, because it seems too speculative.

I agree with the other answers, but I thought I'd offer a slightly different take. Based on the above quote, the issue isn't story points, it is your discomfort with offering an estimate without a firm mathematical model.

But story points are intended to do two things

1. Make the team self-accountable.
2. Shift the effort away from defensive strategy to an honest assessment of the work and impediments involved. If you ask a team to estimate based on a mathematical model, the incentive is to offer extremely conservative, unrealistic estimates to avoid external accountability for factors beyond their control. If you ask a team to estimate based on self-acountability and outcomes (story points) you're going to get a better estimate, based on their expertise.

The great temptation of the PM is to confuse our job of estimating duration with the ability to control duration. We have to rely on the team to estimate duration and to perform to that estimate. We like mathematical models and firm foundations; teams tend to prefer exactly the opposite.