After exploring the basics of software estimation and understanding the key elements that make estimates valuable, it’s time to get practical. You know the theory, you understand what good estimates should provide, but now you’re sitting in your next sprint planning wondering: “Which estimation method should I actually use?”

As someone who’s wrestled with estimation challenges in different enterprise environments, I’ve learned that having a toolkit of proven methods is essential. Today, I’ll share my three go-to estimation approaches that have consistently delivered value in DevOps teams, along with some bonus tips that can save you from common estimation pitfalls.

The Reality Check: Choosing Your Weapon

Before diving into specific methods, let’s acknowledge the elephant in the room. In the corporate world, we rarely get to choose whether we estimate—the question is usually how to do it effectively within existing constraints. While methods like Monte Carlo simulation and parametric methods such as COCOMO exist and have their merits, I’ll focus on what I’ve actually used successfully in real projects with real deadlines and real stakeholders breathing down my neck.

Remember from my previous posts that a good estimation should give you four crucial values:

• Best case scenario (when everything goes right)
• Worst case scenario (when Murphy’s Law strikes)
• Most likely case (your realistic expectation)
• 90% confidence interval (the range you’re willing to bet your reputation on)

Let’s explore three methods that can deliver these values in different contexts.

Method 1: Story Point Estimation (When You Have History)

The Approach

Story Point Estimation works on a simple principle: comparing relative effort is easier than estimating absolute values. Instead of trying to figure out if a feature will take exactly 8 days, you compare it to something you’ve done before and say “this is about twice as complex as that shopping cart feature we built last sprint.”

The key ingredients for success:

• Estimation by comparison rather than absolute guessing
• Regular measurement and recalibration based on actual delivery
• “Yesterday’s weather” principle (your recent velocity is your best predictor)

When It Shines

This method works beautifully when:

• All items have similar size ranges, which helps balance out estimation errors
• You have a stable context (same team, same product, same tech stack)
• Historical data exists to calibrate your estimates
• Your team has developed a shared understanding of story point values

The No-Estimate Evolution

Here’s something most teams don’t realize: if you get really good at creating similarly-sized stories, you’re essentially moving toward a “no-estimate” approach. Why spend time on story point poker when you can just focus on defining stories with consistent sizes and count the number of items you deliver?

Story splitting techniques like The Story Splitting Flowchart and SPIDR are invaluable for helping teams create stories of similar sizes. These methods provide systematic approaches to breaking down large stories into consistently-sized work items.

During this transition, I recommend running both approaches in parallel—track your story point velocity alongside your delivery count and see which predicts better.

Getting Your Four Values

At first glance, story points seem to give you only one number. But here’s the magic: when combined with your team’s actual delivery data, you can calculate all four estimation values.

Track your sprint-to-sprint velocity variance. If your team typically delivers 25 story points per sprint with a standard deviation of 5 points, you can calculate:

• Most likely case: 25 points
• Best case: 35 points (mean + 2 standard deviations)
• Worst case: 15 points (mean - 2 standard deviations)
• 90% confidence interval: Use your historical distribution data

When It Struggles

Story points become unreliable when:

• You’re working in a highly volatile environment without reference points
• The team composition changes frequently
• You’re using completely new technology stacks
• Context switching between different types of work is constant

Method 2: Three-Point Estimation (When You’re Flying Blind)

The Approach

When you don’t have historical data to lean on—new team, new product, new technology—three-point estimation becomes your lifeline. This method involves a group of experts estimating three scenarios for each work item, then using statistical formulas to calculate confidence intervals.

The process:

1. Gather your most experienced developers
2. Estimate best case, worst case, and most likely case for each item
3. Calculate the 90% confidence interval using the formula

The Math That Actually Works

There are several statistical distribution models you can use to represent the probabilities of an estimation—normal distribution and PERT distribution each have their merits. After experimenting with different approaches, I’ve settled on the formula from Steve McConnell’s “Software Estimation: Demystifying the Black Art” that balances accuracy with simplicity:

Confidence Interval = Most Likely + 1.28 × ((Worst Case - Best Case) / 3)

This assumes:

• 90% probability coverage between best and worst case (achievable with experienced developers)
• Target confidence interval of 90% (good for most project planning)

The Critical Success Factor

The make-or-break element of three-point estimation isn’t the math—it’s having the courage to estimate a worst case that truly covers everything that could go wrong. Most developers severely underestimate this because we’re naturally optimistic about our ability to solve problems.

My favorite question to help teams get realistic: “Would you quit your job if this worst-case value is exceeded? If not, estimate again.”

When It Shines

Three-point estimation works best when:

• Historical data is limited or non-existent
• You have senior developers with broad experience
• Uncertainty is high and needs to be quantified
• Stakeholders need explicit risk communication

When It Struggles

This method can fail when:

• Team members lack experience with similar work
• Political pressure prevents honest worst-case estimates
• The scope is too large or poorly defined
• Dependencies between items are complex

Method 3: T-Shirt Sizing (When You’re Estimating Epics)

