Moving From Time Estimates To Relative Sizing For Improved Planning
Moving Beyond Time Estimates
Software development teams have traditionally relied on time estimates to plan and schedule projects. However, time estimates have proven to be unreliable and often lead to missed deadlines, rushed output, and frustration among teams.
Estimating the time required to complete software development tasks can be challenging as there are many unknowns and variables that impact the actual time needed. Requirements frequently change during development, technologies don’t always work as expected, and developer productivity can fluctuate from day-to-day.
Relative sizing is an alternative approach focused more on the complexity or effort required to complete work. Rather than predicting the number of hours or days a task will take, stories or features are assigned an abstract Story Point value based on effort and complexity.
Why Time Estimates Fall Short
There are several reasons why time estimates commonly fail for software projects:
- Inaccurate assumptions: Estimates rely on guessing how much time tasks will take before fully understanding requirements.
- Unknowns: Project unknowns including changing specs, technology issues, and interruptions that impact velocity.
- Cognitive biases: Developers lean towards underestimating to win work even when unrealistic.
- Poor tracking: Lack of tracking estimate accuracy results in failure to improve.
Due to these factors, initial time estimates end up being far different from reality. What was estimated to take a week ends up requiring several weeks to finish.
The Challenges of Estimating Time Accurately
Estimating anything requires making assumptions and guesses about the future. With software projects there is substantial ambiguity and the requirements themselves are likely to change during development.
Some key challenges include:
- Heavy dependence on individual developer productivity
- Unexpected complexity in certain components
- Scope creep from evolving customer needs
- Integration issues with existing systems
- Understanding time needed to learn new technologies
- Interruptions and context switching decreasing focus
- Failure to account for non-development responsibilities
Even with rigorous effort and the best of intentions, unknowns make accurately budgeting time difficult. Relative sizing helps circumvent needing fine-grained time predictions.
Introducing Relative Sizing
Relative sizing, also referred to as story points, is an agile software development technique. Rather than estimate project duration, the effort required to complete work is estimated relatively.
Each user story or feature request is assigned a story point value based on the required development effort. The scale of story points is arbitrary but commonly ranges from 1 to 20.
How Relative Sizing Works
There are three core steps to implementing relative sizing for a software project:
- Define a Story Point Scale: Develop a point system for quantifying development effort.
- Calibrate Story Points: Gain team consensus on how story points align to effort.
- Assign Story Points: Discuss and allocate story points to each user story and feature request.
Defining Story Points
The first step is working with the development team to define a story point scale. Common scales range from 1 to 10, 1 to 20, or 0 to 100. There may be certain anchor points like:
- 1 story point = minimal effort
- 5 story points = moderate effort
- 10 story points = complex effort
The exact values are not critical. The goal is establishing a relative scale team members relate to based on past experience with story complexity and development effort involved.
Calibrating Story Points
Once the scale is set, developers size one or more sample stories to calibrate their understanding of story points. This ground truths the numerical scale to actual development effort.
The team discusses their rationale for suggesting certain story point values until there is consensus on the appropriate relative sizes. This process uncovers gaps in understanding of scale so that there is consistency going forward.
Assigning Story Points
With the foundation set, developers now size actual stories in the product backlog by assigning story point values. Focus is kept on relative effort rather than absolute time duration.
The team discusses each story to confirm points assignment aligns with overall scale. Re-calibration occurs as needed if differences arise or new complexities are discovered.
Translating Story Points to Time Estimates
Once several sprint cycles have been completed with story point tracking, velocity can be calculated. Velocity represents the sum of story points the team historically completes within a sprint.
By dividing velocity by the working hours per sprint, it is possible to derive hour equivalents per story point. So if velocity is 40 points per sprint and there are 80 working hours, each story point may equal 2 hours.
This translation allows time estimates to still be forecasted while relying on relative sizing to increase accuracy.
Benefits of Relative Sizing
There are several key benefits development teams realize by adopting relative sizing techniques for planning:
More Accurate Planning
By stripping away time predictions, relative sizing eliminates uninformed estimates. Effort is judged based on completeness rather than adhering to duration targets.
Over multiple sprints, realistic velocity emerges. Instead of sandbagging estimates, teams improve awareness of actual throughput.
Focus on Completeness Rather than Speed
Without being constrained to hours and days, developers prioritize writing quality, maintainable code over rushing. The emphasis becomes working collaboratively to meet definition of done.
By focusing less on speed, teams take the needed effort. This leads to higher quality outputs with fewer defects and technical debt.
Adaptability
Unknowns and changes prevent projects from remaining static. Relative sizing recognizes dynamic situations requiring flexibility in planning approaches.
There is no need to re-estimate when new complexities arise. Effort translations simply adjust to absorb deviations rather than teams feeling pressured by earlier time predictions.
Putting it Into Practice
There are several best practices organizations should follow when looking to adopt relative sizing:
Getting Buy-In
Project sponsors and business leaders need education on relative estimating and why it leads to better outputs. Pilot a single team before expanding organization-wide.
Establishing a Benchmark
Use 1-2 sprints to complete stories without size assignment to determine team throughput. This will serve as a baseline for calibrating story points.
Regular Re-calibration
Run backlog grooming sessions before each sprint to size new stories and review accuracy of previous points assignment. Adjust if differences arise.
Reviewing Progress
Track both velocity trends over iterations and variance in story point burn down rates within sprints. Update size model appropriately at release boundaries.
Example Story Point Scale
| Points | Description |
|---|---|
| 1 | Minimal effort and complexity |
| 3 | Low effort and complexity |
| 5 | Moderate effort and complexity |
| 8 | Significant effort and complexity |
| 13 | High effort and complexity |
| 20 | Extreme effort and complexity |
