Estimating and Planning Are Necessary for Maximizing Delivered Value

Because I’m so interested in estimating and planning, I always take notice when I see a new blog post or news group posting claiming, “Estimating is waste! Don’t do it!” The thing that never shocks me about these arguments against estimating and planning is that they never come from the business people for whom we are developing products or systems. They understand the value of estimates and plans (and the shortcomings of poor estimates and plans).

Let’s consider that perspective for a moment. How many significant things in your personal life would do without at least some planning first? I doubt you would plan a wedding, a relocation to another city, a holiday trip, or any such event without first engaging in some amount of planning.

Suppose you are considering a first-ever trip to Italy. You would plan that–which cities? how long in each city? what’s your budget? and so on would be some of the questions you would consider. Now suppose you are planning your one hundredth return visit to the city in which you grew up. You will even plan this trip–even if the extent of that planning is to decide you don’t need to plan at all.

Planning is the act of thinking about the future. Sometimes that future holds risk and uncertainty. In those cases we plan more than when the future is highly predictable as a hundredth visit to your childhood home town would be. When a future activity is highly predictable, planning may consist of nothing more than a few milliseconds of rejecting the need to plan further.

Of course on a software project it is rarely this simple.

What about estimating? Do we really need to estimate? Yes, because estimating is a pre-requisite to planning. You cannot plan without estimates in mind. Those estimates may be very informal and very implicit. As I write this I am on a flight to California. Before boarding the plane I got cash from an ATM. I estimated my upcoming need for cash to do that. $200 should do it. That estimate took less than a second and I was perhaps not even conscious of it, but it was made.

When a product owner says, “I’d prefer to add this feature rather than that feature,” the product owner is acting with at least some implicit estimate (perhaps guess) of how long each will take. When a programmer chooses late in the day to fix a bug rather than start a new user story before going home, that programmer has made an implicit estimate that fixing the bug fits better with the hours left in the day.

Teams that say, “We won’t estimate. We’ll just make every user story the same size,” are estimating. They are estimating that this user story is the same effort as all other user stories. I’d even argue that it’s harder to make each story the same size than it is to use a small range of effort sizes on various stories.

These estimates must be made. Yes, they can be subconscious but they are made. Those who blog and post to newsgroups saying “estimating is waste, don’t do it” are ignoring these types of estimates.

But are these casual, perhaps subconscious, estimates OK? Wouldn’t teams be better with formal estimates?

Perhaps but not in all cases. A team should estimate and plan only to the extent that further investment in estimating and planning will lead to different actions. If you will do the same thing even if you estimate or plan more, stop. But if further planning is likely to lead to better decisions (more confidence in a delivery date, better prioritization of functionality, or so on), then estimate and plan further.

As an example, we recently added quite a bit of functionality to this website to support our new eLearning course on Agile Estimating and Planning. I did not ask the programmer who did that work to give me more than cursory estimates. I’m still enough of a programmer to have an idea how long the new features would take. I’ve worked with him long enough to know how fast he is. Asking him for detailed estimates would not have changed anything about that project.

So estimating and planning are necessary. They can (and should be) lightweight. You should stop when further planning is not likely to lead to improved decisions worth the extra effort.

Share on facebook
Share on twitter
Share on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

Six Actionable Nuggets of Advice for Becoming a First-time Technology NED

If the pandemic has taught companies anything it’s that tech is not something that you put off and think about ‘later’. The last year has seen organisations go through huge digital transformations, whether planned or otherwise. And for those that aren’t technology-based companies, getting the right board-level advice can not only be hard to find, but the difference between success

Read More »

Culture, Skills, and Capabilities // How to become a more data-driven organisation

In our whitepaper “How to become a more data-driven organisation”, we wrote about the five steps that an organisation would need to take, which are: Outcomes: Defining goals and metrics to ensure clear and measurable outcomes Analytics: Implementing and sharing the analytics to improve data-driven decision making Innovation: Testing assumptions through hypothesis testing and learning Data Platform: Gaining new insights

Read More »

Data Platform // How to become a more data-driven organisation

This is the fourth article in our series on “How to become a more data-driven organisation”, and we are going to be focusing on Data Platforms. It is at this point that most people start to dive deep into the technical aspects of Data Lakes vs Data Warehouses, but we want to bring us back up a level and ask

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?


101 Ways Limited
145 City Rd
United Kingdom


101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at