4 ms·

I don't think I've worked with an organisation, or a PM that could actually estimate well in software without using padding. I think the prevalence of story po

by UK-AL 11y ago

I don't think I've worked with an organisation, or a PM that could actually estimate well in software without using padding. I think the prevalence of story points, and probability based estimates(markov), proves that hard deadline estimates just don't work. I don't trust anyone who says they can actually do it on large projects, because they're either padding or lying.

HeyLaughingBoy 11y ago
Padding is not a bad thing if done right. The group I worked most recently with had an estimation target of +/- 20% and we were usually much better than that. It takes a lot of discipline and detailed time recording to get to the point of being able to accurately estimate a task. Padding becomes useful when you know that you always estimate 15% low. Then after you finish your "real" estimate, add 15% and you will be close to the actual value. I like to think of the estimation process as being analogous to Feedback Control theory. It requires good input data and negative feedback to stay on track.
- UK-AL 11y ago
  How you can predict the future estimates based on recording now? What makes software estimation so difficult is that it's like maze. How long will take you to complete a maze? You don't know what's coming up in a maze, and you cant give an exact estimate. And trying to work out details to work out what is coming up, takes almost as long actually programming it. This is why I promote the idea that variation should be inbuilt into methodology. Remove the assumption software can be accurately estimated, build methodology around the fact it's hard to predict. I use guestimates of 'effort', but I don't hold people to it.
  - kohanz 11y ago
    exact estimate I think you've imposed an unachievable standard here. This is why I promote the idea that variation should be inbuilt into methodology This may well work within an agile team deep in an organization, because the business of turning "effort" into costs is abstracted from you. At the end of the day, if you're a consultant with a client, they are going to ask you up front for a rough cost estimate. If you can't estimate the time you'll need with any level of confidence, how do you propose to land their business?
  - HeyLaughingBoy 11y ago
    Prediction only works for what you know. Seems obvious, but people have a way of "forgetting" that. So you estimate within the parameters of what you know about. If what you know changes, then your predictions have to change. There are various points on the predictability curve. I used to work in an environment that was extremely predictable: projects with well-defined scope that took years to complete and changes were tightly managed. If scope changed, the stakeholders understood the cost to the schedule. An environment like that is perfect for using past time estimates vs. actual time taken to estimate future similar or dissimilar-but-related tasks. In other environments I worked in, it's more chaotic. Things change frequently, so estimates change frequently. Often you your long term vision is compromised by firefighting, so that vision has to be adjusted constantly. If you have a deadline, then tasks need to shift to meet the deadline.
kohanz 11y ago
I agree that "padding" is necessary. It is called estimation because there is some level of uncertainty. Part of your job as a consultant is ensuring that the client is aware of and comfortable with this level of risk. I bill by the hour, so my risk is mitigated, while my clients know from experience that I tend to deliver on time and rarely have them go over budget (that is where your estimation ability comes in). If you are doing project-based pricing (as others advocate), then I assume a more significant amount of "padding" is called for, to limit your risk.

by UK-AL 11y ago

HeyLaughingBoy 11y ago

Padding is not a bad thing if done right. The group I worked most recently with had an estimation target of +/- 20% and we were usually much better than that. It takes a lot of discipline and detailed time recording to get to the point of being able to accurately estimate a task. Padding becomes useful when you know that you always estimate 15% low. Then after you finish your "real" estimate, add 15% and you will be close to the actual value. I like to think of the estimation process as being analogous to Feedback Control theory. It requires good input data and negative feedback to stay on track.

UK-AL 11y ago
How you can predict the future estimates based on recording now? What makes software estimation so difficult is that it's like maze. How long will take you to complete a maze? You don't know what's coming up in a maze, and you cant give an exact estimate. And trying to work out details to work out what is coming up, takes almost as long actually programming it. This is why I promote the idea that variation should be inbuilt into methodology. Remove the assumption software can be accurately estimated, build methodology around the fact it's hard to predict. I use guestimates of 'effort', but I don't hold people to it.
- kohanz 11y ago
  exact estimate I think you've imposed an unachievable standard here. This is why I promote the idea that variation should be inbuilt into methodology This may well work within an agile team deep in an organization, because the business of turning "effort" into costs is abstracted from you. At the end of the day, if you're a consultant with a client, they are going to ask you up front for a rough cost estimate. If you can't estimate the time you'll need with any level of confidence, how do you propose to land their business?
- HeyLaughingBoy 11y ago
  Prediction only works for what you know. Seems obvious, but people have a way of "forgetting" that. So you estimate within the parameters of what you know about. If what you know changes, then your predictions have to change. There are various points on the predictability curve. I used to work in an environment that was extremely predictable: projects with well-defined scope that took years to complete and changes were tightly managed. If scope changed, the stakeholders understood the cost to the schedule. An environment like that is perfect for using past time estimates vs. actual time taken to estimate future similar or dissimilar-but-related tasks. In other environments I worked in, it's more chaotic. Things change frequently, so estimates change frequently. Often you your long term vision is compromised by firefighting, so that vision has to be adjusted constantly. If you have a deadline, then tasks need to shift to meet the deadline.

kohanz 11y ago

I agree that "padding" is necessary. It is called estimation because there is some level of uncertainty. Part of your job as a consultant is ensuring that the client is aware of and comfortable with this level of risk. I bill by the hour, so my risk is mitigated, while my clients know from experience that I tend to deliver on time and rarely have them go over budget (that is where your estimation ability comes in). If you are doing project-based pricing (as others advocate), then I assume a more significant amount of "padding" is called for, to limit your risk.