An estimated backlog helps a team communicate to stakeholders how long a product will take to build, or approximately when a given milestone can be reached. There are two main strategies for estimating a backlog: estimating tickets by hours and estimating tickets by complexity using a technique like story points or shirt sizes.
Estimations by hour make a lot of unspoken assumptions: which steps are included (do clarifying conversations with stakeholders, QA, deployment time, automated testing, etc. get included?); who is doing the work (since one developer may be faster than another); are estimate bumped up or padded based on chronic over/under estimations in hours?
I prefer to size stories based on their complexity. In this video, I explain story points as a way to do so. When stories are sized based on complexity, the question isn’t, “How many hours will this take to build?” but rather, “Is this more or less complicated than this other ticket?” This is an easier question to answer with certainty (adding a responsive image field to a page may be harder than adding a simple text field, for example).
“Story points rate the complexity of a task, relative to the complexity of other tasks.”
Over time, a team’s velocity—or the amount of complexity they can build in a given sprint cycle—will gravitate toward a predicable average. It then becomes the work of the Scrum Master and Product Owner to watch the team’s progress and use the estimated complexity and velocity to extrapolate how long a backlog will take.
Acknowledgements of CC Content
Thank you to the generous content creators who freely offered their icons and music used in this project.
- Airplane by Iconic from the Noun Project
- Motorcycle by Guillaume Kurkdjian from the Noun Project
- flatbed truck by Sergey Novosyolov from the Noun Project
- Tshirt by Ema Dimitrova from the Noun Project
This post originally appeared on tsmithcreative.com, February 28th, 2017.