You might be surprised to see this on the list of videos since Titan has a reputation of telling people we don't estimate. But despite all of my ideology of #NoEstimates, there are still contexts in which we need to have a client, or usually more often a prospective client, some sort of sense of what something's going to cost and how long it's going to take. So how do we strike the balance? Clients, whether true clients in an agency sense or the client of an in-house

So how do we strike the balance? Clients, whether true clients in an agency sense or the client of an in-house dev team, which is usually product or business or whomever, desire and understanding of how long a given feature is going to take and how much it's going to cost. And there's nothing necessarily wrong with this desire. If I hire someone to build me a house and they say we don't know how much it's going to cost or how long it's going to take, I'd be pretty frustrated, right?

going to cost or how long it's going to take, I'd be pretty frustrated, right? The business side of the organization needs to be able to figure out where that money's going to come from, how to build marketing around their timelines, and also how to adjust the work and timelines of the rest of the organization around the development work. So these aren't unreasonable desires. The issue is that they think that just because that's a reasonable desire, it

So these aren't unreasonable desires. The issue is that they think that just because that's a reasonable desire, it can actually be met. So let's think back to when I asked someone to build me a house. Let's check in. Is this a house they've built before? Well then, I expect they're going to be pretty freaking close in their estimate because they've done it before.

because they've done it before. But what if it's a custom house? They've built houses before, but they've never built this house. So they use their previous experience in building houses to give me a guess, but in the end it's just that. It's a guess. And if you've ever built a house before, you know, it's always going to cost anywhere

And if you've ever built a house before, you know, it's always going to cost anywhere between one and a half to two times what they told you upfront. It's just sort of a given in building houses. And custom houses, that is. And that's the problem. Estimates are always inaccurate unless you've done it before, in which case it 's mainly accurate, but still somewhat inaccurate. And if anybody's ever actually worked with teams that promise deadlines, you

but still somewhat inaccurate. And if anybody's ever actually worked with teams that promise deadlines, you know from personal experience, at the end of the project, you either cut scope, you extend timeline, and/or somebody's losing money. So why is this? Well, for starters, we never know less about a project than we do on day one. We never know everything that's coming. We've never done exactly this project in exactly these circumstances, so there

We never know everything that's coming. We've never done exactly this project in exactly these circumstances, so there 's always a big bunch of guesswork, and there's no way to know ahead of time what's going to happen. And this awareness that all estimates are inaccurate has led to a bit of a movement or a conversation called #NoEstimates. It was originally introduced by Woody Zuell on Twitter mainly. It's a conversation around the detrimental effect estimation has on software

It was originally introduced by Woody Zuell on Twitter mainly. It's a conversation around the detrimental effect estimation has on software development teams. And while the hashtag says "No Estimates," if you read the content of their work and their blog posts and look at the talks from Woody and other folks proclaiming " No Estimates," they're really usually just pointing out that estimates don't help developers. They're not a necessary or even beneficial part of the software development

they're really usually just pointing out that estimates don't help developers. They're not a necessary or even beneficial part of the software development process. And I would make the case, and I think they would as well, that estimation is actually beyond that, it's dangerous for developers, it's harmful. So first of all, estimation is time spent not developing, which is wasteful in the first place, and it's important to minimize time spent not developing as much as possible.

place, and it's important to minimize time spent not developing as much as possible. But second of all, estimation most commonly leads to expectations of delivery in a given amount of time. So we get toward the end of the project, and because estimates are inaccurate, we push our devs, our devs, we burn them out, we stress them out, and basically everybody's unhappy in this scenario.

everybody's unhappy in this scenario. Imagine office space. I'm going to need you to come work the weekend. So how do we solve these problems? There have been a few ways that people have tried to address these issues, a few comments when I see it. One is plan every tiny single detail, maybe you're willing to eat the costs of planning,

One is plan every tiny single detail, maybe you're willing to eat the costs of planning, maybe you do a paid discovery, but either way, you basically spend as much time planning as you will eventually spend developing. I personally would argue that you're going to get a significantly worse outcome , because among many other reasons, your requirements are going to change halfway into the project, and now all that time spent planning will be wasted.

the project, and now all that time spent planning will be wasted. But it does address some of these concerns. I don't think it's a good answer, but it is at least a little bit of an answer. The second thing people tend to do is just add a percentage above the estimate, maybe add 25% or 30% above every estimate, and this helps a bit, but there's no guarantee that you've padded it enough. And now you start getting clients, again, internal or external, unwilling to

