No Estimates: A Brief Introduction and Practical Uses

Estimation has become engrained into our daily lives. How long will it take me to get to work? What should I budget for my grocery spend this month? Literally on a daily basis, we surmise outcomes virtually from thin air. This behavior has infiltrated the workplace and now has become a cornerstone of project planning without which we feel we could never dream to begin our work.

As it relates to project management and software development, clients predictably lead with a few standard inquiries: How long will this take? And how much is this going to cost me? If you’re not familiar with the No Estimates movement, you may feel like, yeah, these are reasonable questions that I should be able to answer with some degree of accuracy.

While we can understand, as humans programmed to think we need estimations to make wise decisions, that a customer would want to know these projections from the get go, humoring this need, in fact, works to the detriment of how we go about managing our projects.

In the 1950’s, the Japanese began a movement focused on Lean principles. They found that keeping an inventory or parts and pieces needed for manufacturing was a poorly designed plan. It can be difficult to grasp at first, but they soon realized that having their materials supplied “just in time” was a more efficient and cost-effective use of their resources. It allowed them to utilize warehouse space for revenue generating activities rather than a store, and it enabled them to cutout unnecessary upfront costs.

No Estimates is another type of Lean system. Deciding which activities are slowing you down or wasting time and money on the front or back end as they relate to estimating practices and eliminating the need for them altogether are at the core of this method.

Why we’ve become addicted to estimating

We’ve quite literally become addicted to the practice of estimating. It provides certain levels of comfort to feel as though you know what to expect. The problem is that estimations are little more than guesses providing us with a false sense of certainty. Having financial projections allows for budgeting but in the case of companies working on software development projects, the return should be the focus, not the investment.

Why estimates don’t work

Estimates simply don’t provide the benefits we’re programmed to believe they do. There are far too many uncontrollable variables in the workplace that prevent 100% smooth project progression. Software development projects require multiple teams with varied skills and skill levels. Not to mention, rarely are we ever working on simply one project at a time. This being said, the act of transitioning a project to the next team is hardly ever a perfect baton hand off.

People take vacations. They take leave for personal reasons, and they take ill. These factors simply cannot be foreseen and can completely blow your estimations out of the water. Not only can setbacks like this push back estimated deadlines but there’s a chance you’d need to bring in outside sources to finish the job hence creating unforeseen uplifts in your estimated budget. So much for estimations.

Estimating comes with other dangers such as living up to those estimations. This can go either way, but keep in mind that once goals are set people adjust their workflow expectations to meet that exact goal. If expectations are set high, you could end up with stellar project outcomes, but you run the risk of falling short. Set estimated goals too low and you’ve sold yourself short.

Don’t forget the most unpredictable factor of all: the human factor. Our estimating abilities are undeniably tied to our personal emotions. For instance, if given a project and told that if you muck up and fail to meet your projections you could risk losing your job, chances are you’ll err on the side of caution and provide conservative estimates. Again, you could be selling the project short instead of saving your job. On the other hand, someone in a sales position could very likely inflate their estimations to give themselves more room to make a buck.

All things considered, we’re coming to see how estimations, while we think we need them, are little more than comforting and restrictions.

How to work with clients without giving estimations

To be clear, No Estimates dictates that we eliminate as much estimation as possible. There are circumstances where estimating will be necessary, but relying on estimations too much is a waste of time and energy and directly conflicts with Lean business practices. This is where forecasting comes into play.

Forecasting and Estimating sound similar. The main difference is that forecasting involves the use of known factors to surmise an outcome. Much different than estimating which is providing simply the best guess. Forecasting can be useful in working with clients that require some upfront “estimations,” but be mindful that past performance doesn’t perfectly predict future outcomes. As we’ve said before, unforeseen factors arise with employees and teams in the project stream.

Managing stories in slices

Your client has provided you some stories at the onset of the project. Tackling each story in its entirety at once may seem like the correct route, but really, it’s not. Breaking down stories into manageable and actionable slices provides you a way to report progress on a more frequent basis. The more frequently progress reports are needed, the more slices you’ll need to make into each story. Discovering which stories are necessary for your project is also important on leaning out your process and reliance on estimations.

An example could be made from a standard IT ticket submission by an employee:

“I need to be able to submit issues to IT so that a particular problem can be fixed which prevents me from working.”

Simple enough, and possibly too small to slice up, right? Wrong. Breaking this request or story down into several slices helps determine the amount of work required to fix it. Picking apart this particular story, we can decode the request into two actionable items:

  • Employee needs to be able to contact IT
  • IT needs visibility into a queue of issues waiting to be worked on

We’ve successfully limited the scope of our solution by identifying two features to focus on that will inevitably solve the issue. Slicing stories into multiple actionable parts helps us to actively manage projects.

