Estimating without sandbagging — Patterns & Anti‑Patterns — Practical Guide (Mar 12, 2026)
Estimating without sandbagging — Patterns & Anti‑Patterns
Level: Experienced Software Engineers & Team Leads
As of March 12, 2026
Introduction
Software estimation remains one of the most challenging tasks in software engineering. Often, developers sandbag or pad estimates to avoid missing deadlines or to “manage expectations.” While understandable, sandbagging undermines trust, causes misallocations, and delays product delivery. This article explores practical, modern patterns and anti-patterns to improve estimation accuracy and transparency, fostering a healthier culture without resorting to padding.
Prerequisites
- Familiarity with Agile methodologies (Scrum, Kanban) and estimation techniques such as story points, ideal hours, or t-shirt sizing.
- Understanding of team velocity, capacity planning, and sprint commitments (versions since Scrum Guide 2020 are relevant).
- Experience with collaboration tools supporting backlog refinement, e.g. Jira, Azure DevOps, or Wheelhouse.
- Basic statistical literacy to understand confidence intervals, ranges, and variability in estimates.
Hands-on Steps
1. Adopt Relative Estimation Over Absolute
Instead of estimating time in hours or days, use relative measures like story points. This decouples estimation from calendar time and reduces pressure to “pad” exact hours.
// Example: Fibonacci sequence sizing for stories
const userStorySizes = {
login: 2,
addItemToCart: 3,
checkoutProcess: 8
};
function compareStories(storyA, storyB) {
if(userStorySizes[storyA] > userStorySizes[storyB]) {
return `${storyA} is larger`;
}
return `${storyB} is larger or equal`;
}
// Encourage team discussion rather than time-based estimates
console.log(compareStories('checkoutProcess', 'addItemToCart'));
2. Use Estimation Ranges and Confidence Levels
Provide a range (e.g., 3–5 days) with a probability or confidence percentage rather than a single number. This better reflects inherent uncertainty and reduces incentive to pad estimates.
def estimate_with_confidence(task):
# Example estimates with confidence intervals
estimates = {
'API Integration': (4, 6, 0.85), # min days, max days, confidence level
'UI Revamp': (7, 12, 0.75)
}
if task in estimates:
low, high, conf = estimates[task]
print(f"{task} estimate: {low}-{high} days with {conf*100}% confidence")
else:
print("No estimate available")
estimate_with_confidence('API Integration')
3. Perform Regular Backlog Refinement Sessions
Frequent refinement leads to better understanding of stories and thus tighter estimates. Invite cross-functional input to uncover hidden complexities early.
4. Track Actual vs Estimated and Share Transparently
Publishing historical data on estimates vs actuals helps calibrate future estimates and builds trust across stakeholders. Use dashboards or reporting tools linked to your issue tracker.
5. Discuss Risk Explicitly and Separate It from Base Estimates
Identify risks and uncertainties explicitly. Instead of adding padding to base estimates, track risks separately with mitigation plans.
Common Pitfalls (Anti-Patterns)
Sandbagging by Padding Estimates
Artificially inflating time or effort estimates creates mistrust and inflates project timelines unnecessarily.
Single-Point Time Estimates Without Context
Presenting a single precise number without acknowledging variability leads to misleading expectations and pressure to “hit the exact number.”
Lack of Feedback Loops
Ignoring past estimation performance data results in repeated errors and perpetuation of sandbagging culture.
Ignoring Stakeholder Engagement
Estimates made in isolation often underestimate real requirements or overlook external dependencies.
Validation
To ensure your improved estimation process is working without sandbagging:
- Compare historical sprint velocity variance over multiple sprints; aim to reduce unexplained variation.
- Conduct anonymous surveys asking team members if they feel pressured to pad estimates.
- Correlate estimates with post-delivery defect counts and rework hours to measure estimate quality.
- Facilitate retrospective sessions focused on estimation and delivery discussions.
Checklist / TL;DR
- Prefer relative estimation (story points) to absolute hours.
- Express estimates as ranges with confidence levels.
- Hold frequent backlog refinement and risk discussions.
- Track and openly share actual vs estimated performance.
- Separate risk buffers from base task estimates.
- Avoid sandbagging—trust-building trumps padding.
- Engage all stakeholders for comprehensive understanding.
When to Choose Relative vs Absolute Estimation?
Relative estimation works well when dealing with complex, variable tasks and fosters team consensus. It suits Agile environments where velocity feedback loops optimise predictability over time.
Absolute estimation may be appropriate for very small, well-defined, repetitive tasks or when contracts require time-based deliverables. But it demands greater confidence and often invites padding under uncertainty.