SDP Estimate
Ask ten developers what a story point means and you’ll get eleven different answers. Some say it’s time. Some say complexity. Some say it’s a feeling. This definitional fuzziness is the root cause of most estimation problems — not the tool, not the team, not the process.
If story points mean different things to different people on the same team, you’re not measuring the same thing. You’re averaging incompatible mental models and calling it consensus.
Here’s a framework that fixes the definitional problem: estimate across four explicit dimensions before arriving at a final number.
Why Single-Number Estimation Fails
The appeal of a single story point is its simplicity. One number per ticket, multiply by velocity, you have a rough sprint forecast. Clean and fast.
The problem is that a single number can’t distinguish between two fundamentally different types of hard tickets:
- A ticket that requires a lot of work but is completely understood (high effort, low uncertainty)
- A ticket that touches four systems you’ve never seen before but only needs a few lines changed (low effort, high uncertainty)
Both might score as a “5,” but they carry completely different risks. The first ticket will probably take what you estimate. The second might double or triple. When you treat them the same, you get sprint burndowns that look like they fell off a cliff.
The Four Dimensions
Effort
Effort is the most straightforward dimension: how much time and resources does this ticket realistically require?
This is the dimension most people think they’re estimating when they estimate story points. But even here there’s a useful distinction: raw effort (how many hours of focused work) versus coordination effort (how many people need to be involved, how many review cycles, how many meetings).
A ticket that requires one engineer for three days is different from a ticket that requires one engineer for three days plus three other teams to review and approve. Both might be “high effort” but the coordination-heavy one is far more unpredictable.
High effort signals: large scope, many files or systems touched, significant new code required, complex data migrations.
Low effort signals: configuration changes, well-understood bug fixes, copy changes, small additions to existing patterns.
Risk
Risk is about what external factors could make this ticket harder or more damaging than expected.
Technical debt, third-party dependencies, shared infrastructure, external API reliability, upcoming deadlines, compliance requirements — these are all risk factors that can take a “simple” ticket and turn it into a multi-week incident.
Risk is worth estimating separately because it often isn’t visible in the description. A one-line change to a payment service is low effort and low complexity. It’s potentially high risk. Conflating risk with complexity is how critical systems get treated like routine work.
High risk signals: touching payment or auth code, modifying shared infrastructure, depending on external services, working near a release cutoff, making irreversible changes (data migrations, schema changes).
Low risk signals: isolated changes, good test coverage, well-understood systems, reversible operations.
Complexity
Complexity is about how hard this is to understand — both technically and from a domain perspective.
A ticket is technically complex if the code it touches is intricate, has many edge cases, uses unfamiliar patterns, or requires deep knowledge of the system architecture to navigate safely. A ticket is domain complex if understanding what it’s supposed to do requires significant business context that not everyone on the team has.
Teams often confuse complexity with effort. A ticket can be complex but fast (one line in a deeply nested algorithm) or simple but slow (tedious data migration with a clear, mechanical process). Keeping these separate surfaces tickets that look straightforward in a planning meeting but create bugs in production because the complexity wasn’t acknowledged.
High complexity signals: touching core business logic, algorithms or data structures, legacy code without documentation, cross-cutting concerns (caching, logging, authorization), domain-specific rules that require business knowledge.
Low complexity signals: UI changes following established patterns, adding endpoints matching existing ones, CRUD operations on simple entities, well-documented integrations.
Uncertainty
Uncertainty is perhaps the most important and most underestimated dimension. It measures how much you don’t know about the ticket.
Uncertainty comes from several sources. Requirements uncertainty: is the acceptance criteria clear, or will you need multiple clarification rounds? Technical uncertainty: has the team worked in this part of the codebase? Does anyone know how this service behaves at scale? Process uncertainty: do you know how this will be tested, deployed, and rolled back if something goes wrong?
High uncertainty is a sprint killer. A ticket with high uncertainty almost always expands. Not because the work is large, but because you spend half your time figuring out what the work even is.
High uncertainty signals: vague or incomplete requirements, untouched legacy code, new technologies or frameworks, unclear acceptance criteria, no one on the team knows this area.
Low uncertainty signals: requirements are detailed and stable, team has recent experience here, clear definition of done, existing tests to validate against.
How to Run a Structured Estimation Session
Step 1: Read the ticket silently. No discussion. Everyone reads the description and forms an initial impression independently.
Step 2: Vote on each dimension simultaneously. Use a three-point scale: low / medium / high (or 1/3/5 if you prefer numbers). Reveal all votes at once for each dimension before discussing.
Step 3: Discuss disagreements, not agreements. If everyone scored Risk as low, move on. If votes are split, that split is the valuable part — it means different team members have different information about the risk. Surface that information.
Step 4: Derive the final story point from the dimensions. The exact formula doesn’t matter as much as having one. A simple approach: the overall score is dominated by whichever dimension is highest. A ticket with high uncertainty is a big ticket regardless of how low the effort is.
What Changes When You Do This
The most immediate change is that estimation meetings become more specific. “I scored Uncertainty as high because I’ve never touched the billing module and I don’t know how it handles partial payments” is much more actionable than “I think it’s a 13.”
The second change is that your sprint planning gets more honest. When you see a ticket with high risk and high uncertainty sitting next to a high-effort ticket, you can make an informed decision about which to take first. You might choose to spike the high-uncertainty one before committing it to a sprint.
The third change is harder to quantify: the team gets better at estimation over time because they’re practicing specific reasoning skills rather than gut-feel number generation. After a few months, team members start naturally thinking in dimensions even before the meeting.
A Note on Velocity
If you switch to multi-dimensional estimation, your historical velocity numbers won’t apply directly. That’s fine. Velocity is a lagging indicator anyway — useful for rough planning, dangerous when treated as a commitment.
What multi-dimensional estimation gives you instead is a leading indicator: a structured view of where your sprint risk is concentrated. That’s more useful than knowing your average throughput.
Estimate well. Ship fewer surprises.