Estimation of software projects is one of the most painful subjects for any tech company. (Look no further than the comments in this Hacker News post to see some of the strong emotions that this challenge provokes.)
Software is extremely complex, so accurately predicting how much time a project will take can feel nearly impossible. This leads many developers and teams to not take it seriously or even give up and drop time estimation completely – an obvious issue when the business relies on deadlines to coordinate launches, close sales, or drive renewals.
For those teams that haven’t given up on estimation completely, one common approach is to use various time units (such as Story Points, Hours/Days, or T-shirt sizing). But this approach often suffers from various challenges:
Acumen’s vision is to ultimately solve for all of these challenges with traditional estimation approaches. (Full disclosure: we’re still working to crack the nut on unknown unknowns.) But based on feedback from our customers, we believe we’ve developed a novel solution to the second and third obstacles: creating a standard “currency” of estimation across devs and resolving tensions around efficiency vs. predictability in time estimation.
How do we do this? Acumen has access to the engineering team’s data, and uses machine learning to infer the Maker Time (the actual developer coding time) spent on each task throughout the history of a team. Knowing Maker Time equips Acumen to help teams improve estimation accuracy throughout three stages of the software development lifecycle: planning, execution, and retrospectives.
Planning in Acumen involves standardizing individual time estimates to a common denominator, benchmarking the total capacity of the team and individual developers, and then forecasting workload on the individual level.
Acumen automatically identifies “lookalike” projects to benchmark progress and flag estimation risks throughout the execution of a software iteration.
Acumen’s comparisons are done at the individual level, with the context of each developer’s patterns and point capacity. So if Developer A worked on Task Z for 4 hours, for example, Acumen might show the task as On Track. But if developer B worked on the same task for the same amount of time – 4 hours – Acumen might show it exceeding the estimation.
The same principle of “lookalike” projects applies to completed work. Once a team has finished a project, Acumen can look back at the tasks the team finished and show if a task was fast or slow compared to similar tasks.
Planning is a notoriously challenging task for many dev teams that often feels more like guesswork than a data-driven exercise.
Acumen’s approach to inferring Maker Time from the engineering team’s data – and surfacing relevant insights throughout the development lifecycle – can help teams improve the accuracy and value of estimation.
Learn more about Acumen's approach to unifying and analyzing engineering data.
Elad Ash, Chief R&D and GM at Placer.ai, describes the mindset shifts that have enabled him to build and scale world-class R&D teams.
A recent conversation between Aviv Ben-Yosef (author of The Tech Executive Operating System) and Nevo Alva (CEO and Co-Founder, Acumen) illuminated four principles for building a high-impact engineering organization
Tell us a bit about yourself, and we'll set up a time to show you how dev teams boost productivity and predictability with Acumen.
We'll share the latest from our blog, along with new product releases and beta opportunities.