My Journey to NoEstimates

Planning a project has always been a simple process for me. As a frontend developer, the initial step of outlining the UI and UX requirements is usually handled by the design team in collaboration with my manager, who acts as the product owner. My role starts with reading the product specification and generating tasks—a glorified to-do list that I will check until all the tasks are completed and the project is finished. I have to admit that this effort is primarily for my manager’s satisfaction, allowing him to monitor the project’s progress.

If it was up to me, I’d keep all the things to be done inside my head. I said to myself as I was about to start a new project that would probably take a month and a half. Maybe two.

Four (4) months and a post-mortem later, my boss told me that it was very concerning that my estimation of the project was so incorrect. Especially since the project I had just finished was supposed to be a major milestone for the goals of the company, so its development had been blocking everything else since we started thinking about it earlier in the year.

Another flop like this, and my neck will be on the line. I thought, cringing as I remembered that I had the great idea of leaving for a week of vacation in the middle of the project.

Fortunately for me, my manager is a fair man, and his concern was more an invitation to step up my game than an invitation to leave the company. I needed to somehow start producing accurate time estimates, and understanding how was about to become my top priority.

But to be honest, I’ve always thought time estimates are kinda… whack. Or at least mine were, since they always ended up being way off. The more I thought about it, the harder it seemed to generate ideal estimates. There was just so much to consider!

I have ADHD, and doing things I don’t want to do is really hard for me. I considered letting the “lazy” me take control and continue giving estimates from the top of my head, fully knowing that I’d need to give an excuse later for why they were not accurate. I spent a couple of days pondering the idea, not sure of what to do.

A few days into the project release, new KPI values started popping up on our dashboards. Our expectation was that the new features would increase the retention of the users in the app. Instead, we started seeing that the new version numbers were slightly worse than the previous version. Fewer people were returning to the app, and the ones who did were staying for less time.

I had just spent four months working on something that makes things worse.

This hit me like a truck. If I had taken a month instead of four to release something, maybe we would have known that we were going in the wrong direction. Instead, my failure to produce accurate estimates left my project in an all-or-nothing situation where I had no option but to finish the project without an end in sight or not release anything at all.

So, I took my manager’s feedback to heart, thinking: Well, he has at least a decade of experience more than I do, and he’s asking for accurate time estimates. Surely there must be a way to get there.

But my intuition told me that coming up with ideal estimates was going to be a hard problem without a general solution. Since every project is unique, the experience of having good time estimates for one would not guarantee that I’d be able to produce them for a different or larger project.

The first thing I found was a talk called NoEstimates, which was completely the opposite of what I was expecting. In his talk, Allen Holub discusses why time estimates are a wasteful practice that won’t end up providing any value to your final client. On top of that, they won’t accurately predict how long a deliverable will take.

Allen mentioned the pressure that is put on developers when managers take their estimates and assume them as facts, when in reality, developers know that those dates will be wrong. This leads to a toxic work environment where employers have to overwork themselves to finish before a date that was established at the beginning of the project, the moment where they know the least about it.

The talk really resonated with me. I had found my first mentor in my journey to better estimates. Near the end of the talk, Allen mentioned that just counting User Stories was almost as accurate as establishing time estimates in predicting the actual delivery date. Very promising, but I still had no clear idea of what to do. Apparently, everything starts with real data, so for my next project, at the end of each day, I would look at the things I had accomplished and take note of how long they took.

The problem was that the list kept growing bigger. Like a Hydra, as I finished one task, two more would appear. I noticed that legacy code needed refactoring, and new requirements that weren’t considered before started coming up from the product team. Allen Holub’s talk had been a good, reassuring start, but I needed something else to link all his points together into a concrete solution.

Fortunately, during the talk, Allen mentions a book by Vasco Duarte that’s also called NoEstimates. Looking at the summary and reviews, it seemed to promise more specific alternatives in the journey of ditching time estimates. So I got the book on Kindle and started reading it.

The book is beautifully structured. As a reader struggling with time estimates, you follow the story of Carmen, a young and bright project manager who is able to get on the right track with the help of NoEstimates. The descriptions of the stressful situations that Carmen experiences with her boss and the progress of the project really made me feel that the author has effectively managed the same problems I was having, so I was very excited to see the solutions that he proposed.

And boy, did I get what I needed.

The first half of the book describes the different ways Carmen (and the reader) suffers when the project is managed with rigid time estimates in mind, and the second part starts describing solutions. After reading the book twice, here’s a summary of what I was set to do:

