If you're working in a team using the Scrum framework, you use story points to estimate effort on your stories, tasks, etc. Then also, some management takes this into account and does planning, measures your productivity, and even keeps you accountable when something is done. Yet, they need to learn that software estimations are always wrong.
Great article, Milan. Thanks for gathering all related "laws" in one place, it makes it easy to return to the list.
You mention Vasco Duarte suggests "[...] delivering the minor work that provides significant value". This reminds me of Kaizen (https://en.wikipedia.org/wiki/Kaizen), which invites to make small valuable steps toward a bigger goal.
I've be part of teams which did not plan nor estimate, teams which planned with story points (and spent a fair amount of time calculating the velocity), and others which planned without estimates (Kanban approach). The last two ways worked well, because teams liked doing so, and saw value estimating, or skipping estimates. I've found that it's often a question of culture, where teams which have never estimated are reluctant to try it, and they perform fine with the Kanban approach.
Hey Milan, your article brilliantly highlights the complexities of software estimation. I've navigated these challenges in regulated tech, where precision is paramount. Your insights on uncertainty, decomposing tasks, and tracking progress resonate with my experiences. Great read. Looking forward to more. - Adam
Great article, Milan. Thanks for gathering all related "laws" in one place, it makes it easy to return to the list.
You mention Vasco Duarte suggests "[...] delivering the minor work that provides significant value". This reminds me of Kaizen (https://en.wikipedia.org/wiki/Kaizen), which invites to make small valuable steps toward a bigger goal.
I've be part of teams which did not plan nor estimate, teams which planned with story points (and spent a fair amount of time calculating the velocity), and others which planned without estimates (Kanban approach). The last two ways worked well, because teams liked doing so, and saw value estimating, or skipping estimates. I've found that it's often a question of culture, where teams which have never estimated are reluctant to try it, and they perform fine with the Kanban approach.
Truly awesome your understanding makes my heart sing.
Hey Milan, your article brilliantly highlights the complexities of software estimation. I've navigated these challenges in regulated tech, where precision is paramount. Your insights on uncertainty, decomposing tasks, and tracking progress resonate with my experiences. Great read. Looking forward to more. - Adam