In this first of a pair of articles about software project estimations, I’ll be arguing in favour of foregoing estimations.
The #NoEstimates movement/hashtag has been gaining much press over the past couple of years, particularly when tied to a Kanban-style workflow. It takes the viewpoint that instead of expending effort estimating, or some may argue, guessing, as to how long the implementation of a feature may take, you’re better to spend that effort delivering the feature instead.
Popular delivery methodologies such as Scrum are heavily underpinned by estimations. Planning sessions typically precede the start of every iteration, during which the team will estimate the complexity involved in a set of features, drawing a line in the backlog when the estimates say that the team is at capacity.
Other contemporary methodologies such as XP focus more militantly on delivering the most valuable feature at any given time, rather than estimating and committing to larger bodies of work.
Here are our 7 top reasons to consider adopting #NoEstimates on your next software project, or indeed transitioning estimates out of your workflow on your current project:
1: Humans are bad at estimation
Humans are inherently bad at estimating the time it will take the complete a task, particularly in complex domains such as software development, where it can be unrealistic to foresee fine-grained implementation details or every case in which unexpected complexity could arise.
2: Estimates used as deadlines
In many organisations, it’s common practice that estimates are quickly turned in to deadlines. If a team estimates that a feature can be completed in one week, there can be an expectation that it will be delivered in one week.
This can lead to scenarios where teams inflate their estimates to ensure they have adequate buffer to deliver the feature to the estimate, ultimately reducing your team’s throughput as every feature includes potentially unnecessary padding.
3: You estimate when you know least
By nature, estimations happen before the work has started. You might have chosen to spike out an implementation to remove some uncertainty or to understand the feasibility of a proposed solution, but you still know least about the feature before you’ve written any code.
4: Time can be better spent delivering value
In most scenarios, we believe that you’d be hard-pressed to argue that spending time estimating (guessing?!) is a true value adding exercise. Estimates can seldom speed up delivery, and so the time spent estimating is time not spent delivering working software.
We often espouse that generating heavy documentation, or designing interfaces using tools such as Photoshop is ultimately an exercise in producing artefacts. In many cases, producing time estimates can be viewed in a similar light.
5: Adapting to change becomes harder
By the time you’ve invested in pulling together your estimations, you feel attached to them, and have a hard time throwing them away. Value is attached to the estimate because of the effort involved in creating it, and so even where it’s desirable to follow a different course, there may be resistance, conscious or otherwise, to doing so.
6: Adopting #NoEstimates doesn’t mean #NoDeliveryDates
One of the common themes of resistance to abandoning estimates is that it also removes delivery dates. This doesn’t have to be the case. By continuing to work towards a delivery date, and making regular go/no-go calls based on the very latest understanding, the team can remain focused on delivering the highest value increment by the agreed delivery date.
7: Focus on delivering smaller increments
Instead of big planning up front, the team can shift their focus to break features down on a just-in-time basis. In addition, with discipline, each of these features can be delivered as an incremental delivery out in to the hands of customers on a far more regular basis. This shortens feedback loops and empowers the Product Owner to make more frequent prioritisation calls.
Where the team’s discipline allows, adopting increasingly agile workflows that don’t rely on estimation, can, in our experience, often result in reduced waste when compared to methodologies that encourage longer-term commitments. There are a number of drawbacks, or at least areas that require closer full-team collaboration and discipline when removing some of the structure that estimates can help to provide. We’ll be covering these in a follow-up post that looks at the pros behind retaining estimates in your software deliveries.
About the Author
Chief Operating Officer at Made Tech
Chris has 20 years’ experience in digital and technology consulting roles spanning public and private sector clients including Royal Bank of Scotland, Philips, Government Digital Service, and Ministry of Justice. Prior to Made Tech Chris was Technology Director at Dentsu Aegis agency Isobar, leading technology delivery in the UK. Chris has been with the Company since 2012.
