Do you apply a multiplier to your development estimates?
It's common to use a 2x multiplier on time estimates given by developers for projects/features to be delivered.
Now I'm somewhat wondering if both, the developer and product owner/client, knowing of the rule, applies it. Which eventually would result in a 4x multiplier.
What's your experience with time estimates in this regard?
Trending on Indie Hackers
Quick warning, I've spent a lot of time in my career thinking about estimates, so this might get long. But what I've seen is that there are basically three kinds of "multipliers."
When you suggest that there's a "rule" for developers, you're talking about somewhere between the second and third approaches, not caring enough to plan out the project before estimating and/or not trusting the stakeholder to not change the project in the middle. It's not ideal, but since most shops have shifted to one of the various "it'll be done when it's done" scheduling disciplines, it's probably acceptable as long as you're mindful about it.
When you suggest that a stakeholder might do it, it's always the third, that they don't trust the developers. And if a business associate doesn't trust you, then you need to work on that relationship or (if it's not someone that you can deal with regularly) work on a reputation of reliably hitting targets, so that you can point to reasons they should trust your estimate more than someone else's.
That all said, the way I personally build estimates to increase the chances of it being precise is to recursively break tasks down until the worst-case estimate was no more than a few hours long, since those estimates are almost always accurate. That maximum-size time is based on projects that are likely to take an on-one-hand number of worker-months, and so should probably be adjusted if that's not the likely scale, so that you're not mapping out hours on a twenty worker-year project or on a weekend hack. Looking for the worst case keeps you honest and reminds you about all the little tasks you were going to just assume happened magically.
Then, take your development time estimate and put together a 2:1:3 schedule of design/architecture time, development time, and QA/debug time, because that's basically fixed overhead (I've never seen anybody cheat it) that you don't want to think about up-front, so technically a fourth multiplier. And then track your low-level estimates to forecast how you should adjust them in the future. I actually ran a project management site that enforced all of that, way back when, but it's easy enough to do that much with just a spreadsheet.
It's more work for a proposal than "eh, sounds like a three-week job to me," but it's work that makes it easy to get estimates pretty close to the final results and also quickly see how scope changes are going to impact the schedule, and that builds everybody's confidence. However, like I hinted a couple of times, it doesn't mesh well with Agile-style project planning, so take all that with a grain of salt for a modern office.
Thank you for your detailed answer!
Of course, you can assume that you have a plan or specification in some form. By the way, that holds true for agile projects, too, IMHO - the plan is simply evolving over time, but you can usually still specify in milestones before you go into sprints.
When I mentioned the 2x "rule", some may refer to it as "common practice". I don't know if someone wrote a book about it, or if it's something exclusively to software development, but as a developer, I've always ever worked with people (both other developers as well as non-techie business owners) and everybody seemed accustomed to the idea that everything will take longer than anticipated, therefore just assuming it will take twice as long. That never seemed to originate from distrust, by the way, it seemed and seems like perfectly fine practice.
From this observation, I wondered if all parties usually take into account, that this x2 may have been already applied by the previous link in the chain (because for more or less standard, not incredibly scientific applications a total of 4x does feel a bit too much IMHO).
To clarify, by "plan," I mean that mostly-complete breakdown of work. My experience with Agile shops has been that you either guess at the scope with the "t-shirt size" approach, then tickets get generated from that, or the required milestones are set and sprints are planned when you get to them with just the next milestone in mind. Neither of those is a plan. Like, if a contracting company were to vanish, the issue tracker couldn't easily be handed to another organization to pick up where they left off.
It's a legitimate choice to work that way, but it conflicts with this sort of estimation.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Totally brained my damage :)
🤯
Depends on the length of the build -- longer timelines are harder to predict. If it's a small tool/utility or a couple of marketing pages, I just round up to the nearest week.
We took our estimates and multiplied by 1.5 to give our product team a target date. We usually fell short by a couple of weeks and they kind of expected it. I think having 2x would have made us pretty close. So to answer your question - 4x is a bit high.
OK so this can get complicated depending on just how people there are up the reporting line after you and product.
I think in my experience this is how it works but that doesn't mean x4. Mostly because if I say 4 hours, product will tell their boss 3 hours and so on up the line.
That's how we end up with crazy short deadlines, so in essence you have to over quote to stand a chance of getting a half decent amount of time to actually do it in that's still less than what you quote.