2 ms·
Here's a relevant quote from a nice article [1]: """ When you are estimating tasks that are done over and over, you can look to your historical execution time
by vvillena 8y ago
Here's a relevant quote from a nice article [1]:
"""
When you are estimating tasks that are done over and over, you can look to your historical execution time for insights. We average chopping X logs per hour.
If I hand you a Rubik's Cube and ask you to tell me how long it will take you to solve it...what is your answer going to be? If you've done it before you might have an idea. Maybe you just kept plugging away until you finally solved it? Maybe you've watched one of those videos about how to solve a Rubik's Cube, have practiced it and are confident that you could do it in 3 minutes flat? Maybe you have no idea?
Complexity and experience will dictate your answers, but then those estimates still only reflect your perception of the task...not everyone else on your team.
At best those numbers are a guess.
Every step in a software project is solving problems. You don't know how long it will take to solve the problem. You don't know how many new problems you might run into along the way. Can the new problems be solved by you or do they need to be solved by other people?
"""
[1]: https://www.brightball.com/articles/reality-driven-development-fixing-project-management-in-software https://www.brightball.com/articles/reality-driven-developme...