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!
My experience is that estimation meetings sucks. The truth is you just don’t know what’s going to happen that far in advance. #noestimates
— Dominic Krimmer (@dkrimmer84) August 21, 2017
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?
Crazy?
Contradictory?
I’m open for questions, ideas and critics. Just drop your thoughts below!
Hi Dominic,
Thank you for sharing your experiences and thoughts on the topic of estimating. Highly appreciated. I do have a few observations and viewpoints from my side that I wish to share with you.
It starts of with two expriences from your side involving estimates:
1. “… 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.”
The fact that you constantly have to re-estimate, isn’t this a symptom of something much bigger? My instant response to above would be that the story is not clear enough and that it first should be further refined before even thinking about estimating it again. When such discussions start, why did you pick up the story in the first place? As a result I don’t see how estimating is the issue here.
“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!”
Again basically the same remark. Why did you estimate the features when it was totally unclear you would be picking them up? I would advise to only estimate stories that are fully crystallized in the first place. Also here I don’t see where estimates are the issue.
So, to have these two observations as a starting point to re-think estimates strikes me as odd.
Then you come with what you have learned:
“The quicker it’s in the hands of your customers, the better off you’ll be. ”
I fully agree. Why would estimating block you in any way here?
“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.”
Our way of working is that we refine our stories, which means we want to have a good understanding of the characteristics of the story, by using INVEST. Isn’t this what you do by defining the right metrics? On the topic of wasting time on estimation meetings: we don’t have such meetings. Instead estimating helps us to determine if everyone has the same idea about what is meant with the story/what to build, as part of INVEST. Could you elaborate on what an estimation meeting used to be for you and what the metrics are you discuss instead?
“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.”
My organization has to deal with multiple clients that all have a wish list. We only have limited people obviously, so we have to prioritize what we do in what order and what we will not even start. We depend upon estimates to determine what potentially has the highest value and this includes having a rough idea of the costs. I don’t see us working as you described, but obviously that is highly contextual as you also acknowledge.
“However the roadmap should not be written in stone.”
Agreed, just as a planning can’t be written in stone and just like estimates can’t be.
In general I wonder how you came to the conclusion that estimating was your main problem. I don’t get it from your post. Seems like there were bigger issues just under the surface. I also don’t see why fast delivery with MVE/MVP (or whatever) would exclude working with estimates. It’s not mutually exclusive at all. I fully agree that we should be experimenting from time to time, because staying in a comfort zone all the time will only hold you back. But your article did not convince me why dropping estimating would help. I see it more as a case for fast delivery to learn from feedback than anything else.