Part One – Story Point Estimation in Scrum: Does it Still Work?
We all remember the first time we read The Agile Manifesto. It brought out the “Hell-Yeah, Man!” in people. Its values motivated and empowered teams. It created deeper value for customers and kept the malarkey out of software development. Stuff got done.
Fast-forward to 2018, and “Houston, we have a problem.”
Scrum works, and stuff still gets done, but… Rapid adoption of Agile and Scrum has created a monster for enterprise-level planners responsible for Epic/Portfolio Estimation. The industry took a practice that was created for small teams working closely together in a uniform way – then retrofitted it for the masses.
One Scrum team became multiple teams, or dozens, each with their own understanding of “what is a Story Point?” Today, no two teams have the same experiences, infrastructure or skill sets; thus, no two teams define Story Points the same.
All of a sudden you have high-level managers trying to divvy up the Epic backlog based on 25+ different interpretations of a Story Point. The more teams that are working on the same product, the bigger the mountain is to climb. [Pardon the irony]
What would those 17 guys at Snowbird say?
Organic Scrum would say don’t even try to estimate an Epic backlog because it is effort wasted and full of inaccuracy. Detail will inevitably change, and things will get reprioritized last minute. But tell this to the Epic/Portfolio Manager on the hook to provide a roadmap timeline for funding, and you’ll get the stink eye!
Epic estimation deviates from the days of single Scrum teams when Estimation was super straightforward. Dependencies, available skill sets, and tools to complete the work were rinse-and-repeat. Individual team members knew each other’s capabilities and limitations. When someone said a Story was five points, everyone on the team knew exactly what he/she meant. As Scrum grew legs, the meaning of “five points” grew increasingly fuzzy. The more teams that were added, the harder it was for managers to interpret Story Points. At 10 or 20 Scrum teams… Utter Planning Chaos! If there is no center line for estimation, the whole team can become unstable very quickly.
It raises the question, “Are Story Points still an effective way to estimate Epics in Scrum?”
Some argue yes, you can still use Story Points with the right scaling framework. Others believe enterprise Scrum has wandered too far from Agile principles because the work cannot break down. As Scrum scales up, how can teams establish a consistent standard for estimating Epic backlogs so that high-level managers, stakeholders and other teams are all on the same page?
The Pros and Cons of Story Points
We had a little internal debate and came up with these pros and cons to using Story Points for high-level Estimation in Scrum. Read the list, then send us your feedback on the topic. What do you disagree with? What are we missing?
Pro: Story Points help break down large backlogs.
Story Points can work well as part of a scaling framework such as SAFe and NEXUS. These frameworks provide scalable estimation techniques for breaking down work at the Epic, Program and Portfolio levels:
- SAFe looks at the big picture of how work flows from Product Management through Governance, Program teams and Dev teams, and out to customers.
- NEXUS is a more bottom-up approach that focuses on unifying multiple Scrum teams working on the same product. Through transparency, NEXUS seeks to protect and strengthen connections between teams and keep scaling as uniform as possible.
From a tactical perspective, one technique recommended by coaches is to hold the team who did the Estimate accountable for meeting the Estimate. That same team always works on the same module so that the meaning of Story Points remains clear and consistent from Sprint to Sprint. The downside is that your capacity-per-module within each release is fixed, since teams can’t work across modules. You are locked in with the amount of work that can get completed in a release for each module.
Another approach is to designate one or two representatives from each Scrum to join a formal Estimation session. These ambassadors can make decisions about story sizes without taking the whole team off their jobs. This technique assumes that each representative has knowledge of how their team defines a Story Point, so they can share, discuss and find common ground for estimating stories. The downside here is that each Scrum team has to trust and live with whatever their chosen ambassadors come up with for each story Estimate. Also, you run the risk of ambassadors getting influenced by the Estimation approach of ambassadors from other teams.
Con: This is not Scrum!
Hardcore Agilists will argue that these techniques do not represent Scrum. If the same team always works on the same module, does this threaten scalability? What about the concept of self-managing teams? From a capacity perspective, limiting a team to one module does not promote scalability. It is no longer scaled agile. From a team perspective, if you only have one representative Estimating in a vacuum, you risk team instability because either (1) the representative did not have the right knowledge about a particular dependency or integration issue, or (2) he/she could become influenced by another team’s experiences which do not match how their own team works. In either case, people fear things are becoming too top-down, causing Velocity gaps and a big ugly mess in the PMO.
Looking for a partner for software development?
Stay tuned for next’s week entry! Part two will cover pros and cons of story points to set a critical baseline for obtaining budget, and whether they imply more than what Scrum intended them to.
