Over a million developers have joined DZone.

Journeying Towards #NoEstimates

The recent #NoEstimates movement has brought increased visibility to an issue that many find contentious, but they are required for any professional software.

· Agile Zone

Reduce testing time & get feedback faster through automation. Read the Benefits of Parallel Testing, brought to you in partnership with Sauce Labs.

I’ll admit that until I discovered planning poker many years ago, estimating was not my favourite thing to do. Even though I had experienced some estimating success, there was an underlying realization that every time I estimated, I was rolling the dice. It is probably why #RelativeEstimating through planning poker was such a big relief to me. The game was still rigged, but treating estimates in a relative way allowed me to be wrong early and adjust so that my odds of winning at the end were improved. It was a useful paradigm shift.

The recent #NoEstimates movement has brought increased visibility to an issue that many find contentious. Some assert that estimates are required for any professional software project. Others declare that estimates are harmful enough that we must find a way to reduce or eliminate them altogether. Personally, I’ve found the discussions about #NoEstimates valuable enough that I decided to do some research and then run some experiments of my own in order to move in that direction. Here are the results of two of those experiments:

Experiment #1: Relative Points

For my first experiment, I decided to look at our data. We had already been using planning poker for some time, and we were working with a client who had requested that we track our actual hours per user story. (We don’t always do this for various reasons that are outside the scope of this article.) The question I was trying to answer when looking at the data was this:

Will our actuals hold true to the relative sizes we had assigned them?

That is – if a story worth 1 point has an actual average effort of 10 hours, will a story worth 2 points have an actual average effort of 20 hours, etc. For this project, we used points of 0.5, 1, 2, 3, 5, 8, 13, and 20. The “Actual” hours in the graph below are divided by a number so that the Y axis is similar. Here are the results:

Project 1

So, there it is – we were almost perfect at relative estimating for that project! That belief held firm right up until the next project:

Project 2

That’s right, in “project 2”, our 1 point stories took longer on average than our 8 point stories. Still, the relative actuals of stories with points 2 through 8 weren’t too far off and we held on to some belief that the 1 pointers may have been an aberration.

Enter “project 3”:

Project 3

“Project 3” took away any remaining belief about the accuracy of our points estimating by giving us what looked like completely random results. Roll the dice.

Experiment #2: Points to Count

However, this wasn’t enough to convince me to run away from the data. By this time, there were multiple reports of people comparing the sum of their iteration velocities to the count of stories that were being completed. That seemed like a reasonable experiment, so once again I turned to the data. This time, the question I was trying to answer when looking at the data was:

Is summing the number of points per period just as useful for planning 
as counting the number of completed stories per period?

At this point we already had data for 3 projects so we could start graphing right away. Since the initial results were favourable, the graph below shows data from 8 different projects over the course of more than a year:

This graph clearly illustrated to us that we could stop estimating in points and instead just count the number of ‘done’ user stories for planning and forecasting purposes. It has allowed us to move closer to #NoEstimates by removing one more estimating step. We no longer need to use planning poker to agree upon a number – instead we keep slicing stories until they are ‘small enough’.


In summary, these two experiments didn’t lead us to stop estimating altogether, but they have definitely moved us in that direction. We can still use data to help us forecast and plan, but we are less dependent on estimates to do so. This helps us reduce some of the dangerous effects of estimates, with the additional benefit of getting to spend more time delivering value.

As a bonus, these two experiments nudge us towards continued process experimentation - something I'm happy to endorse.

The Agile Zone is brought to you in partnership with Sauce Labs. Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure.

agile,project estimation,project management,estimation

Published at DZone with permission of Steve Rogalsky, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}