6 ms·

I'm surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I've found many

by bart3r 6y ago

I'm surprised there is no reference to time estimation. An important part of their role is estimating how long a task will take to complete, and I've found many people, even engineers with a lot of experience, are terrible at this.

AnimalMuppet 6y ago
One place I worked said that you weren't allowed to make an estimate that was longer than three weeks. There are apparently studies showing that estimates longer than that tend to have much larger errors. So if it was going to be longer, we had to break it up into pieces until each piece was smaller than three weeks. That could get tedious. On the other hand, we did do a lot better than normal at hitting our dates. (I believe this shorter-than-three-weeks idea came from Extreme Programming, but I'm not quite certain of that.)
- __alias 6y ago
  This is also why I like estimating tasks using the Fibonacci scale without a direct correlation to time. In my teams, we generally set 8 points as something that would take an entire day. Every number after that jumps up in relatively large increments as they are more difficult to accurately determine
  - BOOSTERHIDROGEN 6y ago
    Interesting take, mind sharing how do you use fibonacci ? Thanks
    - bart3r 6y ago
      https://www.youtube.com/watch?v=iZYSapFCg4A https://www.youtube.com/watch?v=iZYSapFCg4A
    - redis_mlc 6y ago
      0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610 Hope (Days) = Calculated Est. (Hours) 1 day = 8 hours 2 days = 8 + 13 = 21 hours 3 days = 8 + 13 + 21 = 34 hours H(days) = Fn(6+days) hours, where days >= 2
    - mgkimsal 6y ago
      Not the OP, but one of the teams I'm on uses fib somewhat differently. Any point with 1-2 is estimated at < 1 day. Some are literally 20 minute fixes, but ... you don't always know that up front, you just generally know it may be pretty small. 2 might sometimes go up to a day. A 3 is assumed to be a day or two. A 5 is assumed to be 3-4 days. An 8 would be 1-2 weeks. Anything higher is backlogged until it's broken down into smaller segments. Not sure how well that compares to usages by other teams, but that's one data point for your question.
  - deleted 6y ago
    [deleted]
