Are you familiar with relative sizing and estimation? They are are generally accepted Scrum practices. Even though many Scrum teams do some form of estimation, it can be a confusing topic to explain. Why are these oft-used practices so difficult, and how can we broach the subjects with our own teams to ensure we’re on the same page? To help us answer these questions, our own Ty Crockett gave a brief presentation and then opened the topic further for small group discussions.
Ty helped us start at the beginning: why do we estimate? There are many possible reasons why estimates may be wanted. Our stakeholders want estimates for forecasting purposes. We can use estimates as an indicator for risk and to highlight where we need to have further conversations. Perhaps most importantly, having team members estimate work can gauge whether or not we have a shared understanding of the work. And in some cases, we simply want an idea of how much effort something is to get an idea of how much we can do.
With that in mind, we moved onto the next challenging question: what is a story point? The short answer is that it’s the unit of measure commonly used for relative sizing. Story points allow us to compare items to one another to determine their size. Hours are problematic because the focus is often on precision rather than accuracy, and team members might complete the same tasks at different rates—how could a team ever agree on estimates in hours? As Mike Cohn notes, “story points are helpful because they allow team members who perform at different speeds to communicate and estimate collaboratively.” When estimating in story points, a team might consider complexity, effort, annoyance, or skill; the important thing is that the team members agree on what factors to consider when estimating.
Now that we know how big things are relative to one another, we can look at how much a team can get done over time. We can track how much the team is getting done each sprint, look at velocity trends, and forecast how long it will take to complete work in the product backlog. And we can do it with an easy-to-understand graph!
Those are the basics of relative sizing and estimation, and Ty provided more depth to the topic during our meeting. His slides are available on the DFW Scrum meetup site. Ty is an active member of DFW Scrum and is happy to talk more about relative sizing and estimation.