Table of Contents
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: