“We as an industry are not able to estimate well.”
When I went through my Scrum Master training a few years ago we were taught to estimate the work in the sprint planning meeting. In this case, I just did what they taught us. Recently working on an agile team I noticed we didn’t do any estimating. I thought that was odd but, just kept going. Then as a listener to Ryan Ripley’s Agile For Humans podcast, he had many discussions with people about it.
What does it mean?
Johanna Rothman does a good job of breaking down what the “No Estimates” movement is all about in this article. She starts with a summary that really shares the “meat” of the argument. “The #NoEstimates movement isn’t really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?” She points out the smaller chunks are important. Who hasn’t struggled with sizing?
As Scrum Master having sprint planning meetings I tried using planning poker and the cards. It always seemed like a waste of time. We never could make sense of estimating story points of t-shirt sizes. Once you get the hang of how small it needs to be though you can plan out quite a bit better. If only there was a magic wand!
I was recently listening to Malcolm Gladwell’s book Outliers. He discusses pilots of jumbo jets and how much information they can receive. If they focus on the wrong things they can get off course quickly. This requires the pilot to constantly monitor the dashboard that provides him or her with a lot of feedback. The pilot can become overwhelmed at times when some changes happen quickly. Well trained pilots know what to focus on.
When a team moves to using the “no estimate” approach they must ensure open feedback. Without it, like the jumbo jet, a team can get off course. As Johanna details, the Product Owner must be monitoring the stories for complexity. This will help them adjust the new stories coming in and allow them to dial the work in. The proper of alignment with team and Product Owner can deliver the value and remove the estimation needs.
Ryan Ripley did his “No Estimates” talk at the Path To Agility Conference. He touches on how we got here where we use estimation for cost on all projects. He frames Plinko the game from the Price is Right as the villain. In many large organizations, we don’t celebrate failure with experimentation. We need the safety to make small experiments and deliver things to our customers. As laid out in the Agile Manifesto we are learning from our experiments with adoption.
What is an estimate?
An estimate is a word that gets loaded with a lot of baggage. Ryan even uses the dictionary to detail what we may think an estimate is. He comes to the agreement that an estimate is a guess. “The Estimate is the work plus a buffer”, a simple and concise explanation.
Why do we need an estimate?
Some estimates are required for accountability. Perhaps your company leaders want to hold your team to the estimate. Another reason is to cover up the organizational dysfunction. This could take a long time to clean up all of the procedures and processes. Organizations can do amazing things but, they bring on complexity.
According to a report from the Standish Group 80% of projects are late or failed. That is a far cry from Garrison Keillor’s fictitious town of Lake Woebegone where all the children are above average. If a basketball coach lost a similar percentage of games he would be out of a job very quickly. Ryan says it best, “we suck at guessing.” This really puts our companies and organizations at risk.
Take some time and listen to what Ryan Ripley has to say. It is amazing how common the thinking is that most organizations use. The “No Estimates” movement has touched on something that needs to change. If you do one thing and think about how often you use estimates into uncertain things. You might be amazed at how often we are off the ranch in your work.