- valenterry 6y ago
  But then, you still have to connect all these 3-weeks-pieces together. And how long does that take? No we are back to the original, overall question...
  - AnimalMuppet 6y ago
    The idea was that the three week pieces add up to the whole of the larger task. (Yeah, I know - only if you didn't miss anything. Take the time to think it through well enough that you don't do that. And what if you have things you don't know? Then you have to do a research project to find them out before you can give valid estimates.)
    - mgkimsal 6y ago
      "And what if you have things you don't know?" I usually find stuff out in the middle of work - a question comes up I don't have an answer for, and many times, no one else does either. In effect, no one can estimate it, but we didn't even know that up front. And... I've often hit things where the time to give an 'accurate' estimate takes more time than the actual work effort. Is that common in your "limit everything to 3 weeks" world?
      - deleted 6y ago
        [deleted]
      - AnimalMuppet 6y ago
        If the time to give a more accurate estimate takes more time than the actual work, you aren't dealing with an estimate longer than three weeks. If the estimate is less than a day, it's not worth getting more precise. To your first point: Yes, that happens sometimes. When it does, your estimates can be wrong. (Hey, they're estimates - they're not prophecies.) If that happens very often, though, you might add a fudge factor for "that kind of thing". Maybe something like "unknown surprises crop up most of the time, and when they do, they take about 20% of the effort, so we'll make our best estimate, then add 20%". That won't be perfect either - sometimes it will be 40%, and sometimes 0. But, you know, estimates...
slumdev 6y ago
> An important part of their role is estimating how long a task will take to complete Agile exists because a very large number of people dispute this.
- groby_b 6y ago
  And then jumps through large hoops to hide that it's still asking people to estimate. Sure, it's not hours, it's "velocity" and "difficulty", and you don't estimate, you play "Fibonacci Poker". But at the end of the day, the question "can we do this in the allotted amount of time" still gets asked and answered. What agile got right is realizing that the error bars increase superlinearly with duration, and that scope isn't fixed - so frequent estimates with frequent course correction. But you're still estimating.
  - deleted 6y ago
    [deleted]
  - Fire-Dragon-DoL 6y ago
    This is the definition of Agile, the officiak one: https://agilemanifesto.org/ https://agilemanifesto.org/
  - kthejoker2 6y ago
    First, allotting an amount of time to delivering value is an anti-pattern in itself. Second, Agile doesn't ask people to estimate ("respond to change over follow a plan"). Management asks people to estimate. Jeff Patton says it best in User Story Mapping, the "client-vendor anti-pattern" > It's the client's job to know what he wants, and explain the details to the vendor. It's the vendor's job to listen, understand, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate - which in software lingo actually means "commitment" .. > The real tragedy is the client understands their problem better than she's able to predict what will solve it. But in the anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins. > Try showing up at your doctor's office and giving her your "requirements". Tell her the prescriptions you'd like written and the operations you'd like scheduled. If she's nice, she'll smile and say, "That's interesting, tell me where it hurts." > In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships more like doctor-patient and less like waiter-diner.
Geminidog 6y ago
People in general are terrible at predicting the future... I don't think being clairvoyant is a quality that should be expected out of an engineer or anybody. This whole time estimation thing is akin to predicting when the next hurricane or earthquake will occur. The main problem is business people don't understand that so they place this unrealistic burden on engineers. A manager or business guy who needs constant and very accurate time predictions is a sign of a bad manager that is overly reliant on engineers and lacks understanding of software. A good manager should have the technical knowledge to make a technical guesstimate himself (that will also likely be wrong) and have the foresight to be able to manage delays and allow for buffer time. A great team of people creating a product consists of both great Technical product managers and great software engineers. A rockstar software Engineer alone may not have the ability to manage the politics of unrealistic expectations.
- username90 6y ago
  > This whole time estimation thing is akin to predicting when the next hurricane or earthquake will occur. This myth needs to die. Can you predict if an item will take closer to a month or a decade? If true then it is far easier to predict than hurricanes or earthquakes. You might not make predictions as accurate as management wants all the time, but most can predict how long things will take within a factor of 3x or so and it will be within that margin most of the time, a person who could do that for hurricanes or earthquakes would be the greatest genius in history. And yes as you get more skilled your predictions will become more accurate. Hence accurate predictions being a sign of skill.
  - Geminidog 6y ago
    >This myth needs to die. Let me spell it out in an example. Sports. Horse racing or basketball. You have a team of highly skilled players with a bunch of information quantized, including height, weight, score statistics, rebound statistics, biography... etc. And these guys are in a game with a very very controlled set of rules under exactly the same time pressure and everyone still fails to predict the outcome. In software you have a product. The product is usually not concretely defined and you have a complex code base and you can never be 100% sure exactly how the new product will integrate with that code base... you're also not 100% sure how the code will be put together to define the product. Additionally are you 100% familiar with the stack? Do you know every possible primitive of psql or ruby or python or C++ that you could be using to create your project because I pretty much guarantee you every basketball player more or less knows every possible move and rule of a basketball game. You're also working with a team that includes people that you have much less information on than normal. You worked with a guy for what at most two years does that give you accurate statistical information to the degree of say a basketball player? Also there's bound to be people you're less familiar with working on the project as well. Are you interacting with other teams as well? Does the outcome of your project hinge on the completion of a feature by an entire team outside of your own? People can be experts on horse races or sports. Even then they can't predict things accurately. If you were to start making bets on software development dates of completion. You will also massively fail because not only are there more variables in a software project... but you have much less information. Chaos is a phenomenon that happens to systems we have close to perfect information for. We find that if we have the perfect information of all the particles in a weather system except for say one particle. We find that information about that missing particle will make our mathematical calculation wildly inaccurate. For software we don't even have anything close to perfect information in a system with multitudes of variables. Chaos will throw any prediction off. >but most can predict how long things will take within a factor of 3x or so and it will be within that margin most of the time, a person who could do that for hurricanes or earthquakes would be the greatest genius in history. 3x of what. 3x can be big or small depending on x. So if I predict a project will take one year I can be off by 3 years under your logic. If I predict a month, than I can be off by 3 months. If I predict a week, 3 weeks. 3x is pretty horrible if you ask me, it's easy to make guesses within these parameters. I predict that both a hurricane and an earthquake will happen in a century. I'll only be off by 3x or 3 centuries. Actually I can do better than that. I'm 100% sure multiple earthquakes and multiple hurricanes will happen in the next century and I am 100% sure that I will by 0x off let alone 3x.... Look I'm the greatest genius in history. 3x is not a reasonable margin of error.

by bart3r 6y ago

AnimalMuppet 6y ago

One place I worked said that you weren't allowed to make an estimate that was longer than three weeks. There are apparently studies showing that estimates longer than that tend to have much larger errors. So if it was going to be longer, we had to break it up into pieces until each piece was smaller than three weeks. That could get tedious. On the other hand, we did do a lot better than normal at hitting our dates. (I believe this shorter-than-three-weeks idea came from Extreme Programming, but I'm not quite certain of that.)

