Structured Story Points: Estimating Engineering Work with Clarity

Editor’s note: This article was originally submitted to InfoQ. It is shared here in its draft form to open up the conversation and gather feedback from the developer community. Where Structured Story Points Came from Before you can improve delivery, you have to trust your estimates. I didn’t set out to create a new estimation system, but during planning sessions I started noticing a pattern. When engineers debated whether a story was a “3” or a “5,” the number rarely mattered, but the context behind the conversation revealed everything. I kept hearing things like: “This isn’t that much code, but it touches three different systems.” “We don’t even know if that API does what we need yet.” “I can knock this out fast, but I’ll need Jack to unblock me.” “Feels simple, but every time we touch that part of the code, something breaks.” These weren’t conversations about time. They were about complexity, uncertainty, and collaboration. We just didn’t have a shared way to talk about them. That’s what led me to formalize what good teams were already doing informally. It started with effort, complexity, and uncertainty. The collaboration dimension came later, after seeing too many stories fall apart because of hidden handoffs or cross-team coordination issues. What began as an effort to make story points more meaningful turned into a simple, repeatable way to size work more clearly. By naming the factors teams were already responding to: effort, complexity, uncertainty, and collaboration, we created a shared way to talk about what affects estimation. Once that language was in place, the numbers started to reflect reality. Why Estimation Breaks Down Estimation doesn’t fall apart because teams don’t care, or even because estimation is hard. It falls apart because most teams are asked to assign a number without any structure for how to reason about the work. Story points were intended to abstract time from estimation and give developers a simple, relative way to size work. For many teams, that simplicity has lost its beauty. The numbers have become disconnected from reality. What started as a helpful tool often turns into a hollow ritual. You start to see it in the little moments: A senior engineer throws out a “2,” and everyone else quietly agrees. A ticket gets marked as a “8” because it feels big, even though no one’s sure why. Someone says “let’s just call it a 3 and move on.” At that point, the team isn’t estimating. They’re guessing, negotiating, or performing. The number doesn’t reflect understanding, and the planning process stops being useful. Structured Story Points takes a different approach. It replaces the guesswork with a simple structure that’s fast to use and easy to adopt. In the next section, I’ll break down the four factors that make the difference. Introducing Structured Story Points Structured Story Points (SSP) is a practical way to bring clarity to estimation by focusing on the parts of the work that actually matter. It doesn’t throw out story points. It gives them structure, so teams can reason together instead of guessing alone. The core idea is simple, every piece of engineering work is shaped by four things: how much effort it takes, how complex it is, how uncertain the requirements are, and how many people need to be involved. SSP turns these into four clear questions that teams answer together. That’s it. No reinventing agile. Just better conversations that lead to better planning. Instead of debating numbers, teams talk through the work itself. That shift helps catch risks earlier, set more realistic expectations, and reduce surprises mid-sprint. It also makes planning faster because everyone’s working from the same reference points. SSP replaces guesswork with evaluation across four real-world factors: The Four Dimensions That Matter SSP replaces guesswork with evaluation across four real-world factors: Effort, Complexity, Uncertainty, and Collaboration. These dimensions aren’t abstract. They reflect the actual forces that shape delivery; the things that make work easy, hard, risky, or unpredictable. Each dimension gives the team a different lens to look through. Together, they create a fuller picture of the work ahead. And it doesn’t take more time, it just makes the conversation more focused. Instead of drifting into solutioning or debating numbers, the team quickly aligns on what matters most. Let’s break them down, starting with the most familiar. 1. Effort How much actual work will this take? Effort measures the focused, hands-on time required to complete the task. This includes writing code, testing, documentation, deployment, anything that involves doing the work directly. It’s about how much energy the task takes to move from start to finish. Minimal: Can be completed in a single short stretch of focused work, with little ramp-up or interruption. Moderate: Requires at least one longer stretch of d

May 27, 2025 - 21:20

Structured Story Points: Estimating Engineering Work with Clarity

