DEV Community

loading...

Discussion on: ⏰ How to nail time estimations

Collapse
jonrandy profile image
Jon Randy

From 25 years of development experience, I've found it is best not to estimate - at all. Estimation just wastes time.

This is very true:

"Estimation is ultimately a futile effort. Software, more or less, is like writing poetry. Or solving mathematical proofs. It takes as long as it takes, and it’s done when it’s done. Perfect, or imperfect, estimation won’t change how long it takes to complete the work. If that sounds horrible to you, then go do something else."

(quote is from here)

Collapse
marcello_h profile image
Marcelloh

If this works for you, that is fine. But how would you deal with the opposite, when a you want a painter to paint your house, and his answer is like yours? Would you accept this?

Collapse
jonrandy profile image
Jon Randy

I would appreciate his honesty as builder's estimates are notoriously unreliable 😉

Thread Thread
marcello_h profile image
Marcelloh

It's nice when the painter is paid by the hour and you don't knoiw how much you have to wait for it to finish, and how much money it will cost.
Any estimation is perhaps more accurate than no estimations at all. They might be given by previous experiences. And you can always add a dice factor onto it.

Based on mine, I can give a person a rough estimation (with a warning), which will be adjusted in time.

Collapse
pjotre86 profile image
pjotre86

That's confusing! You really NEVER know how long you'd need for a task? You can't even tell if it's gonna be a one-liner or completely unknown?

The people asking for estimations are often not developers. That means they naturally have even less of an idea of how big a task is. So in most cases you should be able to give them at least a rough estimation. If not, then I agree, be honest and say it. But never knowing how much work something would be, that doesn't sound right.

Collapse
jonrandy profile image
Jon Randy

Of course I'm not saying I never know - I definitely know sometimes, but then that is not an estimation. By estimation I mean attempting to break a largely unknown task down and come up with a time or approximate time it might take. This is what I have found is ultimately futile and a waste of valuable time that could be spent just getting on with it

Thread Thread
carmenhchung profile image
Carmen Chung Author

Oh yeah - if you have no clue about the task/it's largely unknown, then estimating is often just plucking a random number out of the air, which is not helpful. We have R&D sessions every fortnight where we sit down and try to actually eliminate most major unknowns on upcoming tickets, to try to put us in a position where we can estimate more accurately. Sometimes it works...sometimes it doesn't (you can't always eliminate every unknown, even when doing prep).

Collapse
tominflux profile image
Tom

That's good to hear. I've been feeing the same but due to being a junior dev I worry it just comes from a place of inexperience.

Collapse
carmenhchung profile image
Carmen Chung Author

Experience definitely helps with estimation, but even extremely senior devs often get estimates wrong. I feel like "just another hour!" is a common refrain...even 1,532,742 hours later... 😂

Thread Thread
artdevgame profile image
Mike Holloway

Ultimately every problem is unique, else there wouldn't be a requirement to estimate. With uniqueness comes a margin of error.

Collapse
190245 profile image
Dave

So what do you do in the real world, when PMO and stakeholders are demanding to know when their new feature will be available to users?

Collapse
jonrandy profile image
Jon Randy

That is what I do. My jobs are in the real world

Thread Thread
190245 profile image
Dave

So, like other commenters have told you - you're very fortunate.

I've gone back & read the article that you reference, and while it makes a valid point (estimates are often used as a stick to beat the developer with), the logical conclusion is frankly, illogical (don't estimate).

That's like saying you keep losing at poker with good friends, so you stop socialising with those friends.

The Project team (PMs, PMO, call them what you will) have a very specific need - to communicate when feature X is likely to be with end users. It's also their job to manage expectations, and to allow for slippage etc, though many of them tend to forget that part.

So our take, is that developers put story points on things, to flag "how complicated we think this piece of work is, compared to another piece of work" - story points do not, ever equate to time. The estimate is, as that article suggests, usually wrong. So we don't have a problem with adjusting it when we get better information.

From there, since we use Jira, PMO have a button they can press that says "how many points per sprint do we achieve" - and then it's relatively simple maths to average that across a number of sprints.

So then, in Sprint planning, assuming all tasks have a "complexity estimate on them," Sprint Planning becomes a drag-drop exercise, and if the backlog is groomed properly by a Product Owner/Stakeholder/vaguely interested party, they simply drag the things from the top of the backlog into Sprints, can plan 6 Sprints in advance, and they know the time box that fits around a Sprint.

Heypresto, stakeholders know how long features will take to be in front of end users (with PMs managing that expectation in case of unexpected issues).

Then, and this is the part most companies get wrong, it's my job as Dev Manager to monitor the whole shebang. Are the team overfitting estimates in order to relax? Are the PMs pushing too much into Sprints? Do the git statistics match the complexity statistics? Etc. Etc.

But again, you're lucky, you don't have to deal with any of this.

Collapse
vinceramces profile image
Vince Ramces Oliveros

