Estimating Stories
Tomoe Magnuson
Last Update hace un mes
Velocity Tracker projects use a Power of 2 point scale (0, 1, 2, 4, 8). This system helps teams estimate work in a structured way, emphasizing the increasing complexity of larger tasks.
Best Practices for Estimating Stories
Break Stories into Small, Consistent Sizes
To maintain predictable velocity, break down stories into small, consistently sized tasks. The smaller the story, the more predictable the work:
If a story is estimated at 2 points and you're off by 100%, the worst case is 4 points.
If a story is estimated at 8 points, the variance can be much higher, making velocity swings unpredictable.
Encouraging teams to deliver fine-grained stories frequently improves predictability across projects.
Keep Estimates Relative Across Teams
Story points should be relative, regardless of who is working on the task:
A 2-point design story should represent the same effort as a 2-point development story.
Many teams use small (1), medium (2), large (4), and huge (8) as a reference for effort.
Once a scale is chosen, it’s important to maintain consistency in estimating effort.
Maintain Consistency in Effort-to-Point Mapping
Each team can define what point values mean in terms of effort, but the key is consistency. A well-defined estimation process, coupled with keeping stories small and granular, results in more predictable and stable velocity.
Tip: If a story is estimated above 4 points (or considered a large effort), consider breaking it into smaller tasks.
Estimating Bugs, Chores and Release
Bugs and Chores do not receive point estimates in Velocity Tracker. They are considered part of normal software product overhead—they emerge over time, and are continual overhead, an ongoing cost of doing business.
Releases are milestone markers that allow your team to track progress toward concrete goals (e.g., stakeholder or investor demos, software launches, etc.).
All stories for a milestone or release should go above the marker for it. Releases only have unscheduled, started and accepted states (Releases are automatically placed in the started state upon being created or dragged in the Backlog).
Automatic velocity calculation accounts them as a built-in cost, and estimates how much business-valued work can be completed each iteration. This lets you focus your planning on business value, risk, and priorities. Therefore, Bugs, Chores and Releases are not estimated.