Estimating Story Points Early On: Techniques And Considerations

Why Estimation Matters

Software development estimation serves several key purposes. It sets expectations for project scope, schedule, and resource needs. By estimating effort early, teams enable upfront planning and risk mitigation. Estimates also facilitate priority setting across proposed work items and product roadmapping based on business value.

Setting Realistic Expectations

Estimates provide the foundation for planningrelease cycles and product capability increments. They set expectations with stakeholders on anticipated delivery timeframes. Estimates should account for both direct development work and ancillary activities like testing, documentation, and deployment.

Informing Planning and Staffing

Estimates dictate staffing needs based on projected workload volume. The development team size and mix should match the skills required to complete estimated tasks within schedule constraints. Estimates also feed into financial planning for the projected costs of developer salaries and other resources.

Allowing Risk Avoidance

By calling out risky, complex, and time-consuming work items early, teams can allocate additional resources. Projects can evaluate and potentially avoid high-risk elements where rework likelihood outweighs business benefit. Teams also preemptively mitigate risks by adding buffer time for uncertainties.

Enabling Prioritization and Roadmaps

Estimate precision facilitates prioritization decisions by providing insight into the effort level and value of proposed work. Product managers can construct release roadmaps by bundling work items based on their size, risk, and business benefit.

Common Estimation Approaches

Many techniques exist for forecasting the level of effort required for software development tasks. Common strategies include expert opinion, analogy, decomposition and recomposition, and parametric estimation models.

Expert Opinion Estimates

Leveraging input from architects, senior developers, and subject matter experts provides a rapid approach to estimation based on existing team experience. It functions well for small work items but lacks scalability and consistency at scale.

Estimation By Analogy

Using the actual effort consumed for historical project work as the basis for estimating proposed tasks with similar characteristics. Analogy estimation is easy to understand but requires significant previous completion data.

Decomposition and Recomposition

Breaking down complex initiatives into small tractable subtasks, estimating these elements independently, and recomposing for an overall effort projection. This technique handles intricacy well but risks overlooking integration work.

Parametric Estimation Models

Applying parameterized effort formulas based on attributes like project size, complexity, team skills, and tooling. An example is the COCOMO model. These formulaic approaches enable automation but often oversimplify reality.

Key Estimation Challenges

While estimating techniques aim to provide accurate forecasts, many obstacles can undermine their precision. Common issues include unknowns, lack of precedents, and poor team understanding.

Unknown Unknowns

Project unknowns including unrecorded assumptions, complex integrations, and lack of familiarity with new technologies can lead to underestimation. Mitigations include architect reviews, risk analyses, prototyping, and learning milestones.

Lack of Historical Data

Analogical and parameterized estimation rely on previously completed work as the foundation for projecting future effort needs. When projects involve significant new development, these data deficit conditions result in guesswork.

Team Capacity Uncertainty

Estimating the delivery capability of development teams requires understanding their size, skills, tool proficiency, and collaborative efficacy. Assembling team member estimates without accounting for synergies and overhead can undermine accuracy.

Getting Started with Story Points

Story points provide a useful abstraction for quantifying the relative predicted effort of work items. Teams assign point values to each task to indicate size and complexity rather than time duration. Common story point scales include Fibonacci, powers of 2, and t-shirt sizes.

Defining Story Points

A story point is an arbitrary measure used by agile development teams to estimate user stories or product backlog items. They provide relativerather than absolute units, with precision coming from point comparisons within a bounded context rather than numeric exactness.

Relative Sizing Techniques

Teams size story points for an item by comparing its anticipated effort against completed stories from prior iterations that established the estimation reference baseline. Examples include affinity mapping, triangulation, poker planning, and sprint baselines.

Team Velocity Concept

Velocity represents the amount of work a team can handle in an iteration based on its capacity and past actual throughput. Velocity measured in story points establishes work intake rates for planning. Comparing planned and completed velocities indicates estimation accuracy.

Accounting for Uncertainty

Estimation uncertainty stems from ambiguous scope, unknown technology factors, complex integrations, and variability across individual team members. Strategies like ranges, progressive elaboration, and buffers address these risks.

Ranges Over Single Values

Expressing estimates as value ranges captures the inherent ambiguity better than prescribing false precision with absolute numbers. Ranges also clarify the distribution and quantify the variability around estimates.

Progressive Elaboration

The agile practice of adding detail over time through continuous estimation as work completes recognizes that certainty increases across iterations. Revisiting and adjusting estimates reflects this learning rather than anchoring on initial numbers.

Buffers for Volatility

Building estimation contingency and management reserve into plans acknowledges variability risks around effort forecasts. Buffers allocate time for unforeseen work that emerges during project execution.

Tracking Velocity Over Time

The most reliable velocity measures use trailing averages over multiple iterations to smooth data inconsistencies. Comparing actual output to past predictions highlights needed process adjustments. Teams re-estimate outstanding work to reflect learnings.

Averaging Across Iterations

Single iteration velocity fails to account for variation in individual performance, interruptions in team continuity from leave, and delivery infrastructure instability. Velocity averages framed within quarters or release cycles improve consistency.

Continuous Re-estimation

Teams measure velocity by comparing completed stories to initial estimates, exposing accuracy issues. Revisiting unfinished work every 3-5 iterations realigns estimates to reflect emergent scope, complexity, and prerequisite dependencies.

Monitoring Trends

Tracking changes in velocity averages over the lifespan of projects and products provides vital feedback on estimation skills. Persistent differences between planned and actual velocities indicate systemic estimation process shortcomings.

Case Studies and Examples

Estimation techniques always require customization for organization contexts. Studying other team experiences during estimationimprovement initiatives provides practical implementation guidance.

Transitioning to Story Points

Company X struggled with unrealistic schedules from inaccurate conversion of hours to months in time-based estimates. By adopting storypoints mapped to accomplished work per sprint, velocity improved estimation fidelity and product delivery cadences.

Addressing Overly Optimistic Culture

Project Y chronically overpromised to customers based on effort estimates reflecting only best-case execution scenarios. Introducing risk factors and buffer time into estimates for different uncertainty levels curtailed these predictive failings.

Using Monte Carlo Simulation Modeling

Technique Z supplemented direct team estimates with simulated effort ranges across 10,000+ automatically generated project scenarios with different productivity inputs. This algorithmic modeling revealed subjective human biases around overconfidence.

Key Takeaways and Next Steps

Software estimation presents many intricacies but serves as the essential foundation for project and product planning. Some best practices to start adopting include:

Continuous, Not One-Time Estimating

Effort levels evolve over time as new information appears and work completes. Progressively elaborating estimates with continuous feedback loops better accounts for risk and ambiguity.

Reducing Uncertainty

Focusing innovations on structuring work to quickly surface unknowns, integrating technical spikes into development sprints, and automating scope changes into re-estimation workflows diminishes volatility.

Balancing Flexiblity with Rigor

Allow teams to determine their own estimating methods but implement structured retrospective reviews when project outcomes diverge severely from projections. Increase estimating documentation while maintaining agility.