Slicing up stories also helps with time management, a piece which helps to eliminate estimations. Breaking up stories into chunks helps to separate quick tasks to those which more time-intensive. This particular form of “chunking” enables your team to implement temporary solutions in a live environment, therefore, mitigating risk. It may be a few more steps, but overall it helps with operational implementation.

Some stories need to remain intact. Such stories should be given a maximum calendar duration a couple of months, of course, depending on the overall size of the project. Anything broken out of these should be given a maximum duration of a day. Any user-specific story should not be granted any level of advanced priority beyond a one-week timeframe.

Breaking stories out based on this practice enables you to determine how many of each category can be completed in a given time frame and provides accurate forecasting capabilities.

Track historical data from the start

Providing progress updates is essential in keeping clients who have not embraced the No Estimates theory happy and secure in your ability to complete the project according to their expectations. If data is not collected from the onset of a project, it can be difficult to piece together a before scenario due to changes in technology or staff.

For example, keeping track of your story deliverables (in slices, remember!?) can allow you to extrapolate how many RTSs you’ll be able to produce over the life of the project. This type of forecasting (not estimating) can be valuable to your relationship with the customer and goes far in demonstrating project progression.

Making the transition to No Estimates

Changing our way of thinking and the manner in which we do things is difficult no matter the task. So, we should expect nothing less from the implementation of a new project management process. Baring this in mind, cutting out estimates on day one of the transition is not realistic nor is it expected. There are, however, several things you can do to pave the way to a lean, No Estimates, project management practice.

Create story points

Basing your projections on story points rather than days and monetary costs is the first step in the No Estimates change. The benefits of story points are important and much more helpful than providing nothing more than a generic timeline. Story points help you to discover dependencies and complexity of issues. Story based estimation allows you to break a project up into predictable milestones.

Eliminate estimating task timelines

Trying to gather data points on story progression is counterproductive especially when compared to the overall time estimate to completion. Often we’ll see a story broken down into sub-stories with estimated timelines only to find that when they’re added back together, they don’t meet with initial expectations. Anecdotal progress updates are more useful to your overall completion goals.

Limit time to complete stories

Any story that starts at the beginning of one iteration that isn’t completed by the end of it points out a failing in your organizational structure. By limiting the time stories are allowed to be floating out there without resolution helps to point out these shortfalls and further your No Estimates program development.


As mentioned before, keep track of the time it takes to complete different types of stories. This type of information can become invaluable for future project forecasting.

Realizing when you’re late and what to do

Just because we’re aiming to rid ourselves of estimated time restrictions doesn’t mean that we’ve exempted ourselves from being off schedule or coming in late. One of the primary reasons for delivering a project behind schedule is because the scope was unrealistic, and the only way to remedy the situation is to have a serious talk with your client about reducing the scope of the project.

No one ever wants to admit that they’re not able to finish exactly what they’d set out to do, but it’s important to understand that if you followed the No Estimates theory and worked on the most important elements of the project first, it is likely that the client would be able to do away with certain items in order to get the project wrapped up. Maintaining flexibility and organizing the project so that it’s simple to see that each component or story may not necessarily be reliant on the next helps one to recognize that it is possible to deliver on some but not all of the original story requests.

It is quite common for the scope of a project to grow while it is still ongoing. If you’re worried about the scope being inflexible, the mere fact that additions can be made on the fly will tell you that it surely is not. Adjusting down as you go is a stellar way to keep a handle on the overall scope of the project. As you begin to understand the stories provided and begin to weave the solution, you’ll find that some of the stories don’t need resolution after all.

In the end…

We’re addicted to estimating. Estimating is difficult to get away from and hard to make people understand why it’s not only useless but also detrimental to our success in accurately setting expectations and creating optimal workflow efficiencies. So, what do you do? Changing the way an organization thinks is a mountain to climb and realistically can be impossible. That’s the truth. But, there’s nothing stopping you from implementing No Estimates practices within your team. Demonstrating the benefits of change is much easier than asking someone to quit cold turkey. Incrementally implement the No Estimates methods into your project management style and see for yourself just how superior they are to traditional estimation systems.

If you are interested in learning more about #NoEstimates you can buy the book NoEstimates, just click here.

Agile Manager – What is an Agile Manager?

I have worked with Agile Software Development for several years, and during all these years I´ve seen the same problem over and over again: very few companies understand what is an Agile Manager and his role inside of the organisation.

Most businesses out there still believe that Agile Managers are line managers and their primary function is to take care of people. “My primary job is to help my direct reports,” they say…

Hundred years ago two gentlemen called Frederick Winslow Taylor and Henry Ford completely changed the industry game. At that time society was stable, static and not dynamic. There was not much competition, and the markets were slow.

