Why We Kicked Estimation Meetings (And Maybe You Should Too)

Ugh, it happened again.

It’s Monday morning, and I’m sitting down with my first cup of coffee. I send my first Tweet about #NoEstimates and I got challenged by some people who did not fully internalize the idea behind the #NoEstimates movement.

It seems to be a never-ending battle: Should we run Estimates or #NoEstimates in Agile?

Discussions tend to go extremely deep. All too often they go into the wrong direction and result in a “do-or-die” fight. Little space for a constructive chat, don’t you think?

It can be highly annoying, especially on Twitter when people start writing tons of messages separated in various Tweets. Twitter is just the wrong platform to have detailed debates.

In this article I want to point out my personal statement why we got rid of Estimation Meetings, and why you should consider it too!

#NoEstimates as an Experiment

One of the standard procedures in Scrum is the Estimation Meeting. That’s the moment where the entire team comes together in order to estimate different items on the backlog. It’s very common to use Story Points for that, although you could use any other measurement unit as well. In the Sprint Planning the team uses the attached points on the items in order to commit on a certain amount of Points for the upcoming Sprint.

When I started with Agile, I first thought: “Hey, cool. Finally I am getting rid of stupid man days”.

BUT … after a time, growing in Agile with great leaders and mentors, I realized that in different projects and companies, story points didn’t work out either. There were constant re-estimations within a running sprint. After a while team members started to doubt that story points reflect reality.

Another scenario we experienced was that after shipping some features, user feedback gave us so much insights that all the estimates we made on previous items were totally useless. Variables have changed!

I started to re-think and jumped into very eye-opening discussions with like-minded Agilists who experienced similar moments. I joined the #NoEstimates movement, read some enlightening books and after a week I asked my current team to skip the time-consuming Estimation Meeting. Everybody agreed instantly and we started this change as an experiment.

What we’ve learned

The quicker it’s in the hands of your customers, the better off you’ll be.

That’s what we’ve learned most out of our experiment. Instead of wasting time in Estimation Meetings, we put much more effort in identifying the right metrics for the features (whuuu, believe me, that’s not easy) and a direct real life contact with our users. With the right tools, sense and communication channels we received insights on a system level.

We also learned that features who didn’t pay off, have to be killed because it costs to maintain them. That’s the power of good metrics, they gave us a clear Keep-or-Kill criteria.

So we did not estimate a single item on the backlog. Nevertheless we were able to navigate through a big uncertainty. I believe that’s what every organization has to learn, inspect and adapt in a very short cycled framework. Market is complex and highly dynamic. That’s why variables change extremely fast after you ship a feature to your user base.

NoEstimates doesn’t mean that you have less work or that you don’t have to discuss about what you’re going to do next. That’s a huge misconception. You will rather jump much deeper into an entrepreneurial point of view. Our team started to discuss and argue on an economical level which helped us to generate much faster small assumptions and experiments with a concrete metric. We called it the Minimal Valuable Experiment (MVE).

Sometimes, you should break some patterns

Sure, there is no single Strategy that works for everyone. Software Development, Production or Service orientated Organizations have different challenges, technologies and target groups. However there are some aspects that most companies should have in common: A strong vision as a direction giver and a rough roadmap that can be used as a soft guide. However the roadmap should not be written in stone. We learned that some promising ideas on the map weren’t good enough for our users, so we had to kick them or heavily modify them.

I know that many people will criticize me for my point of view … but hell, in our experiment we were able to deliver more value for the customers and yes, we even earned more money after a very short period of time. Small and iterative changes made an economic impact in our business.

And let’s be honest, instead of following patterns, discussing about scientific management terms, it’s better to break some schemes from time to time … if this is what generates more money in my pocket, why should I care about critics?

If I tell you that by running a small risk in your organization, chances aren’t so bad that you will increase your income in a very short time, wouldn’t you try it out? That’s exactly what we did!

And you can do the same!

Read this book .. and this as well. Ask some #NoEsimates Gurus on Twitter, LinkedIn etc. Then you have enough information on how to run this low-cost experiment with your team.

What do you think?

I’m open for questions, ideas and critics. Just drop your thoughts below!

1 comment

Leave a Reply

Required fields are marked *.