During my early days managing a product team, Sprint Planning meetings were the longest. They typically lasted 3-4 hours every two weeks, with most of the time being spent on estimation.
The Sprint Planning, Ideal Days and Story Points
The flow of our planning process involved discussing ticket details, sharing estimation points, debating, finding an agreeable estimation point, and moving on to the next ticket. This cycle repeated until we reached our sprint velocity.
Unfortunately, this process did not result in predictable delivery. Stakeholders were upset whenever we informed them that the timeline needed to be extended, and worse, the work often took longer than the estimations.
We tried using ideal days and then switched to story points, but the same results occurred.
When using ideal days, we added a buffer by multiplying the estimated ideal days by 1.5.
When using story points, we used Fibonacci numbers (0.5, 1, 2, 4, 8). If a ticket was estimated as a 4 or 8, we further broke it down into smaller sizes. This technique helped us become more aware of the complexity involved.
Over time, our estimations improved, but the time spent on Sprint Planning was still stressful, and the return on investment of estimation did not justify it.
The Doubt
Upon analyzing our process, I identified a pattern: new ticket → estimate as 4 or 8 story points → break down into multiple 1 or 2 story points → another new ticket. This cycle repeated over and over again, and we achieved clarity in planning only when all tickets went through the same cycle.
This made me question: why do we begin with estimating and what purpose does it truly serve?
The Alternatives
Further research revealed that the work still takes the same amount of time regardless of the accuracy of the estimate, and estimation has been removed from Scrum.
Ron Jeffries, the creator of Story Points, even shared his thoughts on Story Point being misused. Ron Quartel introduced four alternatives to story pointing: Blink Estimation or Wisdom of Crowds, Throughput or Story Counting, Monte Carlo Simulation, and Bayesian Probability. Out of these four, throughput is the simplest idea.
Here are some tips for measuring throughput:
Not all tickets are the same size, and that is okay. The key is to not overthink.
Measure cycle time together.
Remember the Law of Large Numbers, which states that as a sample size grows, its mean gets closer to the average of the whole population.
Conclusion
The traditional estimation methods, such as ideal days and story points, did not yield the desired results. This led me to question the necessity and purpose of estimation in the planning process. I propose exploring alternative approaches, such as throughput measurement, together with cycle time. By adopting a more streamlined and simplified approach to planning, the team can achieve better results and enhance their overall productivity.
References
[1] "11 Laws of Software Estimation for Complex Work" by Maarten Dalmijn - https://betterprogramming.pub/11-laws-of-software-estimation-for-complex-work-c23b6e5e9ec4
[2] "Estimation has been removed from Scrum" - https://medium.com/serious-scrum/how-estimation-got-removed-from-scrum-87ec0404f3c0
[3] Ron Jeffries on Story Point misuse - https://ronjeffries.com/articles/019-01ff/story-points/Index.html
[4] Ron Quartel's alternatives to story pointing - https://medium.com/swlh/why-story-pointing-needs-to-die-e60a775f9d37
[5] Law of Large Numbers - https://www.investopedia.com/terms/l/lawoflargenumbers.asp