Software effort estimation is mostly fake research
shape-of-code.coding-guidelines.com
Software effort estimation is mostly fake research
1–10 of 318 posts
Re: Software effort estimation is mostly fake research
#2If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :)
My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software development, that there seems to be no sane way to compare what happened with original estimates. (new features, changed features, lots of new information, market shifts/product vision shifts, quality assumptions change, etc. etc.)
But at that point nobody cares! People go on with further projects, and no data is ever collected.
Nobody learns.
When f*ckups happen, i.e. a gross over- or under-estimate, this is often not shared with the broader organization (ashamed/afraid sales people/PMs/devs say nothing/hide it/sugarcoat it). Client walks away.
Sometimes project is severly underestimated but usually not just because of the software part. Again, no decoupling and estimation of contributing factors is done.
It's insane.
Re: Software effort estimation is mostly fake research
#3Scrum dogma is that estimates are for complexity, not effort or timing. The points you track in JIRA are meant to reflect how much of the current backlog is complete and how much is remaining. That can be extrapolated into timing but can't be done up front.
Re: Software effort estimation is mostly fake research
#4I am 20 years in development business now.
This simple rule of thumb works for me and the team:
(Your honest and concise estimation) * 3
There are just to many unknowns you cannot foresee. Software development is complex.
Re: Software effort estimation is mostly fake research
#5Scrum dogma is that estimates are for complexity, not effort or timing. The points you track in JIRA are meant to reflect how much of the current backlog is complete and how much is remaining. That can be extrapolated into timing but can't be done up front.
My understanding is that for a team and project that's been going for a while, scrum points can be roughly turned into time estimates by looking at the history of stories that were rated for that many points and averaging.
But that obviously won't work from the start, and it won't be accurate... Just better than nothing and (hopefully) better than what a programmer will estimate in their head.
And IME, it's a lot less stressful on the programmer to estimate points rather than time.
Re: Software effort estimation is mostly fake research
#6At least in a business setting I think the whole concept of a project needs serious reconsideration. We end up more often than not trying to fit developing a digital product into an enormously stupid gantt chart to execute some poorly thought “business requirements”. I prefer to talk products and not projects, I deliver the full thing including “growth” as adoption doesn’t come “if you build it” even within a Company setting. If you are building a product you can also get closer to those with the real problem willing to fund you with real budgets. On top of everything else if you are making users happy they will not chase you on fake estimates but rather work with you to get stuff done.
Re: Software effort estimation is mostly fake research
#7Scrum dogma is that estimates are for complexity, not effort or timing. The points you track in JIRA are meant to reflect how much of the current backlog is complete and how much is remaining. That can be extrapolated into timing but can't be done up front.
> Scrum dogma is that estimates are for complexity, not effort or timing
The theory of story points (which originate outside of Scrum and are not part of Scrum proper) is that task-specific time estimates in creative intellectual work are extraordinarily unreliable and expending more effort on them doesn't improve them, but broad-banded complexity class evaluation mixed with empirical observation of the teams velocity produces time estimates that are (while still extremely fuzzy) both better and much lower effort, once you have the basic tracking in place, than task-specific direct estimates.
The “dogma” you report seems like something that might be a derivative of that that has lost track of rationale and purpose, reducing it to a cargo cult practice.
Re: Software effort estimation is mostly fake research
#8How do other disciplines estimate NRE? Do they have the same problems with missed predictions?
Re: Software effort estimation is mostly fake research
#9If someone can conclusively teach inexperienced programmers good approach to estimates (methodology) + help embed this into sales process of a software house-type company, I know some folks who'd love to have this :) My own experience has been this: people make estimates, client has expectations based on some variant of those, and something later happens but so much change is introduced during the actual software dev…
Make a complete list of things to develop in a spreadsheet, "complete" means every single item the customer wants to see in the product, not only every single button but also every single label, that should be definable by reading the project specs or mockups. I think "forgetting things" is the first big mistake leading to under estimations.
Add an estimate that you multiply by three in front of each, ie. if the dev thinks 1 hour then they should put 3. From my experiments: no multiplying factor turned to nightly and weekend work, multiplying by 2 turned to long (10 hours) work days, multiplying by 3 turned into comfortable work hours and quality work.
I've had success delivering quality code and respecting deadlines since 2012 or so with this system, but YMMV
Only problem: the customer might not like what he gets, even if it works exactly as planned.
Re: Software effort estimation is mostly fake research
#10"Estimates" are for things you've done before - like you can estimate building a house, because people have built houses before. The more like an existing house, the better you can estimate it.
Software is invention and construction. The construction part is pretty easy to estimate. The invention part is ... very very hard. I'd like to say it's impossible. I'd like to see the software industry use a different word than estimate.