#NoEstimates: Crazy Talk, or Agile Compatible?


#NoEstimates: Crazy Talk, or Agile Compatible?


wedding figurines cake

A couple years back, I started hearing about an interesting movement in the software and web development community called #NoEstimates. At the time, I was fresh out of CSPO and PMI-ACP certifications, and I naturally started wondering about this movement that was too new to be taught by the courses I took to earn those certifications.

I had colleagues who were adamant that we avoid estimates in most cases, while others insisted it was insane to suggest that accurate estimates were not always necessary or possible. Before forming my own opinion, I decided to examine as many sides of the discussion as I could and read up on the thoughts of various writers and experienced professionals in the community.

What I found were well-reasoned arguments on both sides. However, one thing that bothered me was that people who did not favor implementing a strictly defined agile framework didn’t tend to want strict estimations either, while those who wanted to implement a more elaborately defined agile framework also tended to support formal estimates.

It made me wonder – can #NoEstimates and agile coexist in the same team? Did being agile and Scrum certified mean that I automatically needed to reject and exorcise our team from this dangerous school of thought? I didn’t think so.

Don’t get me wrong – Scrum and other agile frameworks explain a thoughtfully evolved process for estimation that is rock-solid, clearly defined and often 100 percent part of the framework. However, not all agile frameworks are the same. Many teams use formal estimates with great success, and I want to be clear that I’m not advocating that there is one correct answer for every team.

The only thing I’ll advocate in this debate is to consider reasoning from all sides. To help facilitate this, I’ve prepared some points that are inspired by some respectful and intellectual discussions I’ve noticed on LinkedIn, various web development blogs and conversations with other professionals.

Below is a summary of some of the points that have stood out to me from the various discussions. Of course, this list does not contain every point that can possibly be made, so feel free to share your own points and express your own opinions in the comments section at the end of this post.

Points Supporting Less Emphasis on Estimates

  • For some teams, estimates are often inaccurate. While teams attempting to adopt Scrum and other estimate-supported agile frameworks will probably want to refine and improve their estimation process before abandoning it, some experienced programmers have found that the teams they work on over the years tend to have inaccurate estimates. They point out that these estimates often err on the side of over-optimism.
  • Some people intentionally provide inaccurate estimates. Some people believe in overcompensating, for example doubling their initial estimate to create a timeframe that’s twice as long. While this might ensure that fewer estimates are overly optimistic and fewer deadlines are missed, this can be problematic if the goal is to coordinate with other teams like marketing and sales, who might be caught off-guard by an earlier-than-expected release.
  • In many cases, accurate estimates are too difficult to provide. For example, if you’re being tasked with building an integration with a system or API you have little experience with, it could be challenging to form an accurate estimate. A lot of research would be needed, and necessary documentation could be inaccurate or lacking. There could be other factors, like the quality of libraries or wrappers provided for various programming languages, API stability, ongoing support and security, which could also affect an estimate’s accuracy.
  • Estimates are often misused. Rather than viewing estimates as a basic guess, teams can be tempted to treat them as hard deadlines complete with budgets assigned and people held accountable. Similarly, stakeholders often express disappointment when finished work isn’t delivered per the original estimate. In the very worst cases, teams are punished for needing more time than originally estimated, which can lead to a demotivated team, less accurate work and even less accurate estimates.
  • Estimates don’t make work ship faster. Any given work takes a set amount of time to complete, regardless of the estimate applied to it. The process of estimation, justifying estimates, explaining why actual work time varied from estimates and all other estimation-related activities can serve to slow down the team’s ability to ship work and deliver value.
  • Some teams become too focused on estimates rather than prioritization, scalability, careful scoping or other factors. Some teams divert so much attention to delivering per the estimate that they make sacrifices in other areas, like scoping the work carefully or making sure the work is scalable. This is harmful for the product and potentially delivers less value long-term.

Points Supporting More Emphasis on Estimates

  • Estimates can be made accurately, and there are ways to increase accuracy. The more you estimate, the better your estimates should become. Eventually, you can compare upcoming work to a larger historical data set of previous work performed by the same or similarly skilled and experienced team members. The more historical data you have, the more accurate your estimates will be.
  • Other teams need to plan business decisions around estimates. Marketing teams need to know when to launch marketing initiatives around major launches or updates, and sales teams and customer success teams need to know which features will be available, and customer support teams need to be staffed properly for a large release. No team wants to feel like they’ve wasted time and efforts by preparing for the wrong date, and they also don’t want to miss major opportunities by arriving late to the party.
  • Estimation can help set more realistic expectations. Some other team members or managers might take it upon themselves to assume how long work should take. Wouldn’t you rather set the expectations with your own estimation rather than open the door to other estimations from people who haven’t studied or scoped the work as carefully?
  • Estimates do not mean your workflow cannot be continuous. If you finish early in the sprint, you can pick up future sprint or backlog items that fit into the remaining time. How do you know they fit into the remaining time? They’ve already been estimated! In this way, estimates do not need to reduce work efficiency.
  • You need at least some kind of estimate to do an effective cost-benefit analysis. How can you know if it’s even worth doing the work if it could potentially take so much time and money that the costs outweigh the value delivered? How do you know this work is more valuable to pursue than other work, if you don’t estimate how much effort each is required to complete? Imagine agreeing to have a plumber fix a dribbling sprinkler head with no estimate and then learning the cost will amount to your entire life savings.
  • Estimation can reveal inaccurate expectations with burndown charts and other tools. Burndown charts can help show if work is proceeding at expected paces or if it looks like scope, time or budget will need to be adjusted to ensure success. This can be done without punishment for inaccurate estimates, but simply by responsibly tracking progress and comparing to customer expectations. Identifying any significant discrepancies early on can help moderate and readjust expectations to avoid unpleasant surprises.

Again, this list is not exhaustive, and not all points will apply to all teams. Some of these concepts may seem like they’re taken to the extreme, but I’ve personally seen, heard and read these exact concepts from real teams and professionals. Please share your own opinions and experiences in the comments section below, and let me know what you think about the value of #NoEstimates.



 

Ken Shen Robinson is a senior product manager at Praetorian Digital, where he leads product management for EdTech products that make our communities smarter and safer.

Learn More
comments powered by Disqus