7 ms·

The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth i

The business wants to know how much feature X is going to cost and when they can expect it. They need to know that, because they need to decide if it's worth it in the first place, or because they need to plan follow-up actions for when the feature will be done. If the developer doesn't make estimates, you're just forcing other people to make their own estimates, that they'll hold you to.

RandallBrown 8y ago
Nobody should make estimates. They're always wrong. Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc. That's how you figure out when things will be done.
- PaulHoule 8y ago
  That is bull. Some tasks have a high degree of uncertainty. Others don't. Back when I was using a ruby-on-rails style framework (in PHP) I would frequently get 20 hours of work estimated properly down to 15 minutes when it came to adding simple features to a web application. If on the other hand you are trying to figure out the gap between what the documentation says should work and what actually works, that is hard to estimate.
  - carlmr 8y ago
    And nevermind the technical issues. If you need to work with others, that's where estimating gets hard.
- lordCarbonFiber 8y ago
  That act of breaking up and organizing tasks of the same size, that's what estimation is. This feature has these tasks, historically we complete these tasks in this time, so here's a hard minimum for a completion date (which implies cost). Slap on an appropriate fudge factor for dealing with other teams, testing and burn in, and general error bounds as needed. You've described scrum, what you're doing is scrum.
  - RandallBrown 8y ago
    It's not scrum. There's no sprints or commitments.
- aplummer 8y ago
  Don’t make estimates, make... forecasts?
  - pugworthy 8y ago
    This kind of word game in agile drives me crazy. It’s like points aren’t hours, but if I estimate (er, forecast) how many hours it will take, its pretty easy to turn that into points, and vice versa. I suppose it’s like one of those, “There is no word for it in English, but it essentially means...”
    - pas 8y ago
      Points are a team-internal measure of a task. You can after the fact convert points to time, and then after a few sprints (when you have a fairly stable average velocity) then you can convert points to hours and do a forecast/estimation. // In my mind you forecast the date of completion, but you estimate the amount of work. It's probably just mindless semantics, after all saying you can estimate the date of completion sounds just as natural, but saying you can forecast the amount of work sounds a bit unnatural.
  - otaviokz 8y ago
    Sure, just throw some marketing style word play at it. Who knows, maybe this time it will stick?
- deleted 8y ago
  [deleted]
- Scarblac 8y ago
  That's making estimates.
- ryanSrich 8y ago
  This is the perfect recipe for never delivering anything. Without release dates developers will continue building and gold plating and building and gold plating. Create your tasks, estimate your tasks, put a date out there, and hit the date. If the product has bugs, unfinished features, then so be it. Users understand flaws. They don't understand missed dates.
  - gnome_chomsky 8y ago
    Not all developers are gold platers. That seems to be a more common behavior among inexperienced developers.
    - reallydontask 8y ago
      That's interesting as in my experience is exactly the other way about. It's the experienced developers that try to gold plate to avoid the issues that they had in the last project or two projects ago, whereas the juniors ship code quickly but unfortunately often incomplete and certainly lacking a reasonable amount of test coverage
      - someone7x 8y ago
        > It's the experienced developers that try to gold plate to avoid the issues that they had in the last project Literally learning from the past and applying it to the present is “gold plating”? I’m stunned.
        ncallaway 8y ago
        I don't think the parent poster was saying that the learning itself was bad. I think the gold plating they're referring to is a form of over-correcting. The learning itself is good, and correcting prior issues is good. But over-correcting and over-learning can be problematic and can lead to gold plating. I don't think there's any easy indication of the line between the right-amount of correction and over-correction, but I don't think it's unreasonable to state that one can over-correct based on prior experiences.
