We have debate in our company - who should provide the estimation for the duration of a task (usually part of a project). I have seen a few popular options:<p>- the developer who will implement the task (a somewhat prevailing opinion on the internet)
- senior developers
- project managers<p>Thinking about it a new option may have emerged: estimates should not really be needed; and I would like to explore this option below.<p>Let's agree first that estimates are mandated for various business reasons but we won't require greater precision than a day of work.<p>Now, doing a thought experiment we analyse if there would be any estimate difference for a task requiring one line of code or "Hello World!" and agree that no matter who would provide the estimate the answer will be the same - probably the smallest unit of estimation since the task is trivial and the solution is canonical.<p>Going forward, however we agree that there is a point where estimates will diverge even between the most seasoned developers and estimators. I would argue that in that point the divergence stems either from a difference in understanding of the problem or different approaches in solving the respective (complex) task. Since both scenarios could cause problems down the line in the project, the team should step back, clarify the requirements & approach to the solution and break it down into further tasks that are trivial enough to be executed in the smallest unit of estimation.<p>In summary, estimation is the wrong problem to solve, the team should spend the time to thoroughly understand the requirements and truly define the solution approach, leaving the time estimate to be just a matter of counting the generated tasks and multiplying that with the agreed smallest unit of work.<p>While the above is a hypothetical scenario, what are your thoughts around it? Where do you see its flaws and where do you see its merits? Is anyone doing such a thing or was it tried and failed?
There are different kinds of estimates used for different purposes. When making an estimate, know what it's for and if it has any value at all or can be omitted.<p>Very high-level estimates can be used to decide whether to do one project or another. Here we're both guessing time/cost as well as expected value. If unclear do some work to make better guesses of time/cost or expected value.<p>Estimates can also be used go co-ordinate with other teams if there are scheduling dependencies. Communicate early and often. Do some work to validate estimates. Complete tasks in a way that makes other estimates more accurate. e.g. deploy the smallest feature to prod with all steps completed rather than 100% of scope 10% done. If it's an external team, make your best guess, leave some room and aim to be early because you won't be.<p>Estimates to fill plan/fill work weeks are mostly a waste of time. Instead identify what's important, break them down into small parts with the immediately sequenced parts in higher resolution and do as many as you can in a natural order.<p>You can still schedule tasks expected to be completed in a cycle but it's a direct assessment as in "I can do items 1 & 4 in the next two weeks" not an abstract each item got a team-agreed T-shirt size and you've been selected to do these ones that add up to 10 days.
There is a secondary discussion if developers should be accountable for sticking to estimates, and my opinion is that they shouldn't - developers should be accountable for the quality and maintainability of the produced code, documentation and tests, not timelines - that's the job of the PM. A good PM will be able to observe that on average the unit of estimation takes 20% longer or shorter and adjust the project timelines accordingly. Also, if someone is worried about developer productivity, it can always evaluate it in relative terms, i.e. how many tasks generated with the above method does one developer execute vs another developer in the same unit of time.
There is a fair chance I maybe an idiot but I've rarely worked on a problem where I could:<p><i>"thoroughly understand the requirements and truly define the solution approach, leaving the time estimate to be just a matter of counting the generated tasks"</i><p>The problems I've been paid to solve are problems that haven't been solved yet or at least <i>I</i> have never solved them before so I would have difficulty making a estimate.<p>(This isn't meant as a criticism. It's just my experience.)
Is your company requiring hour or even minute accuracy of the estimate?<p>In my whole professional life, I have not been put in such situation, even when working as consultant where we charge by the hour -- we simply estimate by week or day then multiply.<p>The art part of estimation is setting expectations, or more precisely, adding and justifying buffer time, and form an acceptable narrative when the schedule deviate from plan.