Sizing Questions And Answers

Why Your Sizing Estimates Keep Diverging From Reality

I've seen teams waste weeks reworking estimates because they were answering the wrong question entirely. Most people treat sizing like a math problem when it's actually a communication tool. The gap between what you think you're estimating and what your team hears is where projects go off the rails. Start with a clear baseline. Pick a reference story your team has actually delivered before—something mid-complexity that everyone understands. I usually suggest using an authentication endpoint with standard login, logout, and password reset flows. Not too simple, not nightmare-level complex. When new requirements come in, you compare against that baseline rather than trying to estimate from scratch every time. The actual question format matters more than you'd think. "How big is this?" is useless. Instead, ask "How does this compare to the login flow we did last month?" and "What parts feel unfamiliar?" The second question catches edge cases that kill timelines faster than anything else.

Here's something most guides won't tell you: the three-point sizing method (optimistic, most likely, pessimistic) breaks down when your team lacks historical data. We ran into this on a project where we were working with a brand new vendor. Their "pessimistic" estimate was just three times their optimistic one because they had zero reference points. What actually worked was having them size the first three tasks, then recalibrating the rest of the sprint against those actuals. The common pitfall is assuming everyone is measuring the same thing. One developer's "small" means a weekend. Another's "small" means four hours. I've watched senior engineers deflate their estimates down to half because they've already seen similar problems, while juniors pad aggressively. The fix isn't more training—it's making the comparison explicit. "This is 1.5x the reference story" forces everyone to ground their answer in shared understanding rather than personal assumptions. Another counter-intuitive point: larger numbers don't always mean larger work. A task might be 8 points but decomposable into smaller units that don't depend on each other. Conversely, a 3-point task with three external dependencies can take longer than anything in the 8-point bucket. Ask about dependencies before you finalize the number.

One specific edge case I ran into recently: a team was sizing a data migration task and kept landing on wildly different numbers. The issue wasn't estimation technique—it was that half the team assumed "migration" included validation and the other half thought it was just moving raw data. We stopped arguing about the size and wrote out exactly what each number covered. Once the scope boundary was visible, estimates snapped into alignment within two sprint planning sessions. The real value of sizing isn't the number itself. It's the conversation that surfaces uncertainty before work begins. If nobody in the room can articulate why something is a 5 versus a 8, you don't have an estimation problem—you have a clarity problem. Go back to requirements. Teams that get good at this stop treating sizing as a prediction exercise and start treating it as risk identification. The number you land on is less important than the assumptions you've surfaced. A perfectly accurate estimate built on hidden assumptions will still disappoint stakeholders. A slightly off estimate with fully visible risks gives everyone a chance to adjust.

If you need a starting template for organizing these discussions, I've put together a basic tracking sheet that covers the reference comparison, the decomposition question, and the dependency check all in one view. It's nothing fancy—just Google Sheets, honestly. You can find it at this link. The real improvement comes from consistently using the framework, not from the sheet itself. The hardest part isn't learning the method. It's keeping your team honest about uncertainty instead of inflating estimates to feel safe. That takes a few sprints to build the habit, but the alternative is the same pattern I see everywhere: confident predictions that miss by wide margins, followed by blame games instead of course corrections.