__alias 6y ago
This is also why I like estimating tasks using the Fibonacci scale without a direct correlation to time. In my teams, we generally set 8 points as something that would take an entire day. Every number after that jumps up in relatively large increments as they are more difficult to accurately determine
- BOOSTERHIDROGEN 6y ago
  Interesting take, mind sharing how do you use fibonacci ? Thanks
  - bart3r 6y ago
    https://www.youtube.com/watch?v=iZYSapFCg4A https://www.youtube.com/watch?v=iZYSapFCg4A
  - redis_mlc 6y ago
    0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610 Hope (Days) = Calculated Est. (Hours) 1 day = 8 hours 2 days = 8 + 13 = 21 hours 3 days = 8 + 13 + 21 = 34 hours H(days) = Fn(6+days) hours, where days >= 2
  - mgkimsal 6y ago
    Not the OP, but one of the teams I'm on uses fib somewhat differently. Any point with 1-2 is estimated at < 1 day. Some are literally 20 minute fixes, but ... you don't always know that up front, you just generally know it may be pretty small. 2 might sometimes go up to a day. A 3 is assumed to be a day or two. A 5 is assumed to be 3-4 days. An 8 would be 1-2 weeks. Anything higher is backlogged until it's broken down into smaller segments. Not sure how well that compares to usages by other teams, but that's one data point for your question.
- deleted 6y ago
  [deleted]
