This article was originally published on Medium. I just feel it is "2", no, I think it is "3". When I first came across story points, I always wondered how the "experienced" people on the team were calling out numbers so confidently. Now that I've become one of those "experienced" people — I realized I still didn't have a stronger framework for it. Like everyone else, I'd gone with gut feeling. Others would nod along, and sometimes we'd walk out with no real sense of why. All I knew was it should follow the Fibonacci series. Everyone had different intuitions, and the loudest voice — or the consensus — won. So I tried to build a mental model for myself (not used by the team, yet), so I'd have something to point at when I picked a number. This is what I landed on after trying it on a couple of story-pointing sessions. Story points are supposed to capture how big the story would be, but the word "big" can pack in a lot of things, so I unpacked it into four things that I could actually measure: Complexity — How hard is this to build? New tech, tricky logic, or big design decisions push this up. Effort — How much work is there? A lot of small, easy changes across many files can still be Medium or High here, even if each change is trivial. Uncertainty / Risk — How clear is the requirement? Open questions, unfamiliar parts of the system, or things that might surprise me mid-way add risk. Dependencies — Does this depend on other teams or systems? This one is about waiting, not work. And waiting still inflates the point value. Every time the work unblocks, I have to re-page the state back into my head — and a story that crosses sprint boundaries carries its own cognitive overhead and spillover risk. Some people would argue dependencies shouldn't affect the size at all — they're not work, just calendar drag — but for me the cognitive overhead is real enough that they belong in the rubric. For each, I rate Low, Medium, or High. Dimension Low Medium High Complexity Pattern we've done many times Some design decisions needed New tech, design-heavy, or novel problem Effort Single small change Multiple changes, moderate scope Many files / modules / large scope Uncertainty / Risk Requirement fully clear Some open questions Significant unknowns Dependencies None external One known, manageable Multiple, or blocked on another team Roughly, here's where I thought it made sense. Your numbers will probably differ once you've used this a few times — and they should. Ratings Points All Low 1 One Medium, rest Low 2 Multiple Medium 3 One High 5 Multiple High 8 Mostly High 13 Do not be mechanical about this, it works now for me, can change in future. Sanity check: if a story lands at 8 or 13, ask whether it should be split before you size it. Stories with several high-rated dimensions are usually epics in disguise. I rate each dimension in my head before I name a number. The dimensions are the work; the number is just the output. The biggest thing I noticed isn't that I'm picking better numbers — it's that I can finally say why. Before, "5" was a feeling. Now I can trace it back: complexity High, dependencies Medium, the rest Low. Even if I don't share the breakdown out loud, having it in my head means I'm offering an estimate instead of a guess. And when I disagree with the room, I have something specific to point at — "I think it's a 5 because the unknowns here are bigger than they look" — instead of defending a number on instinct. This is a starting point, not a strict formula. Override it when experience says otherwise. After a few sprints, look back at the stories that surprised you — were the surprises about complexity? Dependencies? Something else? Adjust the dimensions and the ratings to match what actually drives your estimation misses. This doesn't convert to hours, and it shouldn't be used to measure individual productivity. The number isn't the point. The four-dimension conversation that produces it is. Thank you for reading, suggestions are welcome. Follow me on LinkedIn: Raj Kundalia