4 ms·

> In the software development world, it is impossible to produce meaningful estimates, let alone precise ones, for anything but nano-tasks. Why is the notion o

> In the software development world, it is impossible to produce meaningful estimates, let alone precise ones, for anything but nano-tasks. Why is the notion of this repeated so often? It's not _impossible_ to differentiate between tasks that take a few hours, a few days and a few weeks, where such estimates are useful enough to make business decisions (e.g. how much to charge, if the time/benefit is worth it). Sometimes you'll go over and sometimes you'll go under in your estimate but an estimate is meant to be a ballpark figure to help make decisions. I track my estimates and actual time when bidding on fixed price projects and I don't find it hard to be pretty accurate; of course it helps if it's a project that's similar to something you've done before though. To put another way, if a manager is trying to decide how much to charge a client for a project or is trying to decide which of two new features has the best cost/benefit ratio, what do you expect them to do if engineers can just say "I will not provide any estimates because estimates are impossible"? Every industry uses estimates and estimates are expected to be a ballpark figure only.

SatvikBeri 10y ago
Some anecdata: I also used to believe estimates were nigh useless. This quarter we made a serious effort to estimate the work involved in each task, across a team of 5 people–so a total of roughly 50 person-weeks of work, broken up into tasks of 1-6 weeks. And this was for a project that involved building a new product, using a lot of technologies we hadn't used before. Almost every estimate was on point. There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week. Now, I definitely think that we got lucky in some significant ways, and I wouldn't bet on being able to achieve the same level of accuracy next quarter. But I'm a lot more optimistic about the possibility of estimates than I used to be.
- alfonsodev 10y ago
  The problem is that as you said it takes a 'serious effort', and yet you think you were "lucky"(perhaps experienced, intuitive, mature, knowledgable enough), but other teams that aren't so "lucky" make the same effort without the results and get frustrated, because is frustrating to be late all the time. So I can understand that some people just want to drop estimations, but I don't agree. I wrote a comment below on why still we need estimations and how I think the risk and frustration could be reduced.
