The team started tracking their estimated number of story points in a given sprint to compare them to what they deliver. In P3 Sprint 1, the team estimated that they’d deliver 40 points, and instead, they delivered 35.
Note: This covers all of their work including infrastructure, maintenance, features, and bug fixes.
What can we learn from this? Initially, a few things come to mind:
- Points are an imprecise measurement of effort.
- The team is still developing the habit of breaking stories up.
- The smaller the story, the more accurate its estimate.
Why go through all the trouble of estimating?
Breaking stories down better conveys the work the team is doing. They estimate, in part, so they know if a story is too big. In an ideal world, all stories would be one-point stories. That doesn’t mean that product owners should only submit very small requests. Ideally, the team would be able to break the work down into very small increments. The goal is to then break it down so you can see their progress as the team works.
For example, let’s say a three-point story would take five to six business days to complete. That story will sit in a “Started” status the entire time it's worked on. If it's broken down into several one-point stories and delivered every one or two days, you’d have better insight into its progress, and the team would have more accurate estimates. It’s not always possible to break work down this way, but it’s a worthy goal. You can check out Scoring Descriptions for Product Owners to see how the App Dev team scores stories.
