Why I advocate a practice of no estimates as a software engineer

Before I get to the topic, I would like to clarify one thing: I don’t want to ban estimations generally from software development, as there are good and solid reasons for it. In a nutshell, business needs to be predictable.

I want to show a software developer's view on how to reduce or even get rid of endless estimations meetings with doubtful outcomes. Critics would argue that software developers should improve their estimation skills in order to:

• develop shared understanding within the team, especially in case of uncertainty
• make informed decisions when very little data (about the product) is available
• make the product more predictable

But let’s go step by step on how no estimates lead to the same goals.

Note: When I mention “team,” I mean a software development team and by “developer,” a software developer.

Improving predictability - Is there only one way?

There are many factors to improve the speed and predictability of software development. In case a team is missing some of those factors, they should be set and measured as team objectives in the meantime. Here are some of them:

• Stable and autonomous team: The product is built by the teams, so the focus should be to make them stable. Autonomy gives teams self-confidence and fosters maturity, which allows for decisions on how to build things.
• Reducing meetings: Keeping the teams busy with meetings will result in less time for developing. Software development consumes a lot of concentration and energy, so distractions should be kept to the minimum.
• Cadence of collaboration: Planning together with designers and product teams to clarify the tasks, building and reviewing together to keep a high quality of code and strengthen knowledge sharing within the team.
• High visibility and transparency: Making work and progress of the development transparent to stakeholders and manages will increase trust within the organization.

Really, no estimates?!

Let’s start to gather some arguments for estimations. Business runs on goals and commitments, and deciding which product should be built is a decision of computing cost against expected profit. With no estimates, how can costs be calculated? How and which commitments should be made? How can different projects be compared?

At some level, estimations have to be done in order to have numbers like cost and time for business decisions. But should this happen on the task level? No! Besides spending time to estimate every single task, it puts time pressure on the developers. Estimation also includes guessing. How certain can you be before starting a task? What is more important? Delivering on time or finding the best solution for the task? Let the developer decide this, as he/she is building the product. The idea behind it is to let the teams focus on what they do best: building the right products, which are reliable, stable and predictable.

How can this look?

Here, I want to quote one of the most active advocates of #NoEstimates (who’s been recommending this for as long as 15 years), Vasco Duarte:

1. The backlog should not contain well estimated stories, increasing the backlog after every sprint. Product should define the most important task and after completing it, they should define what to proceed with i.e. being agile!
2. Chunks should be small. It’s easier to split the work within the team and keep everybody up to date about the code base i.e. knowledge sharing!
3. Keeping chunks small decreases the developing and reviewing time. I feel amazed after finishing a task which didn’t take several days or get merged with another task i.e. boosting motivation to the next level!
4. Receive feedback from customers/stakeholders i.e. again, being agile!

My takeaway from the practice and experience of #NoEstimates is to empower teams to unleash their best. Provide them with the space and environment where nobody tells them what needs to be done but rather they do what needs to be done autonomously. My emphasis on #NoEstimates is to make sure that teams think about the value they deliver rather than going into a vicious circle of discussions. In the end, what matters is the outcome and not the input. Teams, especially developers, need to shift their mind towards value-driven development. This enables them to trigger discussions based on the value they could possibly deliver to the end customer, which is often the missing piece of puzzle. Teams should not follow the complaint mechanism but rather outcome-oriented, customer-centric decisions. Leaders play a vital role in enabling this kind of culture by providing teams with a “safe to fail” environment, where praise is given for experimentation. This, in the end, helps the team to grow and flourish.

For more information, why not check out some of my favorite sources on #NoEstimation: (1) #NoEstimates video by Vasco Duarte. (1) #NoEstimates: 6 Software Experts Give Their View on the Movement by Thomas Carney.

Join our team of developers. Check out our jobs page.