- makmanalp 10y ago
  I kind of agree with this - recently I had a good manager who forced us to do proper estimates. He had a knack for noticing things like "hey, this task you put together is way too big to be one task" or "this task is super vague". And often he was right: if your tasks are all like "implement X feature", you're going to be way off. I realized that I just fundamentally misunderstood how I should be doing estimation. Previously, the way I did it was "well it sort of feels like a day, I guess". Now, what we did was: a) Before estimating, have some certainty about what exactly we want the feature / behavior to be. This is usually the top mistake teams make, and it's a problem. This can come from talking to users, designers, whoever. Focus groups, user testing, design sprints, whatever you want. This all happens before the estimation starts. If you're figuring out what a feature should be doing while estimating time, or even worse, while implementing the feature, you've failed already, and all bets are off in terms of estimates, but also just in terms of finishing things in a reasonable amount of time and in terms of actually building a feature that an end user wants, as opposed to building what's convenient to the developer at the time. It also helps the developer because it's not actually fun to be figuring out requirements in the middle of writing code. b) Now that you have certainty, you go do research. Have you done a thing similar to this before? Pull up the ticket. How long did it take? Whose time did it take? What were the pitfalls, if any? Then go look at some code and start thinking about implementation: what would this take? What modules / files would you have to change? Does this have architectural implications? Should you be talking to anyone else? When you start doing this, you force yourself to think about the actual, real work to be done, and away from the realm of hazy bullshitting. You find all sorts of weird issues you didn't see before, which helps your estimates be much more accurate. Put these in the ticket, to ask your teammates about later. You find things about the task itself that are vague. Note these in the ticket also, and remember to ask about them later. You also can immediately tell if you need someone else to do something before you can get started, so make a separate ticket for that and assign to the appropriate person. Also, resist the temptation to write code just yet. Finally, now, you can make an estimate. Some people prefer t-shirt sizes, others prefer hours. It doesn't matter, just pick one, have it standard across the team, and go with it. c) Now that you have a clear set of features and a reasonably clear roadmap, you and your team sit down together at a table. You discuss work that needs to be done. You bring up issues to each other about tickets. If any of them get solved (often does), then great. If not, it gets moved to the next sprint, along with anything that depends on that. If it's urgent, you make a new, separate "research" task with the purpose of figuring out the remaining details, and leave some room at the end of the sprint to possibly be able to pull in that new task, once it's well-defined. You never pull in a task for a sprint by making up a bullshit estimate for it, regardless of top-down pressure. Every time we violated this rule, it ended up biting us in the ass. Finally, now with actual estimates, you as a team make decisions on what takes high-low priority. Then you figure out blockers: what needs to be done first so other team members can work on things, and you focus on those first. Then there is stuff like Anyway, if you start doing this seriously, in a few sprints you'll be hitting estimates like clockwork. It's actually a very satisfying feeling to have clearly defined tasks and execute as a team. And for reference, a) was done by our manager / designer before the sprint planning. b) and c) used to take us around half a day (3-4ish hours) total to plan a 2 week sprint. All in all, very worth it. edit: Final rule here is that the people who are doing the work decide on the estimates themselves. Never management. Other engineers get to weigh in, but only to make the estimate larger, not smaller. This takes off a lot of pressure from engineers in terms of delivering. At first, the focus is to plan a sprint and just deliver on what you planned. If that means taking on less work, and you finish early, then fine. You can always take on more work once you're done. Once you can always deliver what you promised, only then do you start adding more work. This way, everyone is realistic about the work that can be done, and overpromising is less of an issue. If there is something urgent, the manager gets to say "hey look, this is what we're committing to this week, these are what we'd have to not do to do the thing you want. This is a level of transparency that usually makes stakeholders happy, and at that point they're free to make the decision, as opposed to being angry later.
- seanwilson 10y ago
  > Almost every estimate was on point. There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week. Exactly, and in other cases you'd have a 5 day estimated task that took 2 weeks but given enough estimates the high and low ones should roughly balance out. If estimates are always widely inaccurate there's a big problem somewhere.
  - pdimitar 10y ago
    Yes there is a big problem. Managers reducing all estimates in the hopes of looking professional and thus getting a raise from a higher-level manager, making the programmers' lives a living nightmare in the process. It's the same problem 99% of the time.
    - deleted 10y ago
      [deleted]
daryl_antony 10y ago
The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those. I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that. The next best thing you can do is to agree to work diligently with your team to implement those stories, without waste, towards a stakeholder and team agreed _definition of done_.
- jon-wood 10y ago
  These days I sit somewhere in the middle, I don't give precise estimates because they'll inevitably be wrong, but I am willing to use a kind of log scale when estimating tasks with real time. Estimates come in the form of n hours, n days, n weeks, or n months, and a heavy caveat that the less granular the estimate the less accurate I expect it to be. I'll also never commit to working on any task with an estimate over a day or two, weeks and months are solely for long term planning and deciding which of several large projects should be taken on first.
  - seanwilson 10y ago
    Sounds sensible to me. For longer tasks, I also think it's useful to say (where practical) "I'm really not sure because there are too many unknowns but if you let me work on it for X hours first I can provide a more accurate estimate then". I think the important points are to always caveat estimates, build risks + unknowns into the estimates, update estimates as the situation evolves and never allow yourself to commit to an estimate with too many unknowns.
- seanwilson 10y ago
  > The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. I would only ever say an estimate was wrong if it was widely out and you could have reasonably been a lot more accurate with a small amount of effort. Once people accept that some estimates will turn out to be too high and too some too low but they should mostly balance out instead of treating them all as very accurate it should be less of an issue. > The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those. That's a team problem with how estimates are treated that has to be fixed though. Estimates are estimates and not reading the future. If developers are treated like that for estimates the same problem will just manifest with whatever other system you come up with. > I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that. What would you do for a fixed price project then where the client wants an agreed figure to pay for a delivered product (e.g. a few months of work)? If you're too high they won't accept the contract and if you're too low you'll lose money. You cannot avoid estimates here.

