Software effort estimation is mostly fake research (2021)

Post by e12e » Mon, Jun 19, 2023, 7:33 PM UTC

slinna wrote: post #209

e12e wrote: post #165

Earlier quoted context omitted.

This is great, thank you. Another approach is to do forecasting based on historical throughput (eg tasks/day). Generally using "story points" or other guesstimates turn out to be redundant if you have actual data (actual project by mostly the same team). It takes into account stuff like n% of issues "blowing up" into subtasks, and some issues taking longer. I read a great article on the subject which I've unfortunate…

Thanks for mentioning Screenful. Just wanted to comment on your remark: "In general I'd like to be able to just point a tool at N "completed" GitHub projects, and a fresh one - and get a forecast that adjusts as issues are completed and added (possibly filtering on issue tags in completed and new project)" That's exactly how our Forecasting chart works. You can import any number of repositories and projects (classic…

Thank you for that link, you sum up the idea that sometimes counting total tasks works fine quite well:

> Will this work if my tasks aren’t all the same size?

> The short answer is yes, your work items don’t have to be the same size for this approach to work. The chances are that If you take 100 tasks in the past and compare those to a sample of 100 tasks in your current backlog, they will be the same size on average. Also, they are likely to be the same size on average regardless of how you measure (e.g. in story points or by some other estimate) or simply by task count.

Post by smsm42 » Wed, Jun 21, 2023, 5:55 AM UTC

ngc248 wrote: post #121

eftychis wrote: post #60

Earlier quoted context omitted.

The real problem is not with estimation but with the management denial. I was asked to estimate a project I owned as a “green” lad. I offered 6 months with a real detailed plan and up to a year with some extras. Based on past rates we had etc. I even did some statistical modeling. They disagreed. They decided to alter the approach, that the principal engineer had suggested and “it would take 2-3 months.” Two years la…

>>>. The real problem is not with estimation but with the management denial. ^^ This is the truth. All estimation processes in any company are just ceremony. Management already has a deadline fixed. They will make you agree to their deadlines, even though whatever process stipulated by them says otherwise.

> They will make you agree to their deadlines, even though whatever process stipulated by them says otherwise.

I'm not sure how. I mean, if I know it takes X time to do something, what would make me to commit to Y<<X time when I know it will fail and will be made my fault? If they want to record it as a deadline, so be it, but if it's an impossible deadline I'd make every effort to be on record that I said it from the start that it's impossible.

Re: Software effort estimation is mostly fake research (2021)

Re: Software effort estimation is mostly fake research (2021)