First of all, don’t use time estimates (duh), and ask your manager not to expect them from you. They are inaccurate, but your boss will take them as solid facts. Your commitment to inaccurate deadlines will break your mental state when the project inevitably takes longer than expected, make you work overtime to meet the deadlines, and burn you out.

Instead, start tracking how long it takes on average to complete a task (or User Story). If you’re leading a team, measure how many tasks can be completed in one day. The trick is that you have to be really good at slicing tasks in a way that they take one or two days tops. This is the hard work that #NoEstimates will ask from you, but in my opinion, it’s way less work than trying to come up with accurate time estimates. Fortunately, task slicing is something that you get better at with practice.

Vasco explains that, after slicing, a good User Story should follow the INVEST acronym:

• Independent: Can be implemented separately without depending on other Stories.
• Negotiable: Defines a clear capability for the system but does not dictate a specific implementation strategy. This allows the developer team to select the best implementation strategy when the time comes, and allows the possibility of change after getting feedback from the customer based on a running demo of the software.
• Valuable: The main value is for the customer, as opposed to being for the developer or the organization.
• Essential: Absolutely required for the product to be viable. When removed, the product should be unusable.
• Small: Can be implemented in a short time frame, around one or two work days.
• Testable: Includes acceptance criteria expressed from the point of view of the end user.

If you don’t have historical data on the throughput of your team, or if the project implements something you’ve never done before, you’ll need to take some time at the start to work at your regular pace and start gathering data. You’ll then use this data to make a forecast of the expected delivery date based on the number of tasks to be done. Of course, the throughput is something that you’ll need to update daily for the forecast to be accurate. That’s why it’s important to slice tasks into a day or two.

After finishing the book and reflecting on it, I looked back into the conversation I had with my manager and started wondering what his real necessity was. What was the point of having good time estimates? The answer was apparently obvious: to know when the project will end. So far, I had assumed that the best way to determine the length of a project was to sum the length of its parts.

But then I realized that the NoEstimates method was a way to answer this question in a different, more accurate way. Instead of committing to the assumption that each task (and the whole project) will take an arbitrary amount of time, you commit to an acceptable end date that the project cannot go over. For your manager, it’s practically the same (they are getting an end date), but for you, it’s setting a very important guiding point that will help you notice early if things start getting out of hand.

Let’s consider an example:

Say you have 10 tasks left and an average of 0.7 tasks done per day on a solo project. At your normal pace, the project should take around 14 work days to be done. So if you start on October 8th, you should be done by October 26th. This is great because you and your boss agreed to be done by November 1st. However, as you progress, you’ll inevitably find that some tasks weren’t sliced correctly, bugs will start to appear, and other parts of the codebase will need refactoring, increasing the number of tasks to 15. This adds 7 days of work, moving the expected delivery date to November 6th!

But there’s nothing to worry about because you’re not really late yet. Forecasting allows you to spot this kind of delay very early. So early that you won’t get trapped like me in a situation where you have no other option but to continue. So early that you’ll get a chance to talk with your boss about either reducing the scope of the project to meet the acceptable end date or moving the said date forward in time.

This is the main benefit of the NoEstimates approach. It doesn’t let you lie to yourself with fantasy time estimates and forces you to rely on real throughput data. Problems can be spotted very early, and the scope or deadline can be tuned so that nobody leaves with unmet expectations.

And the best thing is: You can forget about unnecessary meetings! If you have the appropriate setup to measure the number of tasks, throughput, and the acceptable end date (this is very easy to build on a spreadsheet), you can have a red alert if you discover you’ll go over the date, even by a day. And only then you’ll need to meet with your boss to negotiate scope, instead of the daily or weekly standup you probably do.

These negotiations are possible because INVEST stories can be dropped from the project without affecting the delivery and are small enough that some can be implemented quickly to get faster feedback on what’s important.

In my case, since the project I started was a small endeavor, I was ready for a forecast after a week of working at my own pace. It would take another nine work days to finish the project, on October 2nd. I decided to only measure my part of the project. Design and backend work were not considered, neither were the QA cycles spent afterward. The definition of done for this experiment was for the new client features to be ready for QA.

To my satisfaction, I was only 3 days off from my estimate. So the NoEstimates forecast was 80% accurate! I think this is acceptable since I got sick in the middle of the sprint and had to take a couple of days off.

Adopting the NoEstimates approach completely changed how I manage projects. By ditching the need for exact time predictions and relying on real data and task splitting instead, I found a practical way to handle my project planning. This method not only gives more precise forecasts but also helps spot problems early, focusing on necessary features only and facilitating negotiation with stakeholders.