Developer Productivity Myth: Estimation = Endpoint

Estimation itself carries a sense of commitment, “This is a three-day workload = I commit to trying to complete it within three days.”

• If it exceeds three days, you will find yourself in trouble because the commitment was not met.
• Encourages early completion to fulfill the commitment.

In such cases, developers are encouraged to estimate based on the worst-case scenario.

• Commitments are fixed, unknown problems are dynamic.
• Estimates can also be overly optimistic, and the level of optimism varies among different developers.
• Sometimes, experience or actual pitfalls are needed to make more accurate estimates.

If you cannot effectively measure or evaluate certain things, can you not create a feasible plan?

Depending on the type of development, the essence of a developer’s work is not solely about writing code to solve known problems. From the moment of estimation, a developer’s work has already begun. We learn to grasp the boundaries of unknown problems and propose satisfactory solutions with limited resources.

There is no absolute answer to this question, but my thought is that maintaining agility in planning and smooth communication can help the entire team move forward together.

• Understand that estimation is a checkpoint, not an endpoint.
• Understand that there are individual differences in estimation.
• Understand that some things require time and experience to validate.