> I’d say just discussing how a task will be implemented susses out whether it’s understood. Estimation isn’t a useful part of that discussion.
I see your point, but I would argue that estimates are more valuable than just discussing the task because they give you a shared language to quickly define how complex you think a task is, and can also help avoid getting too into the weeds about specific implementation details when talking about the task in general. There are definitely problems that can arise from estimation, but if you're able to avoid them, it can be a useful tool for a high functioning team.
I’d counter further than this sort of estimation naturally arises in any discussion of a problems solution. The challenge arises from the recording, accounting, and aggregation of estimations for any purpose other than the development of the solution - which is important for the purpose of allocation of talent and sequencing of immediate dependencies. The thing is the error bars in these estimates are large and positively skewed so you need to make your estimates about the smallest possible piece of work, and attach as little importance and dependency on their accuracy as possible.
The problem comes when you string estimates together and compound the mistake by assuming a precise estimate is an accurate one. I generally refuse to give precise estimates for that reason.
I see your point, but I would argue that estimates are more valuable than just discussing the task because they give you a shared language to quickly define how complex you think a task is, and can also help avoid getting too into the weeds about specific implementation details when talking about the task in general. There are definitely problems that can arise from estimation, but if you're able to avoid them, it can be a useful tool for a high functioning team.