Don’t Give Up on Story Points (Yet)
If you’ve been an agilist for a while you’ve probably seen the debate on estimating items in your product backlog. One of the common methods is for the team to estimate in “story points”. These estimates are unitless. The number doesn’t reflect “days” or “hours”. It’s a relative estimate to a typical product backlog item to determine larger, smaller, much larger, etc. The numbers are just there to make math easy to see how large is your product backlog.
From my experience, this is where good training and coaching makes a big difference. A good agile trainer needs to give the history and explanation so the team appreciates the advantage of estimating “quickly and reliably”. If your team follows scrum, then they probably do regular backlog refinement where the team reviews new product backlog items and estimates them. In that event, you don’t want the team to deconstruct the new product backlog item into a mini Gantt chart to know exactly how much time it will take. At that point the team may not even know what sprint it will be committed.
Instead, using an estimation method that is quick and reliable will help with answering the following:
- Is the item too big to bring into a sprint?
- Does the team understand what is being asked of them? (If they can’t converge on an estimate then there isn’t alignment)
- Could the story be “split” into smaller stories (hint: smaller is better)?.
So for you agile coaches and trainers out there, please help new teams and even existing teams to understand the value of how quick and reliable estimation can help a team to fulfill the scrum pattern of teams that finish early accelerate faster.