Companies could absorb the daily uncertainties of doing business in a better way using centralize and hierarchical organisations. At that time managers were the gatekeepers of all decisions and delegated the execution down to the workers. Taylor explained that an organization worked like a machine. Small parts connected with each other to create a bigger part.

These people were under the close supervision by their superiors who enforced compliance using punishments or extrinsic rewards. This period was called the manufacturing era. Unfortunately, this time,a still exists today.

We can observe this attitude in most of the existent companies in our society, but why do companies still have this approach?

I have been talking with a lot of managers, and they always tell me the same thing: “Workers need us because they are not mature to be left alone.” Now I must say this is quite funny 🙂 (ironically said). They are not mature. Follow my thought for some moments.

I work within the IT industry; this means I work with brilliant software engineers on the daily basis. Usually, these same software engineers have a masters degree or even a Ph.D. degree. These people are one of the smartest people in our society.

IT is an international environment, most of the times these are the people who moved away from their home country to a foreign country to try a better life. Usually these people do not speak the language of a foreign country, but still, they can manage the day to day life without a problem (most of the cases).

These guys, are the same guys that have house loans, raise kids and live an entirely normal life outside of their daily job. So do you think these guys cannot be left alone during working days because they are not mature enough?!

Our society is different than it was when Ford and Taylor took over. The pace of today’s society is unpredictably fast and chaotic. The predictability from other times is not present anymore. Today most of the jobs are in services, making most of today’s worker’s knowledge workers instead of manual, manufacturing workers.

Organisations must be fast, must innovate and must adapt to their customers´ needs. Decisions cannot be made in a convenient way anymore; this would be too slow and inefficient for companies. To solve the these problems, companies need to trust their employees allowing them to decide what is the best for the customer and helping them to solve their problems.

This requires companies to self-empower people and give them freedom to enable them to decide what is the best for the current environment. We still believe that people are immature, and they need a manager to approve vacations or help them with the next necessary training.

‘Theory X’ and ‘Theory Y’ are theories of human motivation and management. They were created and developed by Douglas McGregor at the MIT Sloan School of Management in the 1960s. These methods describe two contrasting models of the workforce motivation in Human Resource Management: organizational behavior, organizational communication, and organizational development. (original article here)

If you as a manager, manage people believing they will be lazy and immature, people will require someone to change their diapers or approve their vacations

On the other hand, if you treat people like grown ups believing they can manage their life and their work, you will get foreign workforces.

So what is your role as Agile Manager?

I want to be VERY CLEAR; I believe that managers have the best intentions in the world, and they want to help their employees. But if they want to help their guys they need to tackle THE SYSTEM, not people. There is a very powerful quote by W. Edwards Deming:

agile manager

Some years ago, I had the opinion that managers were just a waste for the organisation. Nowadays, my mind is a bit mature, and I realise how important the managers are. However, I want to make sure that you understand that their responsibility is to work in the system, not in people. Deming also said that 95% of organisations´ problems are within the system, and only 5% are related to people.

So what can I do as Agile Manager?

I believe that human beings can learn a lot from each other. Reading is one of the easiest ways. I believe there are hundreds of books out there that are great to help you in your daily job as a System Worker. However, I want to point out to three books I believe are mandatory for any manager who wants to improve the system.

I am sure when you read these books you will be so inspired to start working in the system that you will have problems where to start.

Now I want to give you some ideas what you can start with even without reading these books. If you are involved with Agile Software Development, you have a bunch of teams that come to you with outcomes of Agile Retrospectives that cannot be solved by their teams. This is a very simple way to start working with the system problems.

For example, if you apply Agile Portfolio Management, you might have an Enterprise Kanban Board where you can track what is going in the company. Things like flow, throughput, lead time, cycle time, the cost of delay, etc. are visible to everyone. You as a System worker should start talking with your colleagues and think how could you improve the system to deliver more value faster to your clients.

If you run Organisational Agile Retrospectives, several issues will be found in Agile Retrospectives. Who is better than Agile Managers to take care of those topics?

OIKOSOFY has been developing a tool to help Agile Managers to do their job. We have been working with some companies whom we contribute to ramp up Organisational Impediment Boards. These boards are tools for businesses to track significant problems that local teams cannot solve. Agile Managers´ responsibility is to get together with other managers and Senior Management and address these problems to create High Performing Organisations.

Below you can see a model that OIKOSOFY developed for our clients. This model shows the impediment board in the center of everything. A big part of Agile Managers´job is to get rid of the topics that are part of the board.

agile manager

I am sure I did not tackle all the possibilities of what an Agile Manager does on a daily basis, but I believe I guided all Agile Managers out there who want to improve and do impactful work on regular basis.

If you have any questions, do not hesitate to contact us.

If you like this blog just click here, to tweet about it 🙂

All the best,