that you've padded it enough. And now you start getting clients, again, internal or external, unwilling to work with you because they ask for a small thing, and you're planning it to be this massive amount of work. You become expensive, whether literally expensive or internally expensive. The third common thing that I see is for people, especially in the agile world, to stop working with time-based estimates and start using story points or t-shirt sizes

to stop working with time-based estimates and start using story points or t-shirt sizes or something else like that as a sort of attempt to estimate without estimating. And this was something really fun that I learned while researching this project . Ron Jeffries, who was credited with the invention of the concept of story points in the first place, said, "Storypoints were invented to obfuscate duration so that certain managers

place, said, "Storypoints were invented to obfuscate duration so that certain managers will not pressure their team over estimates." So the whole point of story points is to protect us from people who couldn't help getting stuck on imperfect estimates, but also wouldn't accept the concept of just no estimates at all. So unfortunately, story points, while designed to protect the developer, had been swallowed

So unfortunately, story points, while designed to protect the developer, had been swallowed up in the agile processes, along with velocity and sprints and other things that had relatively good intentions. And now they're just another way to tell devs they should work harder and faster, and they've lost that kind of magic of obfuscation, basically. And the last kind of thing that I often see people try to work with is the idea of estimating

And the last kind of thing that I often see people try to work with is the idea of estimating an ideal time instead of real time. And so it's a sort of way to communicate to clients that if everything went well, if everything went the way we're guessing it would go, including you communicating your needs up front well enough, even though we know it won't, this is how long it would take.

would take. And this is similar to sort of the original plan of, you know, just taking a certain percent above. But maybe you don't take the center percent above initially, you just say, " Here's the ideal estimate. We all know it's going to go over this, but let's just start from here." And that'll depend on the client and the team, whether there's any value in

We all know it's going to go over this, but let's just start from here." And that'll depend on the client and the team, whether there's any value in actually doing that. So those are some options that people work with. Here's what we do at Titans. For starters, we try to avoid estimates, if at all possible. That is the vast majority of the interactions we have is just saying, "Hey, estimation is not actually going to help us out here.

estimation is not actually going to help us out here. I say all the things I'm saying here, but much more concise in our business development processes and our relationship building with clients, and we get the client instead to give us a few weeks of our time, and we just show how productive we can be in that time." And universally, if a client is willing to agree to that, when they see how fast our

And universally, if a client is willing to agree to that, when they see how fast our team works, they stop worrying so much about estimates and they start worrying about how they're going to be capable of keeping up with our developers. It's very common for them to say, "Hey, we need a pause, and then let's book again because we can't keep up when we need to be more prepared, right? They'll book more time with us and we're ready to go." But let's say we can't avoid estimates.

They'll book more time with us and we're ready to go." But let's say we can't avoid estimates. We can't get a sign off for this client without getting a budget and we decided it's worth working with them anyway. That's usually going to be with a nonprofit. A lot of businesses think they have to have an estimate and we're going to push really hard on them. But nonprofits often are in situations where, for example, they need to know

hard on them. But nonprofits often are in situations where, for example, they need to know how much it's going to cost before they can even write the grant to get the money to pay us to work. It's just an unbreakable requirement. So how do we match our thoughts around protecting developers and being honest and transparent with this constraint? Well to start, remember the best estimates come from what you've already done

with this constraint? Well to start, remember the best estimates come from what you've already done before. So if I've installed 700 toilets, I can estimate with a pretty good amount of confidence how much this next toilet is going to take. And it's heightened I've started using that concept to give out something that I call a ballpark. And a ballpark is not some new idea that I'm going to write a book about and

a ballpark. And a ballpark is not some new idea that I'm going to write a book about and make a domain for. It's literally just my preferred language around what a lot of people call elapsed time. And what I'm trying to tell our prospective clients here is, when we've done something similar in the past, it's taken around this amount of time, which costs around this amount

similar in the past, it's taken around this amount of time, which costs around this amount of money. So if you have to set aside money, that's a reasonable amount to set aside. And that's it. To the client, I have to make this really clear. There's no promise that that's what your project is going to cost. But it is at least a reasonable place to start guessing or budgeting. And then if we book the project, we're going to do the absolute best work that can be done

