How One Team Went #NoEstimates

This post is mostly a case study on one team. This is a team that I led for a couple of years. We challenged our way of working often. We changed our way of working often. We tried out changes and kept the ones that improved the rate at which we were getting things done and the quality of the work that was getting done. In early 2015, after being exposed to #NoEstimates, I decided to try the approach with the team.

As a traditional scrum team, we used to observe all the major scrum ceremonies. The major ceremonies though, morphed and changed a lot for us over time. In April 2014, 8 months before our "No Estimates" move, we had already stopped doing sprint planning. We had a pretty steady velocity of about 30 points. Instead of spending 2-3 hours estimating and planning out each sprint, we would put an estimate on a story as we were about to start work on it. We had one rule with this "just in time" estimation - We would never work on a story that was estimated at more than 5 points. We discovered two advantages with this approach. First, instead of taking the entire team offline for half a day, we would only take 3-4 people offline for 5 minutes per story at different points of time during the iteration. Second, it allowed the product owner to reorder the priorities mid-sprint. We were fine with any work that has not yet started being reprioritized. Working on a product that is affected by local, state and federal regulation changes, this allowed the product owner to change priorities, whenever any government changed its mind.

By the middle of 2014, we had discovered that our no-planning experiment was working out very well. To be clear, by no-planning I mean not doing sprint planning. We still had dates to hit, we just realized that we were just as predictable, whether we did sprint planning or not. January 2015 is when we first started questioning if the estimates themselves were providing any value. I pulled up the numbers from the last four iterations(which included the Christmas and New Year's breaks) to take a closer look at what value the estimates were giving us. Below is the breakdown of the points per iteration and points per story.

What the numbers told us here was that if we had kept the same rules (don't work on anything that takes too long) and estimated everything as 2.5 points, we would have achieved the same results. Based on this analysis we did the following (this is an excerpt from an email documenting the changes) -

1.          We bring in stories that are as small as possible(just as we do today)
2.          If any story looks like it will take the dev + qa kicking the story off more than 6 working days to complete, then split the story down.
3.      .   For reporting purposes consider all stories to be 2.5 points.

Eventually, as the organization got used to fewer teams reporting points and more reporting story counts, we got rid of bullet number 3 as well. Our Estimation discussions became sizing discussions. We went from "How many points is this story?" to "Is this too big to work on?". This, surprisingly made us more predictable in terms of the number of items we can get done over a time period. It also gave our PO the ability to pivot more frequently.

As a matter of coincidence, our Product Owner, in his numbers used to multiply the stories he had in a feature by 2.5 to figure out roughly when that feature would be done based on our velocity of 30 points per sprint. We also took that indirection away. He wasn't multiplying things in his head and we were not spending time estimating. We were both simply counting stories. Challenging the norm, in this case, seemed that it was making things easier for us, without having an adverse effect.

Without deviation from the norm, progress is not possible. -Frank Zappa

I am personally a big fan of sizing, finding out if something is too large and needs to be broken down. I am no longer a fan of estimating. Story points are a level of indirection that the entire Agile movement could have done without. There is usually the argument that they are a better way of getting teams used to sizing their work. I agree, they are, but I am sure there are better alternatives out there to introduce sizing. Removing story points did not change our throughput or predictability, so, in lean terms, they were a form of waste. I would highly recommend doing the math for your teams and finding out if story points are providing you with value. Maybe they are, but if they are directly and consistently in proportion with story counts, most likely they are wasted effort.