Editor’s note: This article was originally submitted to InfoQ. It is shared here in its draft form to open up the conversation and gather feedback from the developer community.

Where Structured Story Points Came from

Before you can improve delivery, you have to trust your estimates.

I didn’t set out to create a new estimation system, but during planning sessions I started noticing a pattern. When engineers debated whether a story was a “3” or a “5,” the number rarely mattered, but the context behind the conversation revealed everything. I kept hearing things like:

“This isn’t that much code, but it touches three different systems.”
“We don’t even know if that API does what we need yet.”
“I can knock this out fast, but I’ll need Jack to unblock me.”
“Feels simple, but every time we touch that part of the code, something breaks.”

These weren’t conversations about time. They were about complexity, uncertainty, and collaboration. We just didn’t have a shared way to talk about them.

That’s what led me to formalize what good teams were already doing informally. It started with effort, complexity, and uncertainty. The collaboration dimension came later, after seeing too many stories fall apart because of hidden handoffs or cross-team coordination issues.

What began as an effort to make story points more meaningful turned into a simple, repeatable way to size work more clearly. By naming the factors teams were already responding to: effort, complexity, uncertainty, and collaboration, we created a shared way to talk about what affects estimation. Once that language was in place, the numbers started to reflect reality.

Why Estimation Breaks Down

Estimation doesn’t fall apart because teams don’t care, or even because estimation is hard. It falls apart because most teams are asked to assign a number without any structure for how to reason about the work.

Story points were intended to abstract time from estimation and give developers a simple, relative way to size work. For many teams, that simplicity has lost its beauty. The numbers have become disconnected from reality. What started as a helpful tool often turns into a hollow ritual.

You start to see it in the little moments:

A senior engineer throws out a “2,” and everyone else quietly agrees.
A ticket gets marked as a “8” because it feels big, even though no one’s sure why.
Someone says “let’s just call it a 3 and move on.”

At that point, the team isn’t estimating. They’re guessing, negotiating, or performing. The number doesn’t reflect understanding, and the planning process stops being useful.

Structured Story Points takes a different approach. It replaces the guesswork with a simple structure that’s fast to use and easy to adopt. In the next section, I’ll break down the four factors that make the difference.

Introducing Structured Story Points

Structured Story Points (SSP) is a practical way to bring clarity to estimation by focusing on the parts of the work that actually matter. It doesn’t throw out story points. It gives them structure, so teams can reason together instead of guessing alone.

The core idea is simple, every piece of engineering work is shaped by four things: how much effort it takes, how complex it is, how uncertain the requirements are, and how many people need to be involved. SSP turns these into four clear questions that teams answer together. That’s it. No reinventing agile. Just better conversations that lead to better planning.

Instead of debating numbers, teams talk through the work itself. That shift helps catch risks earlier, set more realistic expectations, and reduce surprises mid-sprint. It also makes planning faster because everyone’s working from the same reference points.

SSP replaces guesswork with evaluation across four real-world factors:

The Four Dimensions That Matter

SSP replaces guesswork with evaluation across four real-world factors: Effort, Complexity, Uncertainty, and Collaboration. These dimensions aren’t abstract. They reflect the actual forces that shape delivery; the things that make work easy, hard, risky, or unpredictable.

Each dimension gives the team a different lens to look through. Together, they create a fuller picture of the work ahead. And it doesn’t take more time, it just makes the conversation more focused. Instead of drifting into solutioning or debating numbers, the team quickly aligns on what matters most.

Let’s break them down, starting with the most familiar.

1. Effort

How much actual work will this take?

Effort measures the focused, hands-on time required to complete the task. This includes writing code, testing, documentation, deployment, anything that involves doing the work directly. It’s about how much energy the task takes to move from start to finish.

Minimal: Can be completed in a single short stretch of focused work, with little ramp-up or interruption.
Moderate: Requires at least one longer stretch of dedicated work, often more. A solid block of time, but manageable within normal flow.
Painstaking: Demands multiple extended stretches of effort. Often repetitive or tedious, with a lot of doing spread out across days.

