Let’s admit it! Estimations aren’t for everyone, right? If you’re watching this, chances are that you’re doing SCRUM, which at certain point you struggled to estimate work, even when you thought you nailed all the points on that sprint. 6 out or 10 times, you end up underestimating complexity and facing scope creep. So what if I told you that abandoning estimations on agile software development, can significantly streamline processes and improve productivity.
And now about this…
In the traditional Agile methodology, especially Scrum, the process of estimating work often becomes complicated, fuzzy and detracts from actual development time. The complexity of estimating points often leads to lengthy discussions that divert attention from the actual work. We’ve all been there! Haven’t we? Even if you transition from Scrum to Kanban in pursuit of the utopia or leaner processes, you still get loads of meetings about task sizes, stalling your progress. It’s like this “metawork”, the time spent on work about work, such as meetings and estimations, which detracts you and your teams from the actual productivity.
So, how to address this? Well, to achieve better predictability, use average points from past performances instead of complex estimations. And if you focus on completing tasks rather than estimating them, it usually increases productivity, right? So instead of relying on subjective estimates, use historical data to drive development. By analyzing past project data, teams can predict timelines and resource needs with greater accuracy. You should focus on key metrics like the Average Cycle Time: the average time taken to complete a task and Throughput: the number of tasks completed per sprint.
By tracking the number of completed tasks per sprint as the primary measure of team productivity, it shifts the focus from estimating the size of tasks to ensuring consistent delivery. Which at the end it simplifies tracking, reduces time spent in meetings, and provides a clear measure of progress. Also, by using cycle time to understand the efficiency of task completion, means that a shorter cycle time indicates a well-functioning team, capable of quickly resolving issues and delivering features. Then Kanban principles align well with the this no-estimation approach, by implementing Work-In-Progress Limits, meaning, restricting the number of tasks in progress to avoid overloading the team and ensure focus, plus using Kanban boards to track task status, providing immediate insight into workflow and any potential bottlenecks.
Now, I do believe that estimations are unnecessary for experienced teams capable of breaking down problems efficiently. Aligning velocity tracking with the number of completed tasks rather than story points, simplifies project management by averaging task sizes and focusing on throughput.
Bu,t does that really work, you ask 🙂
Well, start by using historical data of team velocity to project timelines for new projects. Then adding a margin of error based on past experiences, can provide realistic project timelines. For example, if a project consists of 35 tasks and your team completes six tasks per week, the project will likely take about six weeks to complete. Adding a 10% buffer can provide a more realistic timeline. This, or any method of eliminating estimations is iterative, it improves accuracy over time as more data is collected, which then can be refined with team experience and changes.
Bottom line; let’s explore an innovative engineering approach to software development that eliminates the need for estimations, focusing on maximizing efficiency and delivering value. I do want to emphasize that while this method may not suit all teams, it can significantly improve efficiency for most. So, I encourage teams to experiment with eliminating estimations and adapt based on their specific needs, by focusing instead on velocity tracking, on minimizing the time spent on “metawork” and by improving with data, not with hunches. See you on the next episode.
