Any estimates longer than 3 days tend to be wrong

[k4ml]

𝗔𝗹𝗹 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗘𝘀𝘁𝗶𝗺𝗮𝘁𝗶𝗼𝗻𝘀 𝗔𝗿𝗲 𝗪𝗿𝗼𝗻𝗴, 𝗕𝘂𝘁 𝗡𝗼𝗻𝗲 𝗔𝗿𝗲 𝗨𝘀𝗲𝗳𝘂𝗹

If you're working in a team using the Scrum framework, you use story points to estimate effort on your stories, tasks, etc. Yet, probably you're often mistaken with estimations. The main reason for this is that estimations are 𝗮 𝗳𝗼𝗿𝗲𝗰𝗮𝘀𝘁, and a forecast predicts an unknown future. Yet we all know it is impossible to see the end, but they tend to forget it and make commitments from estimations.

In general, it is 𝗴𝗼𝗼𝗱 𝘁𝗼 𝗵𝗮𝘃𝗲 𝗽𝗹𝗮𝗻𝘀 because it's how we can iteratively work on something, continuously providing value to our clients. Yet, projects are usually very complex, involving many teams and dependencies between them.

𝗪𝗵𝘆 𝗱𝗼 𝗽𝗹𝗮𝗻𝘀 𝗳𝗮𝗶𝗹? There are many reasons for that, such as not precise requirements, level of knowledge not being considered, etc.

Yet, there are some other things 𝘄𝗵𝘆 𝗲𝘀𝘁𝗶𝗺𝗮𝘁𝗶𝗼𝗻𝘀 𝗳𝗮𝗶𝗹:

𝟭. 𝗛𝗼𝗳𝘀𝘁𝗮𝗱𝘁𝗲𝗿’𝘀 𝗟𝗮𝘄: States that, "It always takes longer than you expect, even when you take into account Hofstadter's Law." It highlights the recursive nature of estimation, where considering the complexity of a task and human optimism often leads to underestimation.

𝟮. 𝗕𝗿𝗼𝗼𝗸'𝘀 𝗟𝗮𝘄: "Adding manpower to a late software project makes it later." This law emphasizes the negative impact of increasing team size to speed up a project. New team members need time to get up to speed, and overhead communication increases, further delaying the project.

𝟯. 𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴 𝗙𝗮𝗹𝗹𝗮𝗰𝘆: This cognitive bias causes people to underestimate the time and resources required to complete a task. In software estimation, developers may need to pay more attention to potential obstacles or be optimistic about their abilities, leading to inaccurate estimates.

𝟰. 𝗕𝗶𝗸𝗲𝘀𝗵𝗲𝗱𝗱𝗶𝗻𝗴: This law states that people tend to focus on trivial details rather than critical aspects of a project. In software estimation, this can result in an overemphasis on understandable tasks while underestimating more complex tasks.

𝟱. 𝗣𝗮𝗿𝗸𝗶𝗻𝘀𝗼𝗻'𝘀 𝗟𝗮𝘄: "Work expands to fill the time available for its completion." This law suggests that if a deadline is too generous, developers may spend more time on a task than necessary, leading to inefficiencies and delays.

𝟲. 𝗡𝗶𝗻𝗲𝘁𝘆-𝗡𝗶𝗻𝗲𝘁𝘆 𝗥𝘂𝗹𝗲: "The first 90% of the code accounts for the first 90% of the development time; the remaining 10% of the code accounts for the other 90% of the development time." This rule highlights the difficulty of accurately estimating the time needed for bug fixing, optimization, and polishing.

Break down tasks by 𝗱𝗲𝗰𝗼𝗺𝗽𝗼𝘀𝗶𝗻𝗴 𝗹𝗮𝗿𝗴𝗲 𝗰𝗼𝗺𝗽𝗹𝗲𝘅 𝘁𝗮𝘀𝗸𝘀 into smaller, more manageable ones. For example, we found that jobs estimated up to 3 days of work are accurate.

https://www.linkedin.com/posts/milanmilanovic_technology-softwareengineering-programming-activity-7063754883312549888-rEx_/