A few weeks ago my post “Scrum is dying, story points are stupid, and true agility lives on” stirred the pot by calling out the dysfunctions of story point estimation and the waning relevance of Scrum. If you read that and thought, “Great, but my team is still not ready to move off of story points… now what?”, this follow up is for you. Keep in mind, this isn't about saving story points forever. It's about deconstructing them to expose why you might not need them at all, while setting up a smoother path to tool configs and alternatives down the line.
In a nutshell: If story points drive you crazy but you can’t escape them yet, you can deconstruct them. By breaking a story point down into its key components, (Time, Complexity, and Risk) you make the best of a complex situation. This approach keeps the spirit of agility alive (focusing on communication and adaptability) while working within the story point system your organization relies on. Over time, as teams see the value in these explicit components, organizations might realize story points aren't necessary above the team level, paving the way for ditching them entirely.
Recap: Why I Said “Story Points are Stupid”
In “Scrum is dying, story points are stupid…” I discussed how story points often create more confusion and unhealthy behavior than actual agility. Teams and managers start treating velocity (total points completed in a sprint) as a goal in itself, chasing higher numbers as if more points = more productivity. As we saw, this leads to obsessing over numbers and prescription frameworks instead of true agility and value.
Story points were meant to protect teams from the old “How many hours will this take?” game. But, ironically, that’s exactly where they ended up failing:
Miscommunication: One thinks story points mean complexity, effort and risk; another might think they map to hours. Everyone’s speaking a different language using the same numbers.
Velocity comparison obsession: Leadership expects velocity to continuously increase (“You did 50 points last sprint, another team did 80… Why can’t you?”). Suddenly velocity feels like a pressure lever, not a planning aid.
Loss of reality: A story point was supposed to be an abstract unit, but people inevitably map points back to time (“Is 1 point a day or an hour?”) or compare team velocities, defeating the purpose entirely.
If this sounds familiar, you’re not alone. Story points, as I argued, have turned into a poor proxy for what we really care about: understanding the work and delivering value. With that comes questions that really do need answers sometimes. Like how much is this going to cost us and when can we expect to have it in customer hands so we can weigh the ROI of building it vs the revenue we expect it to add, and factor in any cost of delay that could impact ROI.
The Real Questions Behind Misusing Story Points
It’s easy to dismiss bad estimation practices but the reality is that most teams misusing story points aren’t doing so intentionally. They’re trying to answer legitimate questions, just with ambiguous data. Story points get misused because they look like a one size fits all solution to big, important problems without education and experience:
“When will it be done?”
Teams convert total story points into timelines using average velocity. Story points aren’t time based, so this shortcut gives a false sense of reliability and leads to disappointing forecasts, especially in the context of a sprint. And don’t even get me started on whether to split a story incomplete in a sprint or carry it over topic, we’ll save that for another blog post.
“How productive is the team?”
Velocity becomes a measured indicator of productivity, but story point totals fluctuate due to factors like scope, team changes, unknown dependencies and complexity. They don’t capture real value delivered or explain the real effort that went in, especially when they are set before you know exactly what it took to complete the work.
“How can I get better performance out of teams?”
Leaders compare story point totals between teams. But points are relative… 40 points for Team A doesn’t match 40 for Team B. This comparison pressures teams to inflate estimates and erodes trust. Performance ends up being an output measurement that can be easily gamed given the ambiguity.
These are all fair questions… predictability, progress, performance are valid concerns. But story points aren’t designed to answer them well. That’s why deconstructing story points into Time, Complexity, and Risk becomes powerful because it lets you address each concern honestly and clearly, rather than hiding behind a fuzzy number. Story points aren't actionable due to their ambiguity, but these dimensions are, providing context that supports better decisions. Even if factors bleed into each other a bit, that's fine; it adds richness, and each remains actionable on its own.
If you aren’t ready to move away from story points… yet
You might be stuck with story points because of Jira, management expectations, or existing processes require much overhead to remove them. That doesn’t mean you have to let them drive dysfunction. Instead, you can reclaim agility by deconstructing story points into their meaningful components.
Think of a story point as a black box containing three things:
How much work it is: the actual time or effort required.
How hard it is: the complexity or difficulty.
How unknown it is: the risks or uncertainties.
Typically, when your team throws out a point estimate (“This story is 5 points”), each person might subconsciously be mixing those factors. One person’s “5” might mean “medium effort, low complexity, some risks,” while another’s “5” could mean “lots of work hours but straightforward, no risk.” No wonder we often disagree on estimates! By deconstructing a story point, we instead discuss each factor explicitly. That brings us to the three dimensions: Time, Complexity, and Risk. We're not inventing these, we're making them explicit to fix common blind spots, like when estimates happen solo or vary by who's in the room.
Time, Complexity, Risk: The Three Dimensions of Estimation
Rather than tossing around a single number and hoping it magically conveys all aspects of the work, break it down into what you actually mean. When you look at work, consider three separate questions:
Time (Effort): How much actual work time do we think this work will require? This is essentially the volume of work, a rough idea of ideal days or hours in a perfect scenario. It’s a gut feel for size/length, independent of complexity.
Complexity: How hard is the work? This captures the intrinsic difficulty, algorithmic complexity, technical challenges, integration difficulty, etc. A highly complex story might require specialized skills or novel solutions, even if it isn’t huge in scope.
Risk (Uncertainty): How unknown is the work? Is there low confidence in a deadline that needs to be met? This dimension covers ambiguity in requirements, unknown technical areas, and potential risks or blockers that could derail progress. To make it less vague, try specifying risks more concretely, like listing how many risks to drive your calculation and discussions (example: two known blockers: unclear API docs and potential dependency delay). This could even open doors to deeper software risk management practices (stay tuned for a future post on that).
How Deconstructing Points Helps Your Team
Better Conversations
When estimating, your team can talk in terms of Time, Complexity, and Risk. This leads to richer discussions. If one person says “This seems low complexity to me” but another is worried about integration difficulties (complexity) or an unclear requirement (risk), that discrepancy surfaces immediately. You end up talking about the actual work and what’s actually impeding progress, which is exactly what we want! It’s far more useful than arguing whether a story is 3 points or 5 points with no arbitrary context, then folks using those numbers to drive decisions.
For example:
Before: A team argues if a user story for adding a new API endpoint is 5 or 8 points, with no clear why.
After: They rate time as 2-3 days, complexity high (tricky API integration), risk is zero (requirements clear), then discuss pairing for the integration and agree on 5 points with actions noted, like "Research API docs first."
Transparency of Assumptions
A single number hides whether an estimate is big because there’s a lot of work (time) or because it’s an unsolved problem (complexity) or simply unknown or scope is too big to confidently meet deadline (risk). By breaking it down, you make those assumptions explicit. This transparency helps in planning and mitigating issues.
For instance, if something has many risks, you know to document the risks immediately so you can start mitigation, or flag it to stakeholders. If something is high complexity, maybe pair programming or a spike is warranted.
Reduced Infighting & Gaming
Story points often lead to debates and sometimes games (“Let’s call everything a 5 to look consistent” or “We need to hit our velocity, so bump that 5 to an 8”). When you focus on the components instead, it’s less about gaming the number and more about understanding the work. It’s harder to arbitrarily inflate “risk” or “complexity” without justification. The team will ask “why do you think it’s high complexity?” which keeps things honest. If someone tries to game risk, it flags responsibility to the right stakeholder to address it, making gaming counterproductive. The result is an estimate that everyone actually understands. And yes, this adds some overhead compared to just slapping on points, but that's a good thing, these components deserve meaningful thought.
Alignment with Reality
Remember, as I pointed out in the last post, story points ultimately represent an unknown amount of time. By dealing with Time directly as one dimension, you maintain a link to reality (effort in actual time, even ranges) without committing to a precise timeline. It anchors the estimate in something tangible, while complexity and risk explain why the time dimension isn’t a simple translation. This helps prevent the “velocity fantasyland” where people forget that 40 points in a sprint doesn’t mean 40 anything in real world time by itself.
A Step Toward True Agility
In the previous post, I emphasized that agile isn’t about story points or rigid frameworks, it’s about adaptability and delivering value. This deconstruction technique is a step in that direction. It forces us to adapt our understanding for each story and focus on value impacting factors like risk. We’re still playing the corporate estimation game, but on our terms, keeping the important conversations alive. It’s a pragmatic compromise that can eventually help your team move beyond story points entirely.
A Note on Jira (and Other Tools)
Many of you are likely using Jira or a similar tool that’s built around story points. Yes, you can absolutely use this approach in Jira:
Custom Fields: Jira allows adding custom fields. So if you’re still using story points as your board estimate, you could add custom fields for, “Complexity”, and “Risk” to your stories. This makes the factors visible to anyone looking at the story.
What about Time? Check out this Atlassian support article to learn how you can use both story points and time estimates in the same company managed project. If you are using a team-managed project, add Time as a custom field.
Behind the scenes calculation: If your organization requires that the Story Point field be filled for every story (for velocity tracking, etc.), you have a couple of options. You could manually decide the story point after discussing T/C/R. Or you could get fancy and use a script or Jira automation to calculate a story point value. For example, you might choose to add the three values together, depending on how you scale each or weigh one higher than the other or use risk as a multiplier. The exact method isn’t critical, and it will vary by organization. The key is that the story point is no longer a wild guess, but a number with consistent variables behind it.
Don’t Sweat the Jira Details (Yet): The important part is the conversation and mindset shift, not the tooling. If adding fields is too much red tape in your company, you can still do this exercise informally and just agree on a story point after discussing Time/Complexity/Risk. While it doesn’t solve for the larger organizational dysfunction that can happen using the story point values, the discussion around these elements should still serve the team in positive ways. In an upcoming post, I’ll share a step by step guide on configuring Jira for this deconstructed story point approach (for those interested in the nitty-gritty).
Conclusion: Transforming Points into Insight
Story points may still be a necessary evil in your environment, but they don’t have to be useless or harmful. By breaking a story point into Time, Complexity, and Risk, you’re injecting intelligence and transparency into the process. You’re essentially saying, “If we have to play the estimation game, let’s at least make it insightful and grounded in reality.” This exposes the real drivers behind the work, potentially showing why story points might not be needed long-term.
This approach is a pragmatic middle ground. It acknowledges, as I did in the last post, that simply chasing story point velocity is a dead-end. At the same time, it helps you work within an existing system rather than fighting it outright. Over time, you might find your team focusing more on delivering value and managing risks, and less on the arbitrary story point totals.
Ultimately, true agility isn’t about the metrics or the labels, it’s about continuous learning, adaptation, and open communication. Deconstructing story points is just one way to nudge your team culture in that direction. It turns the story point from a vague, contentious number into a conversation starter about what really matters for the work at hand.
So if you’re stuck using story points, don’t despair. Try breaking them apart and discussing the pieces. You might be surprised how quickly “stupid” story points start sparking smart insights. And who knows, when your organization is ready to move past story points entirely, your team will be more than ready for that leap.
Stay tuned for the next post, where we’ll dive into practical tips on implementing this framework in Jira (for those of us in the Jira trenches). In the meantime, give the deconstructed approach a try in your next planning session and let me know how it goes!
I like that the article is focusing on the proper dialogue. I have one main question though.
"Time... It’s a gut feel for size/length, independent of complexity"
The increased complexity would usually significantly increase the time estimates. How do you really separate the two? And if you do, would this mean time an epic will potentially take is the sum of all the stories' time estimates?