Cycle Time: have the data provide the estimate, not the engineers
(or why I wish we’d do away with estimates)
“And how long will it take?”: a seemingly innocuous request which actually asks for something quite profound - to quantify the unknowable.
We used to turn to Soothsayers and their chickens to predict the future, but thankfully we’ve advanced as a species, so now we turn to engineers. But should we continue this ancient practice of basically guessing, or should we instead turn to newer and more useful metrics for gauging the size of our software projects?
Our reliance on estimates is a testament to our collective hubris: estimates, as we all know, are inherently inaccurate and yet they’ve persisted - it feels to me at least - as a kind of salve against the unsavoury fact that we’re risking capital on the unpredictable (not a risk to be sniffed at, of course!).
However, in the pursuit of some semblance of control, how often have engineers nervously observed their estimates morphing into commitments and watched ball-park figures turning into deadlines which are totally at odds with reality?
The pressure to provide time and cost estimates is understandable, particularly when there are significant investments at stake.
The folk so often championing estimates, the project managers, are tasked with navigating the delicate balance between delivering results on time and within budget while mitigating risks and uncertainties.
Thankfully, we’re in an age where data is constantly being collected via the tools we use to get the job done and thus provide us with superior metrics to the defective estimate - at least in software development
Enter cycle time
A metric grounded in empiricism rather than speculation. Unlike estimates, cycle time is derived from real data collected during the execution of a project. It measures the time it takes for a task or user story to move through the development process from start to finish.
By analysing historical cycle time data, teams can gain insights into their actual performance and identify patterns and trends that can inform future predictions. This empirical approach provides a more accurate basis for forecasting project timelines and costs.
As long as a software project has been well refined, getting a good estimate takes nothing more than some data and simple arithmetic. For example, say we’ve completed 5 tasks with a cycle time of 2 days. How long will it take to complete the remaining 10 tasks? 10 x 2 = 20 days. It’s deceptively simple, but far more likely to provide a number within the realm of possibility than anything conjured up by ad hoc reckoning.
Plus, tracking cycle time comes with additional benefits beyond estimation. It encourages a culture of continuous improvement. By focusing on reducing cycle times through process optimisation and workflow efficiency, teams can increase their productivity and deliver projects more predictably.
We live in the ‘information age’
We should be collecting and utilising that information, that vast array of empirical data, to make more realistic predictions rather than relying on the speculative and archaic tradition of pulling numbers out of thin air.
In the age of big data and analytics, it's time to shift away from the outdated practice of asking for estimates and embrace the power of empiricism embodied by cycle time. By using real data and insights, we can make more informed decisions and achieve better outcomes in our projects.
How can advancements in technology be used to reduce our reliance on notoriously flaky estimates, and enhance the accuracy and efficiency of project planning?