What Can We Do To Improve Our Point Based Estimates?

Or “How do we improve our point based estimates and resultant velocity?”

Backgound

For many organizations, we focus on making Story Points a true measure of the relative size of the work, and velocity as the true capacity of the team to complete requirements to done.

Most organizations settle on a team-by-team Story Point based approach to estimate work. These estimates are used to understand how much the team can deliver in a Sprint / Iteration. The capacity to deliver working code, called the Team Velocity is determined by summing the Team estimates of User Stories that are Done in a Sprint / Iteration.

We come to rely on this information for a number of uses. For example it helps us plan and understand how Teams are doing. A number of Teams have reported issues in both calculating and using Story Points. The following approaches were pulled together from 2 primary sources:

We gathered up this information from the Teams. Review of the numbers raised a number of questions. The subsequent discussion highlighted both issues and potential solutions to those issues.

A number of Teams reported that velocity in release sprints is different to production sprints which means that historical velocity cannot be easily used to determine likely release date or that defects there is a difference in the size of the story when you compare defects versus new work. Again subsequent discussion of the issue with Scrum Masters highlighted issues and potential solutions.

This page is a summary of what was discovered on the approaches Teams have used to improve their estimation process.

What Estimation Practices Can We Try?

Here is a list, in no particular order of things that someone has tried or suggested as a way of improving something about the estimation process:

Establish a "Done" Definition For a Story to be READY for the Team

Team Has Right to Reject Stories for Estimation That are Not READY

Establish a Keystone Story

Establish Points Guidelines for Each Point Value

Establish Typical Sizes for Typical Work

Establish a "Things That Matter" Matrix

Give Default Estimates for Classes of Work and Then Work Exceptions

If It Involves Work by the Team Then It Should Have a Non-zero Estimate

Only Use Fibonacci Sequence Numbers

Review The 5's To Make Sure They Are The Same Relative Size

Split Every Story Until It Represents a Small Common Size

Estimates Are Based On Current Knowledge

Track Accuracy of Estimate Metric

Track Accuracy of Commit Metric

Track Adopted Work Metric

Track Found Work Metric

Use Ranges to Understand Risk

Want to Know More?

How Do We Use Points to Estimate?