Are there simple tools around to help reaching better estimates?
Why software projects take longer than you think: a statistical model (2019)
11–20 of 178 posts
Re: Why software projects take longer than you think: a statistical model (2019)
#12I've been advocating for 3-point estimation for quite a while. [1] Unfortunately it doesn't happen very often (mainly because tooling support for this has been missing in popular trackers such as Jira). In situations where I was the decisionmaker on the methodology I've had excellent success with it. (using about 90%-95% confidence interval was typically right on the mark) [1]: https://en.wikipedia.org/wiki/Three-poi…
This is good, but I think the "most likely estimate" is going to be misleading a lot of the time.
I don't have numbers to back it up, but I have a strong sense that the actual time to completion tends to be either at the quick end or the slow end of the estimation range, and only rarely somewhere in the middle. A bactrian, not a dromedary. If we hit the problems we were anticipating we might then the whole thing can take ages, but if we don't hit them it's pretty quick.
Best and worst case are going to fairly predictable in advance (the latter improving a lot with experience) so I'd stick with just those personally.
Re: Why software projects take longer than you think: a statistical model (2019)
#13I know a plan is good when my bottom-up estimates (padded with a buffer for unforeseen contingencies) align with my top-down gut instinct of how long a project of a certain complexity "should take".
As an experienced professional, one often compares with past projects and looks at the duration of a similar one - not necessarily regarding content but complexity.
(I also conduct research on methodology, e.g. https://arxiv.org/abs/2201.07725 / https://dl.acm.org/doi/abs/10.1007/978-3-031-08473-7_48 .)
Re: Why software projects take longer than you think: a statistical model (2019)
#14I've been advocating for 3-point estimation for quite a while. [1] Unfortunately it doesn't happen very often (mainly because tooling support for this has been missing in popular trackers such as Jira). In situations where I was the decisionmaker on the methodology I've had excellent success with it. (using about 90%-95% confidence interval was typically right on the mark) [1]: https://en.wikipedia.org/wiki/Three-poi…
I think that's a pretty smart model - best/worst/most likely. One thing I found lacking in kabuki agile theatre was that we were ABSOLUTELY NOT supposed to "get into the weeds" in meetings where we talked estimates. But how does one uncover the best/worst/most likely without doing so? You can spend 20min writing the most beautiful Acceptance Criteria but if you don't get a bit into detail on what the user actually wa…
Thing is, you can always put in "never" as worst case.
Re: Why software projects take longer than you think: a statistical model (2019)
#15Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…
> no-jira, no-meeting, get-it-done environment Best env, but sadly a bit rare? I used to select for shops like that, no wonder lay-offs are scary if you've been trapped in meetings instead of shipping.
I seem to manage getting into these types of roles 30% of the time, which is pretty nice.
Granted I am working a zillion hours right now, but I'm less stressed than when I was working 9-6 but in 5 hours/day of zoom.
Just feels like I am exercising my mastery vs fighting against inertia.
Re: Why software projects take longer than you think: a statistical model (2019)
#16Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…
I think we went from one extreme to the other. While being an "island in the zone" is super productive, some communication and team work needs to be there to avoid the high bus factor. It's nice when a team member leaves and no one is freaking out because there is a level of redundancy in the knowledge.
That said, the modern communication culture is out of control. We spend way more time talking about what needs to be done instead of actually doing something.
"Let's break the whole thing into 40 microservices" does not help. Unlike the neat theory of "everyone maintains their own set of microservices", every change and new feature needs to be over-analyzed for side effects. You are stuck in analysis paralysis. Not only do you not know what you should talk to other teams about, you may not even know who you should be talking to.
Re: Why software projects take longer than you think: a statistical model (2019)
#17What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates. Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
Because no customer wants to write a blank check.
If you don't know if its 500 or 5000 hours - you're simply not buying the product.
Re: Why software projects take longer than you think: a statistical model (2019)
#18I write code for 15 years and I still have no idea how to do any estimations. All my estimations are off by 2-200 times. Basically they’re useless. I write code until I’m happy with it. Sometimes I need to rewrite code 5 times before I’m satisfied. Sometimes I have extremely bad mood and can’t do anything creative at all, so even expecting me to work a hour tomorrow is not reliable. Or may be I’ll be in perfect mood and conditions and will spend weekends writing perfect code for 30 hours.
I envy people who can work on schedule. I’m so terrible on that.
Re: Why software projects take longer than you think: a statistical model (2019)
#19We (or at least I) may base our estimates on the happy-path.
That is, I can see how to solve a problem in the common case. But as I code, I encounter the myriad of error cases, exceptions to the common problems, and especially the interactions of all these. Then add in performance considerations and the complexity can multiply quickly. The long-tail of those errors and exceptions can be very time-consuming to solve, so the mean is likely to be way off.
It's obviously much easier to estimate when you're experienced with a problem space. This should mean that you know how to solve a particular problem as well as the likely exceptions (non happy-path) you'll encounter.
If you're experienced with the domain, you can fit the relevant partial solutions in your head and more accurately judge what could go wrong with your code. But more generally I think this is similar to solving problems in other domains as well, such as architecture, building a car, or anything with many moving parts. These domains do not usually have loosely coupled sub systems.
Re: Why software projects take longer than you think: a statistical model (2019)
#20What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates. Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
> What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates.
Obviously, planning is critical. Planning means resource allocation. How is this not a critical aspect of any project?
The mistake you're making is presuming that if estimates are not crisp then they have no value.
> Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required, which translates to not even knowing how many people should be working on a simple task.
The problem you're failing to address is limited information, and specifically limited context from developers and emerging requirements. Projects have been adjusting to this for decades. Agile developed concepts such as sprints and spikes for this very reason. It's not only about changes in requirements. It's mainly about gathering info and updating projects based on that.