valenterry 6y ago
But then, you still have to connect all these 3-weeks-pieces together. And how long does that take? No we are back to the original, overall question...
- AnimalMuppet 6y ago
  The idea was that the three week pieces add up to the whole of the larger task. (Yeah, I know - only if you didn't miss anything. Take the time to think it through well enough that you don't do that. And what if you have things you don't know? Then you have to do a research project to find them out before you can give valid estimates.)
  - mgkimsal 6y ago
    "And what if you have things you don't know?" I usually find stuff out in the middle of work - a question comes up I don't have an answer for, and many times, no one else does either. In effect, no one can estimate it, but we didn't even know that up front. And... I've often hit things where the time to give an 'accurate' estimate takes more time than the actual work effort. Is that common in your "limit everything to 3 weeks" world?
    - deleted 6y ago
      [deleted]
    - AnimalMuppet 6y ago
      If the time to give a more accurate estimate takes more time than the actual work, you aren't dealing with an estimate longer than three weeks. If the estimate is less than a day, it's not worth getting more precise. To your first point: Yes, that happens sometimes. When it does, your estimates can be wrong. (Hey, they're estimates - they're not prophecies.) If that happens very often, though, you might add a fudge factor for "that kind of thing". Maybe something like "unknown surprises crop up most of the time, and when they do, they take about 20% of the effort, so we'll make our best estimate, then add 20%". That won't be perfect either - sometimes it will be 40%, and sometimes 0. But, you know, estimates...

slumdev 6y ago

> An important part of their role is estimating how long a task will take to complete Agile exists because a very large number of people dispute this.

groby_b 6y ago
And then jumps through large hoops to hide that it's still asking people to estimate. Sure, it's not hours, it's "velocity" and "difficulty", and you don't estimate, you play "Fibonacci Poker". But at the end of the day, the question "can we do this in the allotted amount of time" still gets asked and answered. What agile got right is realizing that the error bars increase superlinearly with duration, and that scope isn't fixed - so frequent estimates with frequent course correction. But you're still estimating.
- deleted 6y ago
  [deleted]
- Fire-Dragon-DoL 6y ago
  This is the definition of Agile, the officiak one: https://agilemanifesto.org/ https://agilemanifesto.org/
- kthejoker2 6y ago
  First, allotting an amount of time to delivering value is an anti-pattern in itself. Second, Agile doesn't ask people to estimate ("respond to change over follow a plan"). Management asks people to estimate. Jeff Patton says it best in User Story Mapping, the "client-vendor anti-pattern" > It's the client's job to know what he wants, and explain the details to the vendor. It's the vendor's job to listen, understand, and then think through a technical approach for delivering what the client asked for. The vendor then gives her estimate - which in software lingo actually means "commitment" .. > The real tragedy is the client understands their problem better than she's able to predict what will solve it. But in the anti-pattern, conversations about problems and solutions are replaced by discussions and agreements about requirements. No one wins. > Try showing up at your doctor's office and giving her your "requirements". Tell her the prescriptions you'd like written and the operations you'd like scheduled. If she's nice, she'll smile and say, "That's interesting, tell me where it hurts." > In my head, I picture a continuum where on one side is the word waiter, and on the other is the word doctor. Try to make your working relationships more like doctor-patient and less like waiter-diner.

Geminidog 6y ago

People in general are terrible at predicting the future... I don't think being clairvoyant is a quality that should be expected out of an engineer or anybody. This whole time estimation thing is akin to predicting when the next hurricane or earthquake will occur. The main problem is business people don't understand that so they place this unrealistic burden on engineers. A manager or business guy who needs constant and very accurate time predictions is a sign of a bad manager that is overly reliant on engineers and lacks understanding of software. A good manager should have the technical knowledge to make a technical guesstimate himself (that will also likely be wrong) and have the foresight to be able to manage delays and allow for buffer time. A great team of people creating a product consists of both great Technical product managers and great software engineers. A rockstar software Engineer alone may not have the ability to manage the politics of unrealistic expectations.

username90 6y ago
> This whole time estimation thing is akin to predicting when the next hurricane or earthquake will occur. This myth needs to die. Can you predict if an item will take closer to a month or a decade? If true then it is far easier to predict than hurricanes or earthquakes. You might not make predictions as accurate as management wants all the time, but most can predict how long things will take within a factor of 3x or so and it will be within that margin most of the time, a person who could do that for hurricanes or earthquakes would be the greatest genius in history. And yes as you get more skilled your predictions will become more accurate. Hence accurate predictions being a sign of skill.
- Geminidog 6y ago
  >This myth needs to die. Let me spell it out in an example. Sports. Horse racing or basketball. You have a team of highly skilled players with a bunch of information quantized, including height, weight, score statistics, rebound statistics, biography... etc. And these guys are in a game with a very very controlled set of rules under exactly the same time pressure and everyone still fails to predict the outcome. In software you have a product. The product is usually not concretely defined and you have a complex code base and you can never be 100% sure exactly how the new product will integrate with that code base... you're also not 100% sure how the code will be put together to define the product. Additionally are you 100% familiar with the stack? Do you know every possible primitive of psql or ruby or python or C++ that you could be using to create your project because I pretty much guarantee you every basketball player more or less knows every possible move and rule of a basketball game. You're also working with a team that includes people that you have much less information on than normal. You worked with a guy for what at most two years does that give you accurate statistical information to the degree of say a basketball player? Also there's bound to be people you're less familiar with working on the project as well. Are you interacting with other teams as well? Does the outcome of your project hinge on the completion of a feature by an entire team outside of your own? People can be experts on horse races or sports. Even then they can't predict things accurately. If you were to start making bets on software development dates of completion. You will also massively fail because not only are there more variables in a software project... but you have much less information. Chaos is a phenomenon that happens to systems we have close to perfect information for. We find that if we have the perfect information of all the particles in a weather system except for say one particle. We find that information about that missing particle will make our mathematical calculation wildly inaccurate. For software we don't even have anything close to perfect information in a system with multitudes of variables. Chaos will throw any prediction off. >but most can predict how long things will take within a factor of 3x or so and it will be within that margin most of the time, a person who could do that for hurricanes or earthquakes would be the greatest genius in history. 3x of what. 3x can be big or small depending on x. So if I predict a project will take one year I can be off by 3 years under your logic. If I predict a month, than I can be off by 3 months. If I predict a week, 3 weeks. 3x is pretty horrible if you ask me, it's easy to make guesses within these parameters. I predict that both a hurricane and an earthquake will happen in a century. I'll only be off by 3x or 3 centuries. Actually I can do better than that. I'm 100% sure multiple earthquakes and multiple hurricanes will happen in the next century and I am 100% sure that I will by 0x off let alone 3x.... Look I'm the greatest genius in history. 3x is not a reasonable margin of error.