- clavalle 8y ago
  Estimates are always wrong only if they are concrete estimates as if they were certain. If, instead, they are 90% ranges (I am 90% sure that this will be done between x and y) then it is much easier to estimate accurately. It is also easier to spot bullshit (if the spread doesn't go up as your time to completion moves further from now, it is probably a bullshit estimate).
  - tonyarkles 8y ago
    I really love the method from The Clean Coder, where you make best/median/worst estimates for tasks and then add them up to a mean and standard deviation. This helps capture the truth of “we don’t know how long it’s going to take, but it’s likely between x and y”. Where this still falls apart, for me, is knowing how many hours per day I’ll be able to spend on each project. I have multiple clients, and things come up. This method has gotten me very good at the budget aspect of project estimation, but the scheduling aspect still slips some (it’s rare that more hours in a day become available)
- matthewmacleod 8y ago
  Do your best to break tasks up so that all tasks are the same size That is estimation, in the Scrum sense.
ramraj07 8y ago
Only issue being that the estimates one gets from poorly planned sprints are probably less reliable than just asking the devs how long the project will take and going with it.
- hopler 8y ago
  Good estimates come from watching people deliver over time and scientifically comparing empirical performance to subjective estimates, not asking them to predict. Joel Spolsky has a great blog post on Painless Software Schedules.
  - kitsune_ 8y ago
    There is nothing scientific about this method in my opinion. You do not make consistent reproducible experiments, you do not control for anything, you haven't even formed a null hypothesis etc.
BurningFrog 8y ago
> The business wants to know how much feature X is going to cost and when they can expect it. Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months. The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise. The agile concept of "velocity" is the best way I know of managing this. It's not very good, and it's often a victim of Goodhart's law.
- jrs235 8y ago
  And velocity should be an internal team measurement not shared with outsiders because (Goodhart's Law) when management says "Let's increase our velocity" and the team and developers are GRADED/PROMOTED on their velocity then you'll get point/estimate inflation which will hurt you more in the long run since the inflated estimates actually now allow for the work to fill the time (Parkinson's law).
- borski 8y ago
  Engineering does not have to lie. All this takes is design and specification upfront, a well-defined feature set, and room for error. Also, avoiding scope creep is paramount.
  - pas 8y ago
    What's the usual processing speed of a software engineer when it comes to reading through and understanding design & specification? We found that usually either the documentation/specification/requirements are too fine grained (and then they then change all the time, but then there's no real effort/bandwidth to do change management on the specs), or they are not detailed enough, which makes the estimation process a useless guessing game on what might they mean by this or that.
    - borski 8y ago
      See, I would expect the engineers to pipe up and explain that. It takes collaboration to get it right, and it takes the engineers setting expectations properly for what they need to estimate accurately. It’s a collaborative effort, not a one-way street, as with most things.
watwut 8y ago
Theoretically. Practicaly they don't do that kind of planning and high estimate leads to pressure to lower it down (or making you feel ashamed for it being to big etc), which most developers will do, because developers tend to sux at negotiation.
- beat 8y ago
  That's where it breaks down. If you strip the Scrum-Industrial Complex nonsense away, one of the basic concepts of Scrum planning is that the business gets to define the stories, and the developers get to assign the points (or whatever mechanism is being used to estimate). Business sets the scope, technical sets the resource requirements. If developers can't hold the line on estimates, they're toast. Nothing will ever get done on time or under budget, because the organization is focused on basic dishonesty about what work can actually get done. Which means people are being rewarded for the wrong things. Measure by estimate accuracy rather than promises made, and you'll see a lot more honesty in estimation.
beat 8y ago
Another bit of wisdom I got from Kent Beck is that there are three basic controls to every project... schedule, scope, and resources. You can only control two of them. And resources are generally fixed at the beginning of the project(1), so most projects are either scope-bound (we must have all these features), or schedule-bound (we must hit this hard date). If you're feature-bound, estimation failure means you'll be late. If you're schedule-bound, estimation failure means you'll be incomplete. This can be a very hard pill for the business to swallow. They want it all, and they want a predictable schedule. But Beck's triangle is akin to thermodynamics. Do you want the volume, or the pressure, or the temperature? When fixing devops-related and agile-related process problems, I often hear "But we're a schedule-driven company!" when they have a scope-driven problem like process transformation. 1. As The Mythical Man-Month pointed out almost 50 years ago, adding resources to a late project makes it even later.
- house9-2 8y ago
  > If you're schedule-bound, estimation failure means you'll be incomplete. Schedule-Bound development (or Deadline Driven Development) can actually work well with minimal estimation as long as you are truly building MVP (minimum viable product), you have to ruthlessly slash features and only build the core features that are going to deliver the most bang for the buck. Not easily done.
- Drdrdrq 8y ago
  There is a fourth control of course which comes into play when nothing else will give room: quality. You can take many shortcuts to deliver in time, full scope, with the resources available. But the result will be buggy and/or unmaintainable. Surprising amount of companies choose this path, I guess most without realizing it.
  - pas 8y ago
    Quality is basically inherent in scope. Is testing the product in scope? Yes, then it will take up precious resources (time). Do you want to test it on every platform? Yes, even more time. (And of course the same goes for code review, writing unit tests, planning, writing and discussing a design document, etc.)
MrBuddyCasino 8y ago
> They need to know that, because they need to decide if it's worth it in the first place Thats only if that feature is optional. Often it isn't, and then it is pointless to estimate. Absolutely pointless.
- dragonwriter 8y ago
  > Thats only if that feature is optional. If it's optional, they need to know to make a decision to include or exclude it. If it's not optional for the project, but the project itself is optional, they need to know to make a decision to kill or keep the project. If it's not optional to the project , and the project is not optional to the business, they need to know to decide whether they keep or fold the business. In any case, if they might choose to keep the business, project, and feature, they need to know because they have to budget for the cost if they do so. So, essentially, business always needs to know the cost.
tybit 8y ago
I think this is totally reasonable at certain times. E.g how long will it take to add feature x with scope y to our existing product is a decent thing to estimate (and estimate only) for stakeholders to prioritise appropriately. I think most problems people have with estimates is when they are applied to things too large, or too small, to reasonably estimate. E.g How long will it take to build this product from scratch with a laundry list of features. Or more commonly, to micromanage. Why does anyone care whether this task will take 2 days as opposed to 3? That’s not meanginful information unless you’re mistakently expecting the individual user story estimates to add up to a reliable assembly line of work. I’m happy to estimate when it has some business purpose. If not, it’s meaningless busy work or worse.
gregmac 8y ago
> They need to know that, because they need to decide if it's worth it in the first place If this is the case, they should also be able to state the threshold above which the item would be "not worth it", and I would assume this is significantly easier to figure out than it takes developers to build a decent estimate. From a developer point-of-view, the first high-level estimate is then much, much simpler: "Is it going to take more or less than $not_worth_it to build?" If the answer is "more", then it gets dropped -- at least in its current state. It could be re-scoped later as a new item with a smaller MVP, for example. If the answer is "less", then the developer can put in the time to get a proper estimate. I think there might also be an argument that if the backlog is properly ranked the detailed estimate also becomes pointless -- just work on it until it's done. No one should be doing detailed estimates on items that are more than a few weeks/sprints away in the first place. Disclaimer: I've only recently been thinking about this abstractly, and have not yet tested this in practice, though I'd love to have this discussion with anyone that has.
- stevesimmons 8y ago
  Then the project sponsors would have to estimate value at a granular level. Which is essentially just as inconvenient for the business to estimate as schedule is for developers. They are more important in the organisation, so they don't, and instead insist on perfect estimates from the dev team.

RandallBrown 8y ago

Nobody should make estimates. They're always wrong. Do your best to break tasks up so that all tasks are the same size. Then work on tasks. You'll find a stable average of tasks per amount of time and that will let you forecast how long things will take, how much they'll cost, etc. That's how you figure out when things will be done.

PaulHoule 8y ago
That is bull. Some tasks have a high degree of uncertainty. Others don't. Back when I was using a ruby-on-rails style framework (in PHP) I would frequently get 20 hours of work estimated properly down to 15 minutes when it came to adding simple features to a web application. If on the other hand you are trying to figure out the gap between what the documentation says should work and what actually works, that is hard to estimate.
- carlmr 8y ago
  And nevermind the technical issues. If you need to work with others, that's where estimating gets hard.
lordCarbonFiber 8y ago
That act of breaking up and organizing tasks of the same size, that's what estimation is. This feature has these tasks, historically we complete these tasks in this time, so here's a hard minimum for a completion date (which implies cost). Slap on an appropriate fudge factor for dealing with other teams, testing and burn in, and general error bounds as needed. You've described scrum, what you're doing is scrum.
- RandallBrown 8y ago
  It's not scrum. There's no sprints or commitments.
aplummer 8y ago
Don’t make estimates, make... forecasts?
- pugworthy 8y ago
  This kind of word game in agile drives me crazy. It’s like points aren’t hours, but if I estimate (er, forecast) how many hours it will take, its pretty easy to turn that into points, and vice versa. I suppose it’s like one of those, “There is no word for it in English, but it essentially means...”
  - pas 8y ago
    Points are a team-internal measure of a task. You can after the fact convert points to time, and then after a few sprints (when you have a fairly stable average velocity) then you can convert points to hours and do a forecast/estimation. // In my mind you forecast the date of completion, but you estimate the amount of work. It's probably just mindless semantics, after all saying you can estimate the date of completion sounds just as natural, but saying you can forecast the amount of work sounds a bit unnatural.
- otaviokz 8y ago
  Sure, just throw some marketing style word play at it. Who knows, maybe this time it will stick?
deleted 8y ago
[deleted]
Scarblac 8y ago
That's making estimates.
ryanSrich 8y ago
This is the perfect recipe for never delivering anything. Without release dates developers will continue building and gold plating and building and gold plating. Create your tasks, estimate your tasks, put a date out there, and hit the date. If the product has bugs, unfinished features, then so be it. Users understand flaws. They don't understand missed dates.
- gnome_chomsky 8y ago
  Not all developers are gold platers. That seems to be a more common behavior among inexperienced developers.
  - reallydontask 8y ago
    That's interesting as in my experience is exactly the other way about. It's the experienced developers that try to gold plate to avoid the issues that they had in the last project or two projects ago, whereas the juniors ship code quickly but unfortunately often incomplete and certainly lacking a reasonable amount of test coverage
    - someone7x 8y ago
      > It's the experienced developers that try to gold plate to avoid the issues that they had in the last project Literally learning from the past and applying it to the present is “gold plating”? I’m stunned.
      - ncallaway 8y ago
        I don't think the parent poster was saying that the learning itself was bad. I think the gold plating they're referring to is a form of over-correcting. The learning itself is good, and correcting prior issues is good. But over-correcting and over-learning can be problematic and can lead to gold plating. I don't think there's any easy indication of the line between the right-amount of correction and over-correction, but I don't think it's unreasonable to state that one can over-correct based on prior experiences.
clavalle 8y ago
Estimates are always wrong only if they are concrete estimates as if they were certain. If, instead, they are 90% ranges (I am 90% sure that this will be done between x and y) then it is much easier to estimate accurately. It is also easier to spot bullshit (if the spread doesn't go up as your time to completion moves further from now, it is probably a bullshit estimate).
- tonyarkles 8y ago
  I really love the method from The Clean Coder, where you make best/median/worst estimates for tasks and then add them up to a mean and standard deviation. This helps capture the truth of “we don’t know how long it’s going to take, but it’s likely between x and y”. Where this still falls apart, for me, is knowing how many hours per day I’ll be able to spend on each project. I have multiple clients, and things come up. This method has gotten me very good at the budget aspect of project estimation, but the scheduling aspect still slips some (it’s rare that more hours in a day become available)
matthewmacleod 8y ago
Do your best to break tasks up so that all tasks are the same size That is estimation, in the Scrum sense.

ramraj07 8y ago

Only issue being that the estimates one gets from poorly planned sprints are probably less reliable than just asking the devs how long the project will take and going with it.

hopler 8y ago
Good estimates come from watching people deliver over time and scientifically comparing empirical performance to subjective estimates, not asking them to predict. Joel Spolsky has a great blog post on Painless Software Schedules.
- kitsune_ 8y ago
  There is nothing scientific about this method in my opinion. You do not make consistent reproducible experiments, you do not control for anything, you haven't even formed a null hypothesis etc.

BurningFrog 8y ago

> The business wants to know how much feature X is going to cost and when they can expect it. Of course they do. We all want things that are impossible to have. I want to know the AAPL stock price in 6 months. The traditional way to manage this impossibility is that engineering lies about it (they have to lie, because they can't know either), and once people are lying to each other, trust is unlikely to arise. The agile concept of "velocity" is the best way I know of managing this. It's not very good, and it's often a victim of Goodhart's law.

jrs235 8y ago
And velocity should be an internal team measurement not shared with outsiders because (Goodhart's Law) when management says "Let's increase our velocity" and the team and developers are GRADED/PROMOTED on their velocity then you'll get point/estimate inflation which will hurt you more in the long run since the inflated estimates actually now allow for the work to fill the time (Parkinson's law).
borski 8y ago
Engineering does not have to lie. All this takes is design and specification upfront, a well-defined feature set, and room for error. Also, avoiding scope creep is paramount.
- pas 8y ago
  What's the usual processing speed of a software engineer when it comes to reading through and understanding design & specification? We found that usually either the documentation/specification/requirements are too fine grained (and then they then change all the time, but then there's no real effort/bandwidth to do change management on the specs), or they are not detailed enough, which makes the estimation process a useless guessing game on what might they mean by this or that.
  - borski 8y ago
    See, I would expect the engineers to pipe up and explain that. It takes collaboration to get it right, and it takes the engineers setting expectations properly for what they need to estimate accurately. It’s a collaborative effort, not a one-way street, as with most things.

watwut 8y ago

Theoretically. Practicaly they don't do that kind of planning and high estimate leads to pressure to lower it down (or making you feel ashamed for it being to big etc), which most developers will do, because developers tend to sux at negotiation.

beat 8y ago
That's where it breaks down. If you strip the Scrum-Industrial Complex nonsense away, one of the basic concepts of Scrum planning is that the business gets to define the stories, and the developers get to assign the points (or whatever mechanism is being used to estimate). Business sets the scope, technical sets the resource requirements. If developers can't hold the line on estimates, they're toast. Nothing will ever get done on time or under budget, because the organization is focused on basic dishonesty about what work can actually get done. Which means people are being rewarded for the wrong things. Measure by estimate accuracy rather than promises made, and you'll see a lot more honesty in estimation.

beat 8y ago

Another bit of wisdom I got from Kent Beck is that there are three basic controls to every project... schedule, scope, and resources. You can only control two of them. And resources are generally fixed at the beginning of the project(1), so most projects are either scope-bound (we must have all these features), or schedule-bound (we must hit this hard date). If you're feature-bound, estimation failure means you'll be late. If you're schedule-bound, estimation failure means you'll be incomplete. This can be a very hard pill for the business to swallow. They want it all, and they want a predictable schedule. But Beck's triangle is akin to thermodynamics. Do you want the volume, or the pressure, or the temperature? When fixing devops-related and agile-related process problems, I often hear "But we're a schedule-driven company!" when they have a scope-driven problem like process transformation. 1. As The Mythical Man-Month pointed out almost 50 years ago, adding resources to a late project makes it even later.

house9-2 8y ago
> If you're schedule-bound, estimation failure means you'll be incomplete. Schedule-Bound development (or Deadline Driven Development) can actually work well with minimal estimation as long as you are truly building MVP (minimum viable product), you have to ruthlessly slash features and only build the core features that are going to deliver the most bang for the buck. Not easily done.
Drdrdrq 8y ago
There is a fourth control of course which comes into play when nothing else will give room: quality. You can take many shortcuts to deliver in time, full scope, with the resources available. But the result will be buggy and/or unmaintainable. Surprising amount of companies choose this path, I guess most without realizing it.
- pas 8y ago
  Quality is basically inherent in scope. Is testing the product in scope? Yes, then it will take up precious resources (time). Do you want to test it on every platform? Yes, even more time. (And of course the same goes for code review, writing unit tests, planning, writing and discussing a design document, etc.)

MrBuddyCasino 8y ago

> They need to know that, because they need to decide if it's worth it in the first place Thats only if that feature is optional. Often it isn't, and then it is pointless to estimate. Absolutely pointless.

dragonwriter 8y ago
> Thats only if that feature is optional. If it's optional, they need to know to make a decision to include or exclude it. If it's not optional for the project, but the project itself is optional, they need to know to make a decision to kill or keep the project. If it's not optional to the project , and the project is not optional to the business, they need to know to decide whether they keep or fold the business. In any case, if they might choose to keep the business, project, and feature, they need to know because they have to budget for the cost if they do so. So, essentially, business always needs to know the cost.

tybit 8y ago

I think this is totally reasonable at certain times. E.g how long will it take to add feature x with scope y to our existing product is a decent thing to estimate (and estimate only) for stakeholders to prioritise appropriately. I think most problems people have with estimates is when they are applied to things too large, or too small, to reasonably estimate. E.g How long will it take to build this product from scratch with a laundry list of features. Or more commonly, to micromanage. Why does anyone care whether this task will take 2 days as opposed to 3? That’s not meanginful information unless you’re mistakently expecting the individual user story estimates to add up to a reliable assembly line of work. I’m happy to estimate when it has some business purpose. If not, it’s meaningless busy work or worse.

gregmac 8y ago

> They need to know that, because they need to decide if it's worth it in the first place If this is the case, they should also be able to state the threshold above which the item would be "not worth it", and I would assume this is significantly easier to figure out than it takes developers to build a decent estimate. From a developer point-of-view, the first high-level estimate is then much, much simpler: "Is it going to take more or less than $not_worth_it to build?" If the answer is "more", then it gets dropped -- at least in its current state. It could be re-scoped later as a new item with a smaller MVP, for example. If the answer is "less", then the developer can put in the time to get a proper estimate. I think there might also be an argument that if the backlog is properly ranked the detailed estimate also becomes pointless -- just work on it until it's done. No one should be doing detailed estimates on items that are more than a few weeks/sprints away in the first place. Disclaimer: I've only recently been thinking about this abstractly, and have not yet tested this in practice, though I'd love to have this discussion with anyone that has.

stevesimmons 8y ago
Then the project sponsors would have to estimate value at a granular level. Which is essentially just as inconvenient for the business to estimate as schedule is for developers. They are more important in the organisation, so they don't, and instead insist on perfect estimates from the dev team.