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:

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.

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.

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.

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.

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.

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.

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.