Part Three – Story Point Estimation in Scrum: Does it Still Work?
To continue from the second part in our series, let’s dive into the final Pros & Cons of Story Point Estimation:
Pro: Story Points empower teams to improve quality.
Story Point Estimation gives Dev teams empowerment and control over quality, and that’s something that needs to be preserved no matter how big the engagement or project. A core principle of Scrum is ‘self-managing teams,’ where it is the team who decides if/when there’s a need to slow down in order to meet the Definition of Done. A team may have to slow down in order to improve code quality and lower technical debt (e.g., important defects left open, ignoring code refactor, etc.).
Organizations can use Story Points as a method to track, analyze and challenge areas of uncertainty, which are only growing bigger. DevOps, Automation, CI/CD, IOT and the demand for digital apps continue to accelerate and complicate delivery; defects are becoming more costly, while end-users expect more features faster. Story Points help teams to anticipate Dependencies earlier and budget enough time to improve quality Sprint over Sprint.
Con: People don’t understand Story Points.
As we mentioned earlier, non-technical stakeholders and managers who came from waterfall mistakenly equate or try to translate Story Points into hours/effort. They see a number, and suddenly it’s a definitive target. Agile says don’t do it, but humans do anyway. The bigger the chunk of work being planned in hours, the deeper the “you-know-what” managers will step in.
A STORY POINT IS ONLY UNDERSTOOD BY THE TEAM WHO USES IT.
Let’s say a manager runs up against a large module and realizes there is a gap in how the backlog was sized across multiple teams. Now teams must get together to re-estimate and agree. Agilists will say, “You can’t do this! Let the team size their own way!” But for the manager, this is a big problem. He/she made a commitment for a release date, but due to varying interpretations of a Story Point across teams, Velocity is off. One team didn’t meet their expectations, and the whole team becomes unstable. The stakeholder doesn’t give a whoop. They just want what was promised.
Truth is, a Story Point is only understood by the team who uses it. Even within a team, Story Points can be objective from one member to the next. A good Release/Epic/Portfolio Manager must consider that every team has their own flavor of technical skills, experiences, infrastructure availability, etc. They must view a Story Point estimate as a common denominator for “good enough”. That’s it.
Pro: Story Points can help facilitate continuous improvement.
In the scenario described above, teams must get together after every Sprint to inspect and adapt their Estimation process. Scrum is about learning. Adaption. Challenging each other. Get everyone together in a regularly scheduled Retrospective session to look at every aspect of your Estimation processes transparently. Talk about gaps, why they happened, and how the team can get better:
- What dependencies can be reduced next time to prevent schedule slippage?
- Did we establish enough feedback loops to be able to respond to change?
- What cross-functional integration issues should we anticipate next time?
- How can we leverage collaboration and bottom-up intelligence to improve the accuracy of Story Point Estimation next time?
- How can we share these learnings with managers and other teams in the organization?
An Example
We had a large customer migrate from a functional waterfall-based team structure to 10+ cross-module Scrum teams. The Board needed to see a Roadmap, Timeline and high-level cost with contingency buffer for the entire MVP backlog across multiple modules. We had the customer pull one development lead representative from each team to form an Estimation Team, which was asked to estimate the MVP backlog into Epics using t-shirt sizes S – M – L – XL. Once the Epics were put into sizes, the Estimation Team picked two sample candidates from each size for the Story Point Estimates. Son Tang, KMS Sr. Engineering Manager, recommends choosing the simplest – albeit well defined (or concise) – Epics for the sample candidates.
Next, the sample Epics were assigned to the Scrum teams to be worked on. The assignment was randomly done at this point, since no single team was an expert at any particular module or domain. The Estimation Team members went back to their own Scrum teams for Sprint Planning, where each team was encouraged to challenge their ambassador. Is the information accurate? Are there dependencies which he/she missed? And of course, the team had a Retrospective after the Sprint. Each team worked the Epics across two or three sprints with Story Point Estimation. At the end of this, the teams had a clear baseline understanding of their average total Velocity, as well as total Story Points, for the entire backlog. The timeline was calculated from an average Estimation by consensus of the group and used to define baseline Story Points Velocity for the remaining backlog.
At the end, teams were able to give the executive team more accurate estimates for Timeline, Cost and Story Points capacity within six weeks (three sprint cycles). The six weeks were well worth the wait – happy team, happy board, happy customer!
In terms of the managers, Son says it’s best to provide duration of the Timeline to the customer or stakeholder. Stick with the base information, so that inquiries about the Epic can be updated accordingly. You can always add or decrease teams to maintain the right capacity depending on the Timeline, but your approach should remain the same. And again, inspect and adapt any gaps in your Estimation early and often.
So What Do YOU Think?
Have Story Points become too misunderstood/misused to use in enterprise Scrum? Can we break down high-level projects during Epic Estimation in a way that is consistent across many teams, or does scaling Scrum compromise the fundamental values of Agile?
KMS has led many large/global organizations in scaling Scrum. There’s nothing we haven’t seen. If you need help with software development or scaling Story Points for Epic Estimation in your Scrum organization, contact us.