2. Complexity

How difficult is the task to reason about?

Complexity measures the cognitive and technical challenge of the work. It reflects how much mental effort is required to understand the task, make sound decisions, and avoid mistakes. This includes logic depth, system interactions, branching conditions, and the risk of unintended consequences. It’s not about how long the task takes to complete, it’s about how hard it is to think through safely.

Simple: The task is easy to reason about. It has few moving parts, clear logic, and low risk of unintended side effects. You can glance at it and know what to do.
Layered: There are multiple concerns to consider at once. The logic might not be complex individually, but understanding how everything fits together requires attention. You have to hold a few layers in your head to do it right.
Convoluted: The task is hard to follow, even for someone familiar with the system. It might involve deeply nested logic, legacy code, unpredictable dependencies, or brittle paths where one wrong move causes regression. You find yourself rereading the code just to understand what it’s doing.

3. Uncertainty

How well do we understand what's being asked?

Uncertainty measures how aligned the team is in interpreting the work. It shows up when requirements leave room for interpretation, when expectations haven’t been confirmed, or when key context is missing. A task might sound clear at first, but if engineering reads the story one way, product expects something else, and the customer imagines a different outcome altogether, that’s uncertainty. It’s about how confident the team is that they’re building the right thing

Clear: The task is well understood. The scope is aligned, the intent is shared, and the team is confident in both what to build and why it matters.
Murky: Some parts are open to interpretation. The team may need to clarify expectations, validate assumptions, or revisit the goal before starting.
Uncharted: There isn’t enough clarity to begin. The task needs exploration or discovery to figure out what’s actually being asked.

4. Collaboration

Who needs to be involved?

Collaboration measures how much coordination is required to complete the task. It captures handoffs, dependencies, and the communication overhead that comes with involving others. Some work can be done solo from start to finish. Other work requires syncing with teammates, waiting on input, or coordinating across teams or organizations. The more people involved, the more friction there is, not because anyone’s slow, but because alignment takes time.

Solo: One person can handle the task independently, without needing outside input.
Paired: The work requires support from a teammate, either for context, review, or shared responsibility.
Cross-team: Involves coordination with another team. Progress depends on aligning priorities and timelines across groups.
External: Requires input or action from someone outside the organization. These tasks often come with delays, added risk, or less control.

What Teams Gain with SSP

Structured Story Points isn’t about estimating faster. It’s about estimating better. SSP helps teams have the right conversations, not just quick ones, and that clarity leads to more accurate sizing. Accuracy drives predictable delivery. And predictable delivery builds trust.

Process Benefits

When estimates are grounded in reality, velocity becomes a meaningful metric. Teams can commit with confidence, adjust based on evidence, and plan without drama. Over time, this consistency leads to a faster pace, not because people are rushing, but because they’re calibrated. Clean sprints become normal. Misses become rare.

Cultural Impact

SSP strengthens the connection between the people doing the work and the people depending on it. When engineers share how they size work, clearly and consistently, it builds trust with stakeholders. Engineering leaders can defend velocity without defending individuals. Conversations shift from “why aren’t we faster” to “what would it take to go faster.” That might mean hiring, reorganizing, or investing in better tools. It’s no longer a question of who’s underperforming.

Estimation isn’t just a technical practice. It’s a cultural one. SSP helps teams deliver with clarity and own their pace in a sustainable way.

Getting Started

The best way to understand Structured Story Points is to put it into practice.

Start by using the four dimensions in your next planning session. Even a quick discussion across effort, complexity, uncertainty, and collaboration can surface misalignment before work begins. Over time, teams tend to find their own rhythm and language around these dimensions, that’s the goal.

If you want a little structure to help guide the conversation, I’ve put together a simple tool that walks teams through the questions and produces a score. You can explore it here:

https://connectedengineeringmethod.com/structured-story-points

Estimation doesn’t need to be perfect. It needs to create shared understanding. That’s what helps teams plan with confidence, deliver consistently, and build trust with the people counting on them.