Part Two – Story Point Estimation in Scrum: Does it Still Work?
To continue from the first part in our series, let’s dive into the next Pro & Con of Story Point Estimation:
Pro: Story Points set a critical baseline for obtaining budget.
Story Points give managers a baseline data point for estimating and calculating Velocity across multiple teams, which everyone knows is a necessary evil if you expect to get funding for any large project.
In waterfall, managers could talk to stakeholders in terms of numbers (hours, days, weeks, months). Everyone could understand numbers. Nothing took less than one hour. When the Internet and Agile came along, hours could no longer be used because so many Tasks could be completed faster than the meeting would take to plan it! On the other hand, some stories have longer Timelines and Dependencies which need to be documented with stakeholders. Story Points give managers a baseline idea of where a story falls on that spectrum, relative to a team’s past experiences, and how they are packaging it.
Our CTO, Kaushal Amin compares Epic Estimation to asking how many boxes (Effort) it would take to handle your move:
Company A tells me they can get the job done in 150 boxes. Company B can do it in 100. On the surface it seems like Company B is much more efficient, but what if Company B is just using bigger boxes? The effort required to do the work could be exactly the same; it’s just that the companies estimate in different ‘bucket sizes’.
At the Program level, you can’t enforce the same bucket sizes across teams. Story Points can, however, help teams break down work to the smallest functional piece so that, over time, high-level planners can learn and understand what bucket size each team is using to estimate.
Con: Story Points imply more than what Scrum intended them to.
That same Pro is also a Con here. Story Points were never meant to become a performance measure. Story Point Estimates are just that, estimates; not forecasts. Yet, they are being used to compare the capacity of different teams against each other.
Scrum never intended to hold teams to a “do-or-die” commitment. Story Points represent a “good enough” guesstimate of the scope involved in a project. If the whole intent of Agility is to allow organizations to respond to change over following a plan, then we’re not getting the full value of Scrum.
Make sure to check back with us next week for our final post on story point estimation. Part three will cover the pros and cons of story points empower teams to improve quality and that certain roles don’t understand story points from a business perspective.
Partner with KMS for your next software development project.
