How can you get started with #NoEstimates when you use Story Points to estimate right now? Easy:

Just replace all story point values with “1”. Then use all the analytics you used before to make predictions and do planning.

Ok, that’s a grossly oversimplified view on #NoEstimates, but it’s the gist of it. You can start now.

Instead of using “1” as your new, only story point value, you could als use the average story point value of your last [n] user stories. Then the statistics will be somewhat comparable. But this is not necessarily a good thing!

But we need estimates!

But what do you need them for?

  • To calculate your throughput
  • To know how much can be done by a certain date
  • To get a feeling about how big a project is
  • To convince somebody else you are not lying about expected effort
  • ...

Could you get all this with a simpler method?

Under certain cercumstances you can achieve all of this by just counting stories (instead of estimating them).

Often you will not even lose any precision in your predictions - Or even gain precision! I have experienced this when I analyzed a lot of past data at a customer I was consulting some time ago. Their average story estimates were very stable over time. By just counting stories, they would not have lost any precision, so their average estimation error must have been very stable too.

But there's estimates everywhere!

I may be missing something, but everything I’ve seen about #NoEstimates uses estimates somewhere. Sometimes just in a different way.

-- Giovanni Asproni

The fact that you have replaced all estimates with “1” does not mean that you don’t have estimates anymore. The “ones” are still estimates. The predictions you make based on your throughput are estimates: Estimates of what can be done by which date. And there are others.

So #NoEstimates does not remove estimates. It just makes them much simpler. And it makes it harder for outsiders to turn them into a commitment.

What about different planning horizons?

Some teams use themes and/or epics to describe larger pieces of functionality. They will split them on demand into smaller stories. How do you count those huge chunks when everything is a “one”?

You could:

  • Not count them. Then your planning horizon is probably quite short, because you don't want to slice stories too far ahead in time.
  • Count them as "one" in a different statistic. That makes statistics a little bit more complicated.
  • Just count them as "one" in the same statistic as the small stories. That was what Vasco Duarte suggested to me.
  • Don't count the small stories at all. After all, the big features are what matters!
  • ...

You can have both!

The cool thing with #NoEstimates is that you can just try it without causing any damage. It is completely safe to fail. Just do both: Story point estimates and #NoEstimates and compare their advantages and disadvantages.

Here is how you can do this:

Step 1: Analyze your past data again. Count the user stories again as if they all were ones, create your statistics again. (You do have past data and statistics, right? No? Let’s talk.) Then compare how well #NoEstimates would have predicted your throuput and what you delivered when.

Step 2: Run in parallel. Now, for some time, you can run story point estimates and #NoEstimates in parallel. The #NoEstimates statistics are really easy to generate, so that will not take much time. Experiment with saying things like “We need to do 12 Stories in the next 3 Sprints, on average we complete 5 per Sprint so we should be fine.” instead of “We need to complete 38 Story Points in the next 3 Sprints, on average we complete 11 per Sprint so we should be fine.”

Step 3 (absolutely optional): Stop doing story point estimates. Only do so if it makes sense for you.

Just try it

So, just try it for your team. It costs almost nothing. As a ScrumMaster or team member, you can probably do Step 1 in a single lazy afternoon. Then talk to your team.

Do you need help with getting started? Or do you have any questions? Just ping me!