If you’re working in a team using the Scrum framework, you use story points to estimate effort on your stories, tasks, etc. Then, some management considers this and plans, measures your productivity…

Pararise

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

Software estimations are always wrong due to various factors. Plans often fail because of imprecise requirements, not considering technical debt, and other reasons. Remediations to improve accuracy include tracking progress with estimates, using contingency buffers, allowing space for the unexpected, and more. Vasco Duarte suggests an alternative approach to estimation, focusing on delivering minor work that provides significant value and utilizing empirical data.

All Estimations Are Wrong, But None Are Useful

These is awesome :
<h2>Key laws and principles mentioned include:</h2>
<ul>
<li>Hofstadter’s Law: Estimations tend to be optimistic and ignore the recursive nature of tasks.</li>
<li>Brook’s Law: Adding manpower to a delayed project only causes further delays.</li>
<li>Planning Fallacy: A tendency to underestimate the time and resources needed.</li>
<li>Bikeshedding: Focusing on trivial tasks at the expense of more critical tasks.</li>
<li>Parkinson’s Law: Work expands to fill the available time, leading to inefficiency.</li>
<li>Ninety-Ninety Rule: The last part of a project often takes much longer than expected.</li>
</ul>