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."
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?
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.
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.
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... 😂
I'm a creator with multiple personalities in this order: Developer, Designer, Writer. Not a multiple personality disorder.
I do quite a number of things, passionately. I am a lover of startups.
Location
Nigeria
Education
Did 5years+ trying to grab a B. Sc. Inc. - consequently I gave it up.
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?
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
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! :)
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!
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!
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).
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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:
(quote is from here)
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?
I would appreciate his honesty as builder's estimates are notoriously unreliable 😉
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.
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?
That is what I do. My jobs are in the real world
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.
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.
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... 😂
Ultimately every problem is unique, else there wouldn't be a requirement to estimate. With uniqueness comes a margin of error.
You can also add this line.
Man, you're spitting fire!
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?
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
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! :)
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!
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!
Why the hell can I only click "love" once on your posts? You deserve a lot more than that!
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).
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.
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.