> I could go on: the point is, there are many situations where an estimate is required. Please do! I'd find it really valuable. (Not necessarily OP. I'm happy to hear from others as well.)
Billing a customer for a feature they want. How much you charge the customer is going to depend on how many dev hours it will take. An accurate estimate is necessary in order to give come up with the appropriate price to charge them. Name a price that's too low, and you end up losing money on devs' salaries. Name a price too high and the customer walks away from the table
That sounds like freelance work, not product development. Am I mistaken?
> commit to something, but you don't know what... The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'. I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of bl…
We don't even need to pretend it is an outside-of-technical-people problem. Developers (and just people in general) are just as guilty at mis-estimating their own capacity for work. By this I mean we forget we have other things - we don't accurately account for meetings and side-tasks. We underestimate the complexity of even simple tasks. We don't account for the flames we fight habitually without much consideration.…
Then you have the companies that take every estimate and cut it down to 1 month without changing scope. Doesn’t matter if the estimates are 3 months worth of work or 6. And now as an eng you have to either lowball your own estimates and burn yourself out to seem like a ‘team player’, or push back and burn yourself out from a losing battle.
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
The way I express it is that estimation is fundamentally a design process. You can't get an estimate without doing design work, to some appropriate level of detail. That design work is not going to spring forth from the void unbidden, so it needs to be paid for.
This does not mean that you need a big design up front, but it does mean that you need to be happy with a level of precision to the estimates commensurate with the funding that has been given to the design process.
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack. And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is: "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it tak…
> But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build
Great, we'll be expecting you to complete that by the end of next week.
Paid overtime will fix scheduling. Scheduling is bad because the cost falls on the employees, not the employer. If crunches resulted in time and a half, double time, and triple time, scheduling would get fixed. As I've pointed out before, film scheduling is an established discipline. Making a movie is much more complex than a software project. There are a lot of moving parts. Things get changed. There are people prob…
> Making a movie is much more complex than a software project.
Software design and development is more like writing the books that the script was based on.
Think Song of Ice and Fire, but 100,000 pages long and written simultaneously by a hundred authors.
A big problem is that estimates given by developers are never treated as estimates but rather as quotes . If you miss your estimate then your employer may expect you to work extra hours to make up for the gap . Best strategy is to under promise over deliver .
That's why scrum changed the wording from "estimate" to "forecast". It's more like a weather forecast: you'll often get close, but sometimes it's completely off.
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
This is generally why I don’t see a ton of value in trying to do accurate estimation. You’ll get better velocity and delivery not wasting your time on all of the faux story point estimating that scrum and other systems do. The most proven way to do accurate estimation is to base new estimates off of previous delivered work (i.e. we’ve built this suspension bridge design before and it took us this long, so we believe…
I've seen counting tickets work fairly well. If the team is well-practised at breaking work down into tickets below a certain size, chances are good that the number of tickets completed per month will be fairly stable. That reduces the problem to "can you break this piece of work down into tickets, please", which isn't framed as an estimation problem with any attendant "no, that estimate's too big, try again" pressure. The bonus is that you can tell when a team has a stable enough process for this to work by looking at their ticket history over a few months, and the "estimate" (projection, really) is provided by the team themselves, so you don't get into a toxic situation where a team feels they're being held to an estimate someone else gave on their behalf.
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
At my last job, I think 15-20% of Engineering Team's time was allocated for estimations (including multiple back and forth to clarify specs with product etc.)