7 ms·
> Can we stop pretending we can forecast the unknown Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of pro
by shados 7y ago
> Can we stop pretending we can forecast the unknown
Within reason. Ive worked in orgs where there is no estimate at all, and that bring a different set of problems (unbound projects and no work getting done because of the complete lack of pressure).
Now you're totally right: software engineers rarely do the same thing (or even similar things) twice, so estimating is somewhere between "very hard" and "impossible".
"Scoping" however is still needed.
If you ask me "How long will it take to add a button to this page", that's a very ambiguous question.
I can solve the problem in a few ways:
- Tack on a plain html button element
- Add a button from an existing styleguide/library/design system.
- Build our own button component instead of reusing one.
- Build a full blown button editor that allows a non-software engineer to use a WYSIWYG editor that will create their own custom button and insert it on the page without code.
Now obviously there's a range between these, going from a few seconds (plus deploy), to months or years of work.
The project/product/whatever managers and the tech leads/engineers need to work together to agree on scope. An arbitrary deadline can be picked and then engineers have to do whatever they can up to that deadline. Or we can agree on minimum functionalities with onbound deadline that MUST be created regardless of how long it will take. Realistically, successful projects will be a mix of both, along with various forms of padding and revisiting estimates along the way to account for unknown and mistakes.
- deleted 7y ago[deleted]
- jrs235 7y ago> because of the complete lack of pressure I would say it may be due to more of a lack of focus.
- avgDev 7y agoI feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss don't understand there is not much you can do but probably look for a better gig.
- RogerL 7y agoGreat! Please let us know when cancer will be cured. In other words, "I don't know" is sometimes a complete answer. I don't know. Period. This is supposedly one of the main points of this religion (agile). Some things are unknowable. So you move ahead a bit, and reassess. If you are scrumming, that is usually 2-3 weeks, and don't get me started on that arbitrary limit. But, you try to move forward for a bit, learn something, and then that might 1) let you know enough to know how to estimate 2) give you some information on what not to try next (I tried a, b, and c, and they all failed) 3) give you guidance on what to work on next (d seems promising, I can flesh it out more and see if it still seems like a promising avenue). You proceed on, and eventually get your hands around the problem, or the person writing checks decides this is not an economical search (because that is what this is, search on a multidimensional surface) and change/delete the requirement. That's what agile is supposed to be, with a nod to the fact that yes, we can estimate writing a single database query or something fairly well, so in some cases estimates can be useful at this scale. The bane of my existence is the endless pressure for estimates. I'm doing research; no one has done this stuff before. It is truly unknowable. If it was known it would be in a paper somewhere, and I would merely be implementing that paper. So I get told "break it down into smaller chunks", as if my 30 years of success didn't teach me how to break down problems. Thanks PM that has never coded or produced anything intellectually novel before! I'm surely being dumb and/or obstinate! I got that written in my previous performance review, that I don't know how to plan and break down problems, because I flatly refuse to play this game. You get punished for trying for hard things. It's nonsense. "I don't know" cannot be changed by insisting on an estimate.
- isoskeles 7y ago> Please let us know when cancer will be cured. An absurd comparison given most software engineering tasks have been done before, they're simply difficult to estimate for some given team without expertise in doing some particular task.
- mplanchard 7y agoTBF, GP said they were doing research, so it’s entirely possible that they’re working in a space with little to no prior art.
- RocketSyntax 7y agoIt's more about what is BEHIND the button.
- deleted 7y ago[deleted]
- hnick 7y agoThe Why rather than the What. Maybe they don't even need a button.
- humanrebar 7y ago> unbound projects and no work getting done because of the complete lack of pressure Actual demos seem to help a lot here in my experience.
- mizchief2 7y agoestimating is either easy or impossible. You either have done it repeatedly and have data to show how long it took, or you have no fucking clue. Focusing on the most important features of each module first, and then the most important of the next then the next with a focus on progress towards something useful is the only way to go. When you have a consistent team and some tracking data to compare task size to hours required to complete, then you can start doing estimates for future work, but you never have to ask the dev team to estimate other than setting some relative size between tasks and trying to stick to the sizing system. I prefer Fibonacci story points, but it can be anything that has a number.