You can also add this line.

"Rate your X framework skills from 1 to 10"
HR somewhere critics everything in numbers

Collapse
jpgbarbosa profile image
João Barbosa

It heavily depends on what you refer as estimates. If I have a new client, they have an idea and a budget. They definitely need an estimate. However, it's not the estimate we, devs, immediately have in mind, like knowing exactly the amount of days for each specific feature. They need just a ballpark, a range, an idea for their product. For someone who has no idea about programming it's very hard to convert a budget into something more tangible. And it's fair. It's also part of our job as devs.

Some clients have hard discussions with investors, they need a product team with them to provide the necessary info. They might have deadlines. And we need to be able to master the scope, cut some corners if necessary, make use of 3rd party services to create workarounds and deliver value as soon as possible.

That's what we, Whitesmith.co do as a product studio. After the idea is aligned, we define the MVP or the PoC and we make the best we can with that budget (if possible and doable). We rollout the product, we gain traction, we get more funding, we keep developing in an agile way, always validating every step.

Essentially, we make sure we deliver the necessary value according to the needs of our clients. That's way different than implementing features within an estimate, because I agree with you on that. If there's no other way around, the feature should take the time it takes. Won't argue with that. But then we ask ourselves again, can we deliver value sooner?

Estimates are tricky. They are data points, they have different levels of precision, different levels of importance depending on the context and the business. If you work on a single product estimates will have different purposes from consulting. An even on consulting, their purpose changes a lot depending on the phase we are working on. We can easily estimate things that we know and things we know that we don't know. But what about those which we don't know that we don't know? That's when estimates really fail.

Putting everything in the same basket is a simplistic view of something highly complex as estimates.

Collapse
carmenhchung profile image
Carmen Chung Author

Hmm that's an interesting approach. So if that's the case, what do you tell product managers, your customers, or management, when they ask you when the feature can be launched?

Collapse
jonrandy profile image
Jon Randy

At work, I tell the PMs that I don't know, they then put a time on it themselves, and it just takes as long as it takes - I'm not going to waste my time estimating - or worse, rushing out poor quality products to meet arbitrary deadlines.

Outside of work, all my clients for freelance work have always been happy with just seeing progress from time to time - and a good final result when it's ready

Thread Thread
carmenhchung profile image
Carmen Chung Author

Interesting! I think you're really fortunate to work in a place where you can take as much time as you need. In my experience, it's not very common for most workplaces - even if it's just because other colleagues (sales, communications, marketing, customer support etc) need to know when something will be launched so they can prepare their end of the work. Management in particular, I've found, need to give at least quarterly updates to the Board on how things are progressing. You're super lucky! :)

Thread Thread
jonrandy profile image
Jon Randy

You can do it at any workplace. Stand up for yourself. If you produce good work you'll be valued. Don't waste time on activities that are detrimental to the production of a good final result.

Deadlines and being held to estimates almost always results in inferior code which ultimately makes the project take longer as there are more issues and technical debt to address - not to mention the time spent estimating!

Thread Thread
carmenhchung profile image
Carmen Chung Author

I agree spending time estimating can be annoying, and that badly-estimated deadlines are very often dangerous, and detrimental to code quality.

I think we'll need to agree to disagree on not doing estimates at all though. I think being a good team player means keeping the rest of the company informed of when they can expect a feature to launch. In my experience, partnerships needs to prepare workshops for partners (and customers, in my current situation), communications/marketing needs to get media releases ready, and management needs to inform investors/the Board about how their money is being spent. It's unfair on them to suddenly spring a feature launch and expect them to scramble to get their work done, especially if there's time-sensitivity to what they do (i.e. they need to get their media releases/workshops done within a week of the feature being launched).

But again, that's just my experience - if you don't have people relying on your time estimates, then by all means, estimates are pretty pointless!

Thread Thread
190245 profile image
Dave

Why the hell can I only click "love" once on your posts? You deserve a lot more than that!

Thread Thread
carmenhchung profile image
Carmen Chung Author

Thanks so much Dave, really appreciate it! Also love your "go back to the drawing board" comment - it's super important for people (not just devs) to raise when things aren't possible early on, and to encourage re-thinking the solution (and sometimes the problem, haha).

Collapse
fwd079 profile image
Fawad

Interesting. This might work for a one-man-army-permanent-job type situations or a greenfield project, but generally doesn't work for a freelancer/contractor working on an existing software/maintaining/rewriting or upgrading it. Besides, the client who's paying you doesn't really like if you shrug with an "uh I dunno" attitude. A rough idea is always appreciated by a client. A company coming to the client premises for a contracting business, giving an impression of having no idea about estimates, will be thanked and shown the door.
This is an ambitious stance at best, but like I said, it might work for permanent employees in a long-term job for number years. For others the article is very helpful.
Regards.

Collapse
cirphrank profile image
🎧Cirphrank👣

Man, you're spitting fire!