The Reality of Epic-Level Estimation

In DevOps teams, you’ll often find yourself in situations where stakeholders need estimates for major releases, roadmap planning, or epic-level work. This is where many teams reach for T-shirt sizing (XS, S, M, L, XL, XXL) because it feels more comfortable than putting specific numbers on large, complex work items.

T-shirt sizing makes intuitive sense at the epic level:

• Relative comparison works well for high-level features
• Less intimidating than precise numbers for uncertain work
• Stakeholder-friendly communication tool
• Quick estimation process for roadmap discussions

The Timeline Forecasting Problem

Here’s where most teams get stuck: you’ve estimated your epic as “Large,” but your project manager is asking “When will this be delivered?” T-shirt sizes are great for relative prioritization, but they don’t directly translate to timelines.

I’ve seen teams try various approaches:

• Assigning arbitrary time ranges to each size (“Medium = 2-4 months”)
• Converting T-shirt sizes to story points after breaking down epics
• Using historical data from similar-sized epics (when it exists)

My Recommendation: Bridge to Three-Point Estimation

When you need timeline forecasts from T-shirt sized epics, here’s what I’ve found works:

1. Start with T-shirt sizing for initial epic comparison and prioritization
2. Convert to three-point estimation when timeline forecasting is needed
3. Involve your most experienced team members who understand the epic scope

The process looks like this:

• Take your “Large” epic and have experienced developers estimate best case, worst case, and most likely case in weeks or months
• Apply the three-point estimation formula to get your confidence interval
• Use this timeline data for project planning and stakeholder communication

Why This Hybrid Approach Works

This combination leverages the strengths of both methods:

• T-shirt sizes provide quick, intuitive relative sizing for portfolio discussions
• Three-point estimation gives you the statistical foundation for timeline forecasting
• Experienced developers can bridge the gap between high-level scope and realistic timelines

The key insight: T-shirt sizing is excellent for comparing and prioritizing epics, but when stakeholders need delivery timelines, you need the statistical rigor that only comes from three-point estimation.

The Method Selection Decision

So which method should you choose? Like most things in software development, it depends on your context:

Choose Story Points when:

• Your team and technology stack are stable
• You have at least 3-6 months of historical delivery data
• Work items are reasonably similar in nature
• You can invest time in calibrating and maintaining the system

Choose Three-Point Estimation when:

• You’re starting fresh with a new team or technology
• Work involves significant unknowns or R&D elements
• Stakeholders need explicit uncertainty communication
• Historical data isn’t available or relevant
• You need timeline forecasts from T-shirt sized epics

Choose T-Shirt Sizing when:

• Estimating at the epic or feature level
• Need quick relative comparison for roadmap planning
• Working with stakeholders who prefer qualitative sizing
• Historical data at the epic level doesn’t exist or isn’t comparable

Don’t force story points when you lack historical context, and don’t overcomplicate with three-point estimation when simple velocity tracking would suffice.

Bonus Tips: Avoiding Common Estimation Traps

A common mistake I see teams make is providing estimates with artificial precision. Saying “this will take 3.7 days” implies a level of accuracy that simply doesn’t exist in software development. This false precision leads stakeholders to expect unrealistic reliability from your estimates.

Instead:

• Use ranges: “2-5 days” instead of “3.5 days”
• Round to meaningful intervals: week/month granularity
• Be explicit about uncertainty levels in your communication

Parkinson’s Law states that work expands to fill the time available. In estimation contexts, this means if you give a 10-day estimate, the work will somehow take 10 days even if it could be done in 7.

Here’s how I combat this:

• For project planning and dependencies: Use the worst-case or the confidence interval, depending on your risk affinity. This protects against cascading delays.
• For daily work and team goals: Use the best-case and most likely scenarios. This maintains urgency and prevents padding from becoming reality.

This dual approach helps you plan conservatively while executing optimistically.

Other Methods Worth Mentioning

For completeness, I should mention that other estimation techniques exist, like Monte Carlo simulation and parametric methods such as COCOMO. While these have theoretical merit and work well in certain contexts, I haven’t found them practical for most DevOps team environments. The overhead of setup and maintenance often outweighs the benefits, especially when stakeholders are looking for “good enough” estimates rather than statistical perfection.

If you have experience with these methods in enterprise environments, I’d love to hear about it!

Wrapping Up: Estimation as a Tool, Not a Goal

After working with estimation for years in a wide spectrum of enterprise environments, I’ve learned that the best estimation method is the one your team will actually use consistently. Story points, three-point estimation, and T-shirt sizing can all provide the key values you need for effective planning, but only if implemented thoughtfully and maintained over time.

Remember that estimation is a means to an end—better planning, risk management, and stakeholder communication. Don’t get so caught up in perfecting your estimation process that you forget to deliver working software.

The key is matching your method to your context, being honest about uncertainty, and using the estimates to facilitate better decisions rather than create false certainty.

This concludes our three-part series on software estimation. If you found this useful, consider sharing it with your team or reaching out with your own estimation experiences and challenges.