Marco Rogers asked about estimates on Mastodon, and I agree with a lot of what he’s written. Engineers often think they should not have to do estimates, going so far as to champion the “no estimates” movement, or claiming that engineers should not have to be accountable for their work. Writing software is expensive, and the people paying for it have every right to ask the developers when it might be done.

I want to go through a process for giving an estimate and running a project, since both are intertwined. Successful delivery makes estimates easier, and realistic estimates support successful delivery. After that, I’ll touch on why estimates are not some evil thing that is done to us and that they can actually make you better and build trust in you and your team.

Why Are You Being Asked for an Estimate?

The first thing to do is ask what is being requested, what is needed, and why does that require an estimate. Ask probing questions to build alignment, such as:

• Is there a critical feature that must exist?
• Should we focus on solving a specific problem as best we can?
• Are we weighing projects against each other to prioritize?
• Do we need to explore a concept through quick iteration?
• Are other teams coordinating on this delivery?

You want to build alignment with everyone on exactly what is being proposed. You must lead this, because product managers, designers, and “stakeholders” are often very wrong about what parts of a project are time consuming and which are not. With no-code and AI-driven products, this problem is worse.

It’s your job to make them understand what is time consuming and why. You are responsible for identifying areas of uncertainty to explore more deeply. It’s also your job to discover other dependencies outside the software that you need to be aware of, such as customer server training, ad campaigns, etc.

With this alignment, you can now deliver an estimate.

Providing an Estimate Requires Experience and Honesty

There’s no formula for coming up with an estimate. Many have tried¹. Marco’s posts outline some techniques, but it boils down to experience. This experience is a combination of repeated delivery of software and mentoring by those who have more experience estimating delivery. Keep in mind that no amount of experience can allow you to accurately estimate any project.

You will need to combine three basic strategies:

• Accurately estimate stuff you generally know how to build. For example, I’m pretty confident I can estimate how long it will take to build a web form, validate its input, and store it in a database.
• Increase your estimate in relation to the amount of uncertainty there is. The more uncertainty, the more likely things will take longer.
• If there is so much uncertainty that you can’t come up with anything, you can estimate time to explore the project and get a better estimate. This technique is extremely common outside software and it can work well to either let you figure out what you need to do or motivate the stakeholders to try to remove uncertainty (if they can).

The more experience you get, the better you get, however you have to pay attention during delivery, as this is your feedback about how good your estimates are.

Figuring out the estimate is easier than negotiating it.

Can You Do it Faster?

Every estimate I’ve given has been met with either “can you shorten it?” or “why is it so long?”. This is natural, but how you handle this is critical to successfully delivering the project and building trust with both your team and the project’s stakeholders.

You can feel free to paraphrase Bender’s Oscar Guarantee to Calculon thusly:

I can tell you any number you want, but it won’t change what you’ve asked me to do.

Perhaps you should be less flippant, but the core message is that your estimate is a best guess based on what you’ve been told.

You can:

• Improve your guess with more information. And you should have ready what information you need.
• Reduce your estimate by removing scope. And you should have ready what scope, when removed, would meaningfully reduce the estimate.

Remember, most product managers and company stakeholders don’t understand what is time consuming in software. They usually assume important things take a long time, and minor features are easy. Get ahead of this by having a list ready of what cuts will reduce uncertainty and be meaningful.

Also, your estimate should include assumptions you are making. For example, “assuming a 3 person team” or “assuming access to a new database instance” or whatever. You must not, however, accept assumptions from others in order to reduce your estimate. Remember that the non-engineers will not have a good sense of what takes a long time or what is complex.

If assumptions are proposed as a way of reducing your estimate, you have two responses:

• “I was already assuming that, thanks for the reminder, let’s write that down”
• “We can’t control that, and I don’t want to give you a false sense of security by lowering the estimate”

Remember, you are the expert here, and you must take ownership for the estimate. You know what assumptions are likely to hold.

The first time you do this with a new team, this all will be hard. It’s a lot of non-coding negotiating that can feel like politicking. And, while it kinda is, it will get easier as you successfully deliver projects. The best way to build trust is to get your shit done.

How you do that matters.

Plan to Work Iteratively in Priority Order

Once everyone is agreed on the estimate and the project is scheduled to start, you can overlay your estimate onto a calendar and come up with a date. Don’t forget about holidays, PTO and, if the project is long enough, attrition. Show your work so everyone agrees on the projected completion date of the project.

I know this will feel like giving a deadline, and the #NoEstimates people are angry, but the world does not revolve around the software engineers. Other people will need to coordinate with whatever it is you are building, and it’s extremely hard to coordinate around weekly deliveries of whatever. Dates are the simplest way to coordinate across many teams.

The way to manage this is to run the project in a way that constantly reminds everyone that this date is a projection and not a deadline.

The first step toward doing that is to ask what happens when things take longer than we expect. Will the team ship what it has, or should the team keep working to delivery everything originally requested?

An Estimate is Just an Estimation in the Category of Guesstimates, What’s the Problem?

On projects where your team must coordinate with others, the stakeholders will almost always want to ship whatever is ready on the projected date, and treat the unfinished work as a “fast follow”. That said, it can feel like you are already telling them the project is behind before work has started.

You can assure them, you stand by your estimate, but that it is just an estimate. This will be the first of many times you will remind everyone that the date is a best guess. But this time, at the start of the project, you will also let everyone know how you will manage this risk.

You manage the risk of not completing everything on the projected date by working on the most important or most uncertain things first. This way, your projection can be improved over time, and you are always sitting on the most valuable features, fully completed.

Inexperienced stakeholders will not usually agree to put everything into a hard-prioritized list. They will want buckets and they will put everything in the “high” or “medium” priority bucket. This is not what any reasonable person would call prioritization. Bucketing can help prioritize, but you need features/tasks/whatevers in a single ordered list that you will work from.

If the stakeholders won’t help, you can solve this problem easily. Tell them that you have to work in some sort of order and you are happy to choose the order in which things are completed. Tell them further that your preference is that they have input into this ordering to ensure that the most valuable aspects of the system are delivered as quickly as possible.

If this doesn’t work, you are not dealing with serious people, but you can certainly create the prioritized list. Sometimes, when people see your list of priorities, they suddenly have an appetite for providing input.

Deliver and Revisit Everything Weekly

At this point, the project has been planned, and your original estimate still holds, and thus your prioritized list of things to do has a single line at the bottom with the projected completion date next to it. This list is how you will manage the project’s delivery and communicate its status.

Each week, you will deliver working software that can be demonstrated to the stakeholders in a way that they can understand what you’ve done. If this can be delivered to real users, that’s great, too.

If the most important task cannot be completely delivered in a week, you must break it down into at least two tasks such that one of those tasks can be delivered in a week. You must maintain a clear mapping between your breakdown and the original list.

Don’t over-do breaking up tasks. If you have a large task that can’t be done in a week, you don’t need several sub-week tasks. You just need the one that you are going to work on. You can break down the remaining work later if needed.

At the end of each week, revise your estimate, based on work done so far:

• What items from the list do we think are deliverable by the original date?
• What date do we think all items from the list could be delivered?

You should also be prepared to explain why your estimates have changed. Show respect for the product managers, designers, and stakeholders by giving a better explanation than “it took longer than we thought”. Even if you need to get a bit technical, the stakeholders can often understand enough of these details to maintain their trust in you. Such details can also improve your own estimation skills when you verbalize precisely why something took longer than you thought.

This weekly review is also a good time to re-prioritize the work. As the software is demonstrated and becomes real, the stakeholders may change their mind about what is important. Move things around and, if needed, update your estimates.

Detailed Review at Halfway

Although your weekly reviews will keep everyone aligned, you need to get ahead of whatever is going to happen when the originally projected date arrives and all the work is not completed. Halfway through the project, you should have a more accurate estimate, and you should start having pointed discussions with stakeholders about what’s going to happen.

Most product managers and other stakeholders will not be as focused on the project as you, and will assume that it’ll all work out if they aren’t told otherwise. You must lead a discussion to set expectations. Your opening proposal is that, on the originally projected completion date, launch happens as planned. The system will have the most important stuff, and you can itemize out exactly what that is.

If there is a perception that the project is “behind”, you need to remind everyone that the projected completion date was just an estimate, and that you have been revising it weekly. You can remind them of the reasons why work hasn’t gone as fast.

You will then need to manage suggestions on how to get the project “back on track”. Inexperienced leaders will ask you and your team to “work harder”. You will need to explain that each additional hour worked does not move the project’s delivery date forward an hour. You will need to explain that, over time, this will make the project later due to team burnout.

You will also be asked to add more engineers to the project. Rather than simply quote Fred Brooks’ Mythical Man Month, I’d suggest you actually itemize out what you think is required to onboard a new person and add them to the team. Show the stakeholders where the project will slow down and grind to a halt. Show them how it may not actually catch back up.

This discussion will be had whether you drive it or not. If you don’t drive it, it’ll happen late enough in the project that everyone will be stressed and tempers may flare. Get ahead of it by taking ownership at the halfway mark. Depending on how big the project is, you should do it again at the 75% mark.

If you do this, you and your team will appear extremely competent. You will be viewed as reliable and trustworthy. This will ensure that the project will end well and that future projects will go more smoothly with you there.

Why Even Engage with Estimates?

The No Estimates Movement, boggles my mind, as it seems to be the quickest way to destroy trust while demonstrating a complete lack of systems thinking. Their site makes this claim:

The basic idea, as I understand it, is that it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.

Imagine being a product manager on a new major product at your company, that will need an advertising campaign, customer service training, and support documentation written being told by the engineering team “we’ll just work one week at a time and I’m sure it’ll be fine”. What the actual fuck.

(I would agree that estimating storiesindividual features is not as valuable as estimating projects, but you still need to be able to figure out how big something is to determine if it needs to be broken down into smaller parts. That’s estimation!)

The reality is that we are paid to do work, and the people paying us have every right to ask what might be involved in doing that work. And, the reality is also that if your team’s work must be coordinated with others, and you don’t provide an estimate, one will be provided for you.

Despite what the #NoAccountability people say, you will be held accountable. My recommendation is to start acting like it.