And then if we book the project, we're going to do the absolute best work that can be done within that budget, whether or not the work we're doing is actually even remotely related to the original plan, which often it's not. You may notice this is very similar to an estimate, for sure. Like an estimate, we're trying to figure out how much something is going to cost and like an estimate, the client could take it and run with it and think, well, Titan promised

like an estimate, the client could take it and run with it and think, well, Titan promised this is what it's going to cost. So what really makes it different? Basically just like with story points, we're purely trying to use language that gets people to stop thinking an estimate can predict the future. We're using differing language of ballpark instead of estimate, plus a lot of other words and caveats that we say around the concept to make sure they know we are only

other words and caveats that we say around the concept to make sure they know we are only describing what similar work is taken in the past, not what this work could take. And you can use any language, you can call it a lapse time or whatever else. We're trying to make it very clear to them that this is not an estimate that you can use as a future prediction. And then, and this is very important, we actually build that language into our legal

And then, and this is very important, we actually build that language into our legal documentation. Now, if you're an internal team, it probably doesn't matter as much, but as contractors, it's very valuable to our statements of work and our contracts to actually say we're only going to promise to do the best work we can in the given timeline. And sometimes the SAWs may list out, you know, and these five items will be addressed.

And sometimes the SAWs may list out, you know, and these five items will be addressed. But the fidelity of how those items will be addressed and delivered can be variable depending on how long things take and how things go. But we can't have that language be a surprise. So we have to lean really heavily on communicating this in initial conversations with clients. And then if estimates are absolutely necessary, when we try to talk them out of them, make

And then if estimates are absolutely necessary, when we try to talk them out of them, make sure they know that what our estimates are and are not or our ballparks. And then we also have to make tons of disclaimers to let them know what the legal situation is so that nobody ends up seeing, you know, this legal situation either now or in the future and being surprised. At an organization where you as a developer or development team are just assigned full

At an organization where you as a developer or development team are just assigned full time on a project, with no concerns, you're just going to be taken off when a certain cost has been spent, you have a lot more freedom to pursue alternate ways of planning your work. And this is often when something like base camps, shape up methodology works or other systems where you commit to ship some version of some feature in a given amount

other systems where you commit to ship some version of some feature in a given amount of time. And then if it needs more work, you just iterate from there. And in this sort of setting, the most important goal is to pick the most important thing to work on, split it into the smallest pieces you can and do the most important of those pieces first. And we actually already talked about this in the video about task process in

pieces first. And we actually already talked about this in the video about task process in your organization, so I'd recommend you check it out if you haven't seen it yet. So if you are working this way, then when your organization asks you how long a larger task is going to take or a larger feature is going to take, the best answer to that, if possible, is to say, I'm going to pick up the most important piece of this feature

if possible, is to say, I'm going to pick up the most important piece of this feature and I'm going to ship something within a week and then I'm going to do that again and again until you're happy, which might even be just after a week, depending. And if the best estimation happens based on work we've already done, then if you need more, if they're asking for you to deliver more planning, at least you could say, once I've done a week of work on this project with my current team, I have a much

say, once I've done a week of work on this project with my current team, I have a much better sense of what progress can be made in the second week and the third week. And they can expect this similar process to continue happening and have a better understanding of process, you know, pace or you might think velocity of this team. We start seeing the healthier side of velocity here. Not a goal or something that can be controlled, but a measure of the past that we can use

Not a goal or something that can be controlled, but a measure of the past that we can use to make informed decisions about the future. And I'm completely aware, this isn't a perfect answer, but the goal for me here is as much as possible to change the conversation with product and business leadership from, tell me exactly when this fully fleshed feature is going to ship to what is the best thing we can do for this organization this week.

thing we can do for this organization this week. So, to wrap this up, estimates are bad for developers and development teams. They're always wrong, and in custom software development, they're usually even more wrong. We don't have any great tools to make estimates better, rather we have tools that try somewhat pathetically to protect us from people who unreasonably expect perfect estimates and expect them to predict the future accurately.

estimates and expect them to predict the future accurately. At Titan, we try to avoid estimates as much as possible, and when we have to, for legitimate business purposes, we use legal language, endless caveats, and the word ballpark to try and distance ourselves from the expectation that any description we make of past work is any kind of commitment to timelines for future work. So, your number one goal should be to forgo estimates entirely, and if you can

is any kind of commitment to timelines for future work. So, your number one goal should be to forgo estimates entirely, and if you can 't, you should do everything in your power to make it clear that an estimate by any name can't reasonably be a commitment to future timelines. Good luck.