SatvikBeri 10y ago

Some anecdata: I also used to believe estimates were nigh useless. This quarter we made a serious effort to estimate the work involved in each task, across a team of 5 people–so a total of roughly 50 person-weeks of work, broken up into tasks of 1-6 weeks. And this was for a project that involved building a new product, using a lot of technologies we hadn't used before. Almost every estimate was on point. There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week. Now, I definitely think that we got lucky in some significant ways, and I wouldn't bet on being able to achieve the same level of accuracy next quarter. But I'm a lot more optimistic about the possibility of estimates than I used to be.

alfonsodev 10y ago
The problem is that as you said it takes a 'serious effort', and yet you think you were "lucky"(perhaps experienced, intuitive, mature, knowledgable enough), but other teams that aren't so "lucky" make the same effort without the results and get frustrated, because is frustrating to be late all the time. So I can understand that some people just want to drop estimations, but I don't agree. I wrote a comment below on why still we need estimations and how I think the risk and frustration could be reduced.
makmanalp 10y ago
I kind of agree with this - recently I had a good manager who forced us to do proper estimates. He had a knack for noticing things like "hey, this task you put together is way too big to be one task" or "this task is super vague". And often he was right: if your tasks are all like "implement X feature", you're going to be way off. I realized that I just fundamentally misunderstood how I should be doing estimation. Previously, the way I did it was "well it sort of feels like a day, I guess". Now, what we did was: a) Before estimating, have some certainty about what exactly we want the feature / behavior to be. This is usually the top mistake teams make, and it's a problem. This can come from talking to users, designers, whoever. Focus groups, user testing, design sprints, whatever you want. This all happens before the estimation starts. If you're figuring out what a feature should be doing while estimating time, or even worse, while implementing the feature, you've failed already, and all bets are off in terms of estimates, but also just in terms of finishing things in a reasonable amount of time and in terms of actually building a feature that an end user wants, as opposed to building what's convenient to the developer at the time. It also helps the developer because it's not actually fun to be figuring out requirements in the middle of writing code. b) Now that you have certainty, you go do research. Have you done a thing similar to this before? Pull up the ticket. How long did it take? Whose time did it take? What were the pitfalls, if any? Then go look at some code and start thinking about implementation: what would this take? What modules / files would you have to change? Does this have architectural implications? Should you be talking to anyone else? When you start doing this, you force yourself to think about the actual, real work to be done, and away from the realm of hazy bullshitting. You find all sorts of weird issues you didn't see before, which helps your estimates be much more accurate. Put these in the ticket, to ask your teammates about later. You find things about the task itself that are vague. Note these in the ticket also, and remember to ask about them later. You also can immediately tell if you need someone else to do something before you can get started, so make a separate ticket for that and assign to the appropriate person. Also, resist the temptation to write code just yet. Finally, now, you can make an estimate. Some people prefer t-shirt sizes, others prefer hours. It doesn't matter, just pick one, have it standard across the team, and go with it. c) Now that you have a clear set of features and a reasonably clear roadmap, you and your team sit down together at a table. You discuss work that needs to be done. You bring up issues to each other about tickets. If any of them get solved (often does), then great. If not, it gets moved to the next sprint, along with anything that depends on that. If it's urgent, you make a new, separate "research" task with the purpose of figuring out the remaining details, and leave some room at the end of the sprint to possibly be able to pull in that new task, once it's well-defined. You never pull in a task for a sprint by making up a bullshit estimate for it, regardless of top-down pressure. Every time we violated this rule, it ended up biting us in the ass. Finally, now with actual estimates, you as a team make decisions on what takes high-low priority. Then you figure out blockers: what needs to be done first so other team members can work on things, and you focus on those first. Then there is stuff like Anyway, if you start doing this seriously, in a few sprints you'll be hitting estimates like clockwork. It's actually a very satisfying feeling to have clearly defined tasks and execute as a team. And for reference, a) was done by our manager / designer before the sprint planning. b) and c) used to take us around half a day (3-4ish hours) total to plan a 2 week sprint. All in all, very worth it. edit: Final rule here is that the people who are doing the work decide on the estimates themselves. Never management. Other engineers get to weigh in, but only to make the estimate larger, not smaller. This takes off a lot of pressure from engineers in terms of delivering. At first, the focus is to plan a sprint and just deliver on what you planned. If that means taking on less work, and you finish early, then fine. You can always take on more work once you're done. Once you can always deliver what you promised, only then do you start adding more work. This way, everyone is realistic about the work that can be done, and overpromising is less of an issue. If there is something urgent, the manager gets to say "hey look, this is what we're committing to this week, these are what we'd have to not do to do the thing you want. This is a level of transparency that usually makes stakeholders happy, and at that point they're free to make the decision, as opposed to being angry later.
seanwilson 10y ago
> Almost every estimate was on point. There was one task estimated at 3 weeks that took two days, and one two week task that took 5. Other than that, every estimate was within a week. Exactly, and in other cases you'd have a 5 day estimated task that took 2 weeks but given enough estimates the high and low ones should roughly balance out. If estimates are always widely inaccurate there's a big problem somewhere.
- pdimitar 10y ago
  Yes there is a big problem. Managers reducing all estimates in the hopes of looking professional and thus getting a raise from a higher-level manager, making the programmers' lives a living nightmare in the process. It's the same problem 99% of the time.
  - deleted 10y ago
    [deleted]

daryl_antony 10y ago

The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those. I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that. The next best thing you can do is to agree to work diligently with your team to implement those stories, without waste, towards a stakeholder and team agreed _definition of done_.

jon-wood 10y ago
These days I sit somewhere in the middle, I don't give precise estimates because they'll inevitably be wrong, but I am willing to use a kind of log scale when estimating tasks with real time. Estimates come in the form of n hours, n days, n weeks, or n months, and a heavy caveat that the less granular the estimate the less accurate I expect it to be. I'll also never commit to working on any task with an estimate over a day or two, weeks and months are solely for long term planning and deciding which of several large projects should be taken on first.
- seanwilson 10y ago
  Sounds sensible to me. For longer tasks, I also think it's useful to say (where practical) "I'm really not sure because there are too many unknowns but if you let me work on it for X hours first I can provide a more accurate estimate then". I think the important points are to always caveat estimates, build risks + unknowns into the estimates, update estimates as the situation evolves and never allow yourself to commit to an estimate with too many unknowns.
seanwilson 10y ago
> The trouble with estimates is that they're always wrong, and we're left to deal with the degree in which they're wrong. I would only ever say an estimate was wrong if it was widely out and you could have reasonably been a lot more accurate with a small amount of effort. Once people accept that some estimates will turn out to be too high and too some too low but they should mostly balance out instead of treating them all as very accurate it should be less of an issue. > The problem with that is that we have no insight on how much they'll be wrong and our reputations as developers get hung out to dry on those. That's a team problem with how estimates are treated that has to be fixed though. Estimates are estimates and not reading the future. If developers are treated like that for estimates the same problem will just manifest with whatever other system you come up with. > I think its better to work with what you can control. You can size stories (S, M, L, XL) to the point of consensus with everyone in the room; so work with that. What would you do for a fixed price project then where the client wants an agreed figure to pay for a delivered product (e.g. a few months of work)? If you're too high they won't accept the contract and if you're too low you'll lose money. You cannot avoid estimates here.