The Problem with Story Points
Before exploring alternative approaches, it's worth examining why story points—despite their theoretical advantages—often fall short in practice.
Story points were designed to address several problems with traditional time-based estimates:
- The false precision of hour/day estimates
- The failure to account for differences in individual productivity
- The tendency to conflate ideal time with elapsed time
- The psychological anchoring to previous estimates
Yet, in many organizations, story points have evolved to inherit the same problems they were meant to solve:
False Equivalence
Despite the theory that story points represent a combination of complexity, uncertainty, and effort, in practice they often devolve into thinly veiled time estimates. Teams routinely translate points directly to hours (e.g., "1 point = 4 hours"), negating the abstraction that made points valuable in the first place.
The Velocity Trap
When velocity (points completed per sprint) becomes a performance metric rather than a forecasting tool, teams face pressure to inflate or manipulate estimates. This pressure can lead to sandbagging (deliberately overestimating to appear more productive) or to artificially consistent velocity that masks real variations in productivity.
Estimation Overhead
The process of estimating each backlog item can consume significant team time in planning poker sessions and refinement meetings. For many teams, this overhead exceeds the value derived from having point estimates, especially when those estimates don't significantly improve forecasting accuracy.
Illusion of Precision
The Fibonacci sequence commonly used for story points (1, 2, 3, 5, 8, 13...) creates an illusion of mathematical precision that isn't supported by the subjective nature of the estimates. Teams debate whether something is a 5 or an 8 as if there's a objectively correct answer, when the difference is largely arbitrary.
Cross-Team Incompatibility
Since points are team-relative, they cannot be meaningfully compared across teams. This creates challenges for organizations trying to coordinate work across multiple teams, as there's no common language for sizing work.
These shortcomings have led many organizations to explore alternative approaches to estimation that better serve their needs for planning, forecasting, and healthy team dynamics.
T-Shirt Sizing: Simplifying Relative Estimation
One of the most widely adopted alternatives to story points is T-shirt sizing—a simpler approach to relative estimation that uses familiar size categories (XS, S, M, L, XL, XXL) instead of numeric values. While seemingly a minor change, this shift offers several significant advantages:
Benefits of T-Shirt Sizing
- Reduced precision illusion: The categorical nature of T-shirt sizes makes it clear that these are rough approximations, not precise measurements.
- Faster estimation: Teams typically find it easier and faster to assign a size category than to debate numeric point values.
- Intuitive scaling: Most people already have an intuitive understanding of the relative difference between sizes (a medium is roughly twice as big as a small, etc.).
- Non-linear progression: T-shirt sizes naturally accommodate the non-linear relationship between size and uncertainty (larger items have disproportionately more uncertainty).
- Reduced overhead: The simplified scale reduces time spent on estimation without significantly affecting forecast accuracy.
Implementation Approach
To implement T-shirt sizing effectively:
- Define a shared understanding of what each size category means for your team
- Start with reference stories that exemplify each size category
- Use range-based planning rather than single-point forecasts
- Track completion times for each size category to improve future forecasting
- Consider further simplification for some contexts (e.g., just S/M/L)
Example T-Shirt Size Definitions:
Size | Typical Characteristics | Time Range |
---|---|---|
XS |
|
0.5-1 day |
S |
|
1-3 days |
M |
|
3-5 days |
L |
|
1-2 weeks |
XL |
|
2+ weeks |
Note that while time ranges are included here for reference, they're not the primary basis for assignment. The focus remains on relative sizing based on complexity, uncertainty, and effort, with time ranges emerging from historical data rather than driving the initial estimates.
Practical Considerations
When implementing T-shirt sizing, keep these considerations in mind:
- Break down large items: Just as with story points, items sized XL or larger should typically be broken down before implementation.
- Adapt ceremonies: Estimation activities like planning poker can be adapted to use size categories instead of point values.
- Visualize distributions: Track the distribution of sizes across your backlog to identify potential issues (e.g., too many large items).
- Connect to forecasting: Convert sizes to ranges for sprint and release planning, accounting for the uncertainty in larger items.
T-shirt sizing retains the benefits of relative estimation while addressing many of the practical issues with story points. For many teams, it provides a more intuitive, less overhead-intensive approach to estimating work.
NoEstimates: Forecasting without Story-Level Estimation
Taking a more radical departure from traditional practice, the "NoEstimates" movement questions the fundamental value of estimating at the story level. Instead, it focuses on tracking flow, managing work in progress, and using historical throughput to forecast delivery timeframes.
Core Principles
The NoEstimates approach is built on several core principles:
- Focus on throughput: Track how many work items are completed per time period, rather than trying to estimate each item individually.
- Standardize work item size: Break work down into roughly similar-sized items, minimizing the need for individual estimation.
- Manage flow: Prioritize smooth and predictable flow of work over optimizing utilization or velocity.
- Probabilistic forecasting: Use historical data and statistical methods to create range-based forecasts rather than single-point estimates.
- Reduce batch size: Work in smaller increments to increase predictability and reduce the cost of delay.
Implementation Approaches
There are several ways to implement NoEstimates principles, depending on your team's context:
Count-Based Forecasting
The simplest approach tracks the number of work items completed per time period (e.g., sprint or week) and uses this throughput to forecast future delivery:
Example Count-Based Forecast:
- Historical throughput: 6-10 items per sprint (average 8)
- Backlog items remaining: 40
- Basic forecast: 40 ÷ 8 = 5 sprints
- Range forecast (using min/max): 4-7 sprints
This approach works best when work items are broken down to roughly similar sizes. For teams using user stories, this often means ensuring that stories are small enough to be completed within a few days.
Monte Carlo Simulation
For more sophisticated forecasting, Monte Carlo simulation uses historical throughput data to run thousands of simulations of possible futures:
Example Monte Carlo Forecast:
Based on 10,000 simulations using historical throughput data:
- 50% confidence: 5 sprints
- 70% confidence: 6 sprints
- 85% confidence: 7 sprints
- 95% confidence: 8 sprints
This approach provides probability-based forecasts that acknowledge the inherent uncertainty in software development, shifting the conversation from "When will it be done?" to "How confident are we that it will be done by a certain date?"
Cycle Time Tracking
Another NoEstimates approach focuses on cycle time—the time it takes for a work item to move from "in progress" to "done." By tracking cycle times for different types of work, teams can create more accurate forecasts without estimating individual items:
Example Cycle Time Analysis:
Based on historical data for the last 30 completed items:
- 50th percentile (median) cycle time: 5 days
- 85th percentile cycle time: 8 days
- 95th percentile cycle time: 12 days
For a new feature with 10 work items:
- Forecast (50% confidence): 7-8 weeks (working in parallel)
- Forecast (85% confidence): 9-10 weeks
This approach is particularly effective for teams using Kanban or other flow-based methods, as it focuses on optimizing the end-to-end flow of work rather than sprint commitments.
Benefits and Challenges
Benefits of NoEstimates:
- Reduced overhead: Eliminates time spent on detailed story-level estimation
- Data-driven forecasting: Based on actual historical performance rather than subjective estimates
- More realistic uncertainty: Explicitly acknowledges the probabilistic nature of delivery timeframes
- Better team dynamics: Reduces pressure to inflate estimates or manage to velocity metrics
- Focus on value delivery: Shifts focus from estimation accuracy to delivering valuable increments
Challenges and Limitations:
- Cultural shift: Requires stakeholders to accept probabilistic forecasts instead of commitments
- Historical data: Needs sufficient historical data to create reliable forecasts
- Consistent sizing: Requires discipline in breaking work into relatively consistent-sized items
- Mixed contexts: May be harder to apply in highly variable work environments
- Stakeholder expectations: May require education for stakeholders accustomed to concrete estimates
NoEstimates represents a significant departure from traditional estimation practices, but for teams willing to make the shift, it can dramatically reduce estimation overhead while providing more realistic forecasts.
Hybrid Approaches: Combining Techniques for Better Results
Rather than viewing different estimation approaches as mutually exclusive, many teams find value in combining techniques based on the context and needs of different types of work. Here are some effective hybrid approaches:
Two-Tier Estimation
One practical hybrid approach uses different estimation techniques for different levels of work:
- Initiative level: Use T-shirt sizing for epics and larger initiatives to provide rough forecasts for roadmap planning
- Story level: Use NoEstimates principles for day-to-day work, tracking throughput and cycle time rather than estimating individual stories
This approach balances the need for longer-term planning with the efficiency of flow-based delivery at the team level. It recognizes that different stakeholders need different levels of forecasting:
Example Two-Tier Approach:
Initiative Level (for executives, product management):
- User Profile Redesign: Medium (1-2 months)
- Payment Integration: Large (2-3 months)
- Performance Optimization: Small (2-4 weeks)
Team Level (for development team):
- User Profile Redesign broken into 15-20 stories
- Tracking: 8-10 stories completed per sprint
- Forecast updated weekly based on actual progress
Complexity-Based Sizing with Time Tracking
Another hybrid approach separates the sizing of work from the forecasting process:
- Size work items based on complexity using a simple scale (e.g., 1, 2, 3)
- Track actual time spent on items of each complexity level
- Use historical data to forecast future work based on complexity
This approach maintains the benefits of relative sizing while creating increasingly accurate time-based forecasts as historical data accumulates:
Example Complexity-Based Approach:
Complexity | Historical Cycle Time | Forecast Range |
---|---|---|
1 (Simple) | 1-3 days | 2 days |
2 (Moderate) | 3-7 days | 5 days |
3 (Complex) | 7-14 days | 10 days |
For a backlog with 5 simple, 8 moderate, and 3 complex items:
Forecast: (5 × 2) + (8 × 5) + (3 × 10) = 10 + 40 + 30 = 80 days
Confidence-Based Estimation
This hybrid approach focuses on the team's confidence in their estimates rather than the estimates themselves:
- Assign a basic size category to work items (e.g., S/M/L)
- Add a confidence rating (High/Medium/Low) to each estimate
- Apply different buffers based on confidence level
- Track accuracy by confidence level to improve future forecasts
Example Confidence-Based Approach:
Buffer Multipliers:
- High confidence: 1.2x
- Medium confidence: 1.5x
- Low confidence: 2.0x
For a feature with:
- 3 Medium stories (High confidence): 5 days × 3 × 1.2 = 18 days
- 2 Large stories (Medium confidence): 10 days × 2 × 1.5 = 30 days
- 1 Large story (Low confidence): 10 days × 1 × 2.0 = 20 days
Total forecast: 18 + 30 + 20 = 68 days
This approach explicitly acknowledges the varying levels of uncertainty in different work items, providing more realistic forecasts by accounting for confidence levels.
Context-Sensitive Estimation
Perhaps the most flexible hybrid approach applies different estimation techniques based on the specific characteristics of the work:
- Exploratory work: Use timeboxing rather than estimation ("We'll spend 2 weeks exploring solutions")
- Routine work: Use throughput-based forecasting without individual estimates
- Complex new features: Use T-shirt sizing with confidence ratings
- Critical path work: Break down into small stories and track cycle time
This approach recognizes that different types of work have different estimation characteristics and adapts techniques accordingly.
These hybrid approaches allow teams to tailor their estimation practices to their specific context while addressing the key limitations of traditional story point estimation. The best approach often combines elements from multiple techniques, adapted to your team's specific needs and organizational context.
Cross-Functional Work: Estimating Beyond Development
Modern product development involves multiple disciplines beyond software development, including design, research, quality assurance, and operations. Traditional estimation approaches often struggle to account for this cross-functional nature of work. Here are approaches specifically designed for estimating cross-functional work:
Role-Based Estimation
This approach recognizes that different roles may have different perspectives on the complexity of a given work item:
- Have representatives from each discipline estimate separately
- Discuss differences in perspectives to gain shared understanding
- Track actual effort by discipline to improve future estimates
- Use the highest estimate as the basis for planning to account for bottlenecks
Example Role-Based Estimation:
Feature: Enhanced Data Export
Role | Sizing | Main Concerns |
---|---|---|
UX Design | Medium | Interface for selecting data, format options |
Frontend | Small | Implementing UI components |
Backend | Large | Data extraction, formatting, performance |
QA | Medium | Testing various data types, edge cases |
Overall sizing: Large (driven by backend complexity)
This approach helps identify which disciplines will be most impacted by a given work item and ensures that all perspectives are considered in the estimation process.
Value Stream Mapping
For end-to-end features that flow through multiple teams or disciplines, value stream mapping provides a way to visualize and estimate the entire process:
- Map out all the steps in delivering the feature from concept to production
- Identify the disciplines involved at each step
- Estimate cycle time and wait time for each step
- Use the complete map to forecast end-to-end delivery timeframes
Example Value Stream Map:
[This would be a visual showing the flow of work through different disciplines, with cycle time and wait time estimates for each step.]
Based on this map:
- Total cycle time: 15 days of actual work
- Total wait time: 10 days of handoffs and queues
- End-to-end forecast: 25 calendar days
This approach helps identify bottlenecks and wait times that traditional estimation methods often miss, providing a more realistic view of end-to-end delivery timeframes.
Constraint-Based Estimation
For teams with specialized skills that create bottlenecks, constraint-based estimation focuses on those constraints:
- Identify the constraining resources for each work item
- Estimate demand on those resources specifically
- Use constraint capacity to drive overall forecasting
- Identify ways to reduce dependency on constraints
Example Constraint-Based Estimation:
Constraint identified: Data engineering (single specialist on team)
Current capacity: 20 hours per week
Upcoming work:
- Feature A: 15 hours of data engineering work
- Feature B: 25 hours of data engineering work
- Feature C: 5 hours of data engineering work
Forecast: 45 hours total / 20 hours per week = 2.25 weeks (assuming no other work)
This approach recognizes that the overall delivery timeline is often driven by the most constrained resources, regardless of the size of the work item overall.
Phase-Based Estimation
For organizations with distinct phases in their development process, phase-based estimation provides forecasts for each phase:
- Break down the delivery process into distinct phases
- Estimate size for each phase separately
- Track historical phase completion times by size
- Use phase-specific forecasts to create end-to-end timelines
Example Phase-Based Estimation:
Phase | Size | Historical Range | Forecast |
---|---|---|---|
Research | Medium | 1-2 weeks | 2 weeks |
Design | Large | 2-3 weeks | 3 weeks |
Development | Medium | 2-4 weeks | 3 weeks |
Testing | Medium | 1-2 weeks | 2 weeks |
Deployment | Small | 0.5-1 week | 1 week |
End-to-end forecast: 8-11 weeks (with some parallel work)
This approach works well for organizations with well-defined delivery phases and helps highlight which phases contribute most to overall delivery timeframes.
These cross-functional estimation approaches acknowledge the reality that modern product development involves multiple disciplines and helps create more realistic forecasts that account for all aspects of delivering value to users.
Implementing New Estimation Approaches: A Practical Guide
Transitioning to new estimation approaches requires thoughtful change management. Here's a practical guide to implementing new estimation techniques in your organization:
Start Small
Begin with a pilot implementation to build confidence and gather data:
- Select a single team that's open to experimentation
- Choose a specific project or time period for the pilot
- Run the new approach in parallel with existing methods initially
- Track results to compare accuracy and overhead
This approach allows you to demonstrate value and work through initial implementation challenges before scaling more broadly.
Engage Stakeholders
Prepare stakeholders for changes in how estimates are communicated:
- Educate on limitations of current estimation practices
- Explain benefits of the new approach for planning and delivery
- Set expectations about changes in how forecasts will be presented
- Create visualization tools to help stakeholders understand new formats
Remember that stakeholders often care less about the specific estimation technique and more about getting reliable information for planning and decision-making.
Collect and Use Historical Data
Build systems to collect and analyze historical performance data:
- Track completion times for different types and sizes of work
- Analyze variance and patterns in historical data
- Use data visualization to communicate trends and distributions
- Regularly update reference data based on recent performance
The accuracy of data-driven forecasting approaches improves as you accumulate more historical data, so invest in good data collection from the start.
Adapt Ceremonies and Tools
Modify existing agile ceremonies and tools to support new estimation approaches:
- Adapt backlog refinement to focus on sizing rather than pointing
- Modify planning meetings to incorporate new forecasting techniques
- Update reporting dashboards to show appropriate metrics
- Create new visualization tools as needed for probabilistic forecasts
Look for opportunities to reduce estimation overhead while maintaining or improving the quality of information available for planning.
Evaluate and Refine
Regularly assess the effectiveness of new estimation practices:
- Compare forecast accuracy between old and new approaches
- Gather feedback from team members on the estimation process
- Survey stakeholders on the usefulness of new forecasts
- Measure time spent on estimation activities
- Regularly adjust and refine your approach based on results
Be prepared to make adjustments based on what you learn. The goal is not to implement a specific estimation technique perfectly, but to develop an approach that works well for your specific context.
Address Cultural Factors
Estimation practices are deeply intertwined with organizational culture. Address these cultural factors to support successful change:
- Separate estimation from performance evaluation to reduce gaming of estimates
- Create psychological safety around uncertainty and probability-based forecasts
- Promote a learning mindset about estimation and forecasting
- Celebrate improvements in predictability, not just velocity
Cultural factors often have a greater impact on estimation effectiveness than the specific technique used, so don't neglect this aspect of the change.
Example Implementation Timeline:
Month 1: Preparation
- Educate team on new estimation approaches
- Set up data collection for historical performance
- Engage stakeholders and set expectations
Month 2-3: Pilot
- Run new approach alongside existing estimation
- Track results and refine process
- Develop visualization tools for forecasts
Month 4-5: Gradual Transition
- Expand to additional teams
- Phase out old estimation practices
- Update planning and reporting processes
Month 6+: Continuous Improvement
- Regular retrospectives on estimation effectiveness
- Ongoing data collection and analysis
- Further refinement of approach based on results
By taking a thoughtful, incremental approach to implementing new estimation techniques, you can minimize disruption while maximizing the benefits of more effective forecasting practices.
Case Study: Adaptive Estimation at FinTech Inc.
To illustrate how alternative estimation approaches work in practice, let's examine how FinTech Inc., a mid-sized financial software company, transformed their estimation practices to better support their product development process.
Background and Challenges
FinTech Inc. had been using story points for several years but faced recurring challenges:
- Story point estimation sessions were consuming up to 20% of team capacity
- Despite detailed estimation, delivery forecasts were rarely accurate
- Teams felt pressured to maintain constant velocity, leading to estimate inflation
- Cross-team dependencies were causing unpredictable delays
- Stakeholders were frustrated by missed deadlines and uncertain forecasts
Solution Approach
After researching alternatives, FinTech Inc. implemented a hybrid estimation approach tailored to their context:
For Strategic Planning (Quarterly):
- T-shirt sizing for initiatives and epics
- Reference class forecasting based on historical data
- 85% confidence intervals for delivery timeframes
For Team-Level Planning (Sprint):
- No individual story estimates
- Focus on breaking stories to similar sizes
- Throughput-based forecasting using historical data
- Cycle time tracking for different work types
For Cross-Team Coordination:
- Constraint-based planning focused on specialized resources
- Value stream mapping for end-to-end visibility
- Explicit buffers for handoffs between teams
Implementation
FinTech Inc. took a phased approach to implementation:
Phase 1: Data Collection (2 months)
- Continued using story points while collecting historical data
- Implemented tracking of cycle times and throughput
- Created reference data for similar past initiatives
Phase 2: Pilot Team Transition (3 months)
- One team stopped estimating individual stories
- Used throughput-based forecasting for sprint planning
- Compared results with traditional estimation approaches
Phase 3: Organization-Wide Rollout (4 months)
- Gradual transition of all teams to new approach
- Updated roadmap and portfolio planning processes
- Created new visualization tools for probabilistic forecasts
- Trained stakeholders on interpreting new forecast formats
Results
After nine months with the new approach, FinTech Inc. experienced significant improvements:
- Reduced estimation overhead by 85% (from 20% of capacity to 3%)
- Improved forecast accuracy from 35% to 80% of initiatives delivered within forecast
- Better stakeholder relationships due to more reliable, transparent forecasts
- Higher team satisfaction with planning processes (as measured in engagement surveys)
- More effective cross-team coordination through constraint-based planning
Perhaps most importantly, the time saved on estimation activities was redirected to value-adding work, resulting in a 15% increase in feature delivery without adding resources.
Lessons Learned
FinTech Inc.'s experience yielded several valuable lessons:
- Historical data is crucial for effective forecasting; invest in good data collection
- Different contexts need different approaches; one-size-fits-all estimation doesn't work
- Stakeholder education is as important as the technical implementation
- Probabilistic forecasts better reflect the reality of software development uncertainty
- Focus on outcomes over process; the goal is effective planning, not adherence to a specific method
This case study demonstrates how a thoughtful, context-specific approach to estimation can significantly improve both the efficiency of the planning process and the accuracy of delivery forecasts.