ThoughtWorks
  • Contact
  • Español
  • Português
  • Deutsch
  • 中文
Go to overview
  • Engineering Culture, Delivery Mindset

    Embrace a modern approach to software development and deliver value faster

    Intelligence-Driven Decision Making

    Leverage your data assets to unlock new sources of value

  • Frictionless Operating Model

    Improve your organization's ability to respond to change

    Platform Strategy

    Create adaptable technology platforms that move with your business strategy

  • Experience Design and Product Capability

    Rapidly design, deliver and evolve exceptional products and experiences

    Partnerships

    Leveraging our network of trusted partners to amplify the outcomes we deliver for our clients

Go to overview
  • Automotive
  • Cleantech, Energy and Utilities
  • Financial Services and Insurance
  • Healthcare
  • Media and Publishing
  • Not-for-profit
  • Public Sector
  • Retail and E-commerce
  • Travel and Transport
Go to overview

Featured

  • Technology

    An in-depth exploration of enterprise technology and engineering excellence

  • Business

    Keep up to date with the latest business and industry insights for digital leaders

  • Culture

    The place for career-building content and tips, and our view on social justice and inclusivity

Digital Publications and Tools

  • Technology Radar

    An opinionated guide to technology frontiers

  • Perspectives

    A publication for digital leaders

  • Digital Fluency Model

    A model for prioritizing the digital capabilities needed to navigate uncertainty

  • Decoder

    The business execs' A-Z guide to technology

All Insights

  • Articles

    Expert insights to help your business grow

  • Blogs

    Personal perspectives from ThoughtWorkers around the globe

  • Books

    Explore our extensive library

  • Podcasts

    Captivating conversations on the latest in business and tech

Go to overview
  • Application process

    What to expect as you interview with us

  • Grads and career changers

    Start your tech career on the right foot

  • Search jobs

    Find open positions in your region

  • Stay connected

    Sign up for our monthly newsletter

Go to overview
  • Conferences and Events
  • Diversity and Inclusion
  • News
  • Open Source
  • Our Leaders
  • Social Change
  • Español
  • Português
  • Deutsch
  • 中文
ThoughtWorksMenu
  • Close   ✕
  • What we do
  • Who we work with
  • Insights
  • Careers
  • About
  • Contact
  • Back
  • Close   ✕
  • Go to overview
  • Engineering Culture, Delivery Mindset

    Embrace a modern approach to software development and deliver value faster

  • Experience Design and Product Capability

    Rapidly design, deliver and evolve exceptional products and experiences

  • Frictionless Operating Model

    Improve your organization's ability to respond to change

  • Intelligence-Driven Decision Making

    Leverage your data assets to unlock new sources of value

  • Partnerships

    Leveraging our network of trusted partners to amplify the outcomes we deliver for our clients

  • Platform Strategy

    Create adaptable technology platforms that move with your business strategy

  • Back
  • Close   ✕
  • Go to overview
  • Automotive
  • Cleantech, Energy and Utilities
  • Financial Services and Insurance
  • Healthcare
  • Media and Publishing
  • Not-for-profit
  • Public Sector
  • Retail and E-commerce
  • Travel and Transport
  • Back
  • Close   ✕
  • Go to overview
  • Featured

  • Technology

    An in-depth exploration of enterprise technology and engineering excellence

  • Business

    Keep up to date with the latest business and industry insights for digital leaders

  • Culture

    The place for career-building content and tips, and our view on social justice and inclusivity

  • Digital Publications and Tools

  • Technology Radar

    An opinionated guide to technology frontiers

  • Perspectives

    A publication for digital leaders

  • Digital Fluency Model

    A model for prioritizing the digital capabilities needed to navigate uncertainty

  • Decoder

    The business execs' A-Z guide to technology

  • All Insights

  • Articles

    Expert insights to help your business grow

  • Blogs

    Personal perspectives from ThoughtWorkers around the globe

  • Books

    Explore our extensive library

  • Podcasts

    Captivating conversations on the latest in business and tech

  • Back
  • Close   ✕
  • Go to overview
  • Application process

    What to expect as you interview with us

  • Grads and career changers

    Start your tech career on the right foot

  • Search jobs

    Find open positions in your region

  • Stay connected

    Sign up for our monthly newsletter

  • Back
  • Close   ✕
  • Go to overview
  • Conferences and Events
  • Diversity and Inclusion
  • News
  • Open Source
  • Our Leaders
  • Social Change
Blogs
Select a topic
View all topicsClose
Technology 
Agile Project Management Cloud Continuous Delivery  Data Science & Engineering Defending the Free Internet Evolutionary Architecture Experience Design IoT Languages, Tools & Frameworks Legacy Modernization Machine Learning & Artificial Intelligence Microservices Platforms Security Software Testing Technology Strategy 
Business 
Financial Services Global Health Innovation Retail  Transformation 
Careers 
Career Hacks Diversity & Inclusion Social Change 
Blogs

Topics

Choose a topic
  • Technology
    Technology
  • Technology Overview
  • Agile Project Management
  • Cloud
  • Continuous Delivery
  • Data Science & Engineering
  • Defending the Free Internet
  • Evolutionary Architecture
  • Experience Design
  • IoT
  • Languages, Tools & Frameworks
  • Legacy Modernization
  • Machine Learning & Artificial Intelligence
  • Microservices
  • Platforms
  • Security
  • Software Testing
  • Technology Strategy
  • Business
    Business
  • Business Overview
  • Financial Services
  • Global Health
  • Innovation
  • Retail
  • Transformation
  • Careers
    Careers
  • Careers Overview
  • Career Hacks
  • Diversity & Inclusion
  • Social Change
Agile Project ManagementLanguages, Tools & FrameworksTechnology

"No Estimates" is not the (only) Answer or: Moving towards Predictability

Inger Dickson Inger Dickson

Published: Jul 16, 2020

Dear No Estimators: You are probably estimating, even if you don’t admit it. When you say something is “small” or “easy”; when you say “yes I think we can get that done” or “these are about the same size for flow” or “these are about the same over time”, you are estimating. And even if you aren’t, please remember that for any work that involves expectations, there are stakeholders with questions that need answers, and no one benefits without predictability.

A Story

Some years ago, I was at an Agile Alliance conference where I attended Stalwart’s Session: a fishbowl with early pioneers in Agile. I could hardly contain my excitement – my hand was the first one up with a question that had been burning in my mind for a while. It is a common, popular opinion that they had changed a lot more than “just” software development with Agile's influence; beyond the approach and practices, to careers, perception, organizational structure, and product thinking in general. If they could take one thing back, what would it be, and why?

The answer was “estimates” and because they were used for evil. The wrong people were asked at the wrong times, and then the information was used for the wrong decisions. (My distillation – not their words).

I had to agree – project failure rates are so famously rampant that I could not narrow down the links to reference here. I’d been on too many teams whose stakeholders, months into a project, held teams (sometimes angrily) accountable to educated guesses made when they knew least about the work.

So: What do we do?

Enter #NOESTIMATES

At this point, a #NoEstimates movement was already underway. #NoEstimates was created in response to being held to imperfect expectations that were made with imperfect information. It was designed to eliminate the waste of ‘conversations about the software’ instead of actually building the software. It serves a purpose.

When “No Estimates” makes sense

And indeed, there are times when estimating does not help.
 
  1. When something is too big to estimate anyway. When there are questions that are stopping you from having a general idea of what it will take to build a product, then invest time and effort to discover those answers first.
    • Instead of estimating, use timeboxed spikes to answer the questions that are stopping you from sharing a reasonable expectation. Spikes are a time-bound investment to find answers. Invest what you can tolerate investing to find the answers to help you understand the problem and possible solutions better.
  2. When both the team and the product is established, mature and predictable. That is, when at least one MVP is in the hands of the people for whom it was designed, and the team has the experience of shared assumptions and decisions, context and skills to build mostly equally sized stories, and they have done this for a while, then estimates are probably a waste of time.
     
  3. When the product is in a repeatable cycle of life. That is, when the team and product are not in the beginning, or in the end stages of product development, estimates are probably a waste of time here as well.
    • When a team is already in flow and keeping a pattern of predictability, estimating becomes redundant. Even then, checking on that predictability is helpful to keep the conversations on shared assumptions and dependency meaningful.

Using #NoEstimates at any other time is not helpful and makes life harder

To reiterate: Not arriving at a shared understanding or expectation setting hurts those around the work. Primarily because:
 
  1. The burden of predictability is hidden.
    • The burden of predictability exists, and hiding it in the name of waste avoidance only shifts the burden of that predictability to others with less context that the team has, and forces dependent teams and stakeholders to make worse guesses.
  2. Or, it moves the burden of predictability to story authors.
    • #NoEstimates believes that work normalizes over time. Work will not normalize over time without the mindful intent of the team. If you are not estimating, you are not providing feedback to each other or to story authors, and then story authors must guess at stabilizing their story size without this feedback.
    • This scenario might actually be worse, because they are probably less equipped to determine the technical feasibility of whatever it is that is being built.
    • Unvalidated assumption of said predictability also increases the chance of burying very real risks and issues that could have been resolved before adverse effects were realized.
  3. It perpetuates a fantasy where no one needs a timeline.
    • Go/no-go decisions are real, and investment still takes the shape of time and money. Product-value driven KPIs, OKRs have a place on whether what is being built is worth it. ROI helps stakeholders decide whether or not to try.
    • A successful project/program/product requires intricate coordination of many parties, teams, and stakeholders. Timelines, expectations management, and dependency mapping and resolving are key components to ensuring the coordination is done well. 
  4. None of that matters anyway really, because you are already doing it.
    • You say something is small? Easy? You can get it done “soon”? You can predict flow? You are estimating.
    • Instead of wasting time talking about estimates, just start experimenting with estimating and you’ll get better at it, and get past it faster.
  5. Teams inside an ecosystem need to set expectations, and should be able to come to a shared understanding around a known or controllable “done” – at least for a controllable scope of work.
    • For example, when approaching an MVP in order to get feedback from customers to decide if or how to move forward. Maybe it’s just an “epic” or “feature” idea as a unit that should be released.
    • Or when sunsetting a system on a deadline that is set.

Using Estimates Properly

Once estimates are built properly, by the proper group at the proper time, they need to be used properly. This can take patience and a leap of faith on behalf of stakeholders who have been burned by project estimates in the past. To empathize with their context, it might be helpful to remember that stakeholders are often unfortunate beneficiaries of failed initiatives. 

Image Inception

Helping stakeholders balance expectations with evolving and maturing understanding on delivery takes not only buy-in on their own behalf, but also coaching, transparency and accountability on the part of the delivery team. Some things that might help them use estimates properly is to help them remember what estimates can help with, and what they are not.

Estimates should help:
  1. Decide to start work or not. It’s not about if you can get everything done. It’s about MIGHT WE at a level of risk that is acceptable, and then the gift to make informed decisions as time and development wears on.
  2. Balance “how soon can we get feedback on this thing until we can test if it’s valuable to the people for whom it is designed”? In other words: How much do we want to work on something before we get feedback on it?  
  3. Drive predictability so the team and those dependent on the team can plan.

What Estimates Are Not

Estimates are not a deliverable. Yes, you may end up with loads of observable data. This observable data only has a history, whereas someone on the team has not only the context of history but also the context of direction. The deliverable is working software, and estimates are not working software. 

Estimates are not a velocity (moreover: “velocity is not speed; it is speed in a direction”). Estimates are a component of the speed part of the velocity equation – and not in any way the full picture. They are a measure toward completion of some amount of scope, over time with all its flaws and interruptions, toward some measure of done. And this is when the customer KPIs can begin.

Estimates are not waste. Beyond predictability: as team members strive to reach agreement, the conversations and outlines of assumptions and constraints that are driven from this activity are sometimes the most valuable output from these exercises. Estimates help the team self-examine. Especially when roles for the team are cross-functional – not only developers.

Estimates are not “Process over People”; they are not “Documentation over Working Software”. Estimates reflect a conversation about what it takes to get to working software to help reflect and plan. 

Estimates are not always the first item on your checklist. One purpose of an estimate is to set expectations, and the team might not have all the answers in the beginning. The team may need to run some spikes or spike iterations to explore the answers to questions that are keeping the team from answering those questions.

Estimates do not need to include EVERYTHING. There may be a task set to the team that is just too large for a meaningful estimate. In these cases, a perfectly reasonable approach is to break the task at hand into smaller pieces that have value once delivered. For example, you may have no idea how to replace a whole legacy system in one go, but breaking down or decommissioning one part of it and providing usable value is still useful.

So: What purpose do estimates serve? Hint: It depends

Effort put into estimates should be a factor of how much the team knows about a problem and the level of granularity of the question. Estimates themselves should be provided by those closest to the work, and should be just enough to make the next decision.

In Closing

Estimates are about sharing assumptions, maturing toward predictability, and about making the best decisions possible with the information available at the time, with the people who are best equipped to make them. 

NoEstimates was about creating safety from being held accountable for setting flawed expectations in a flawed system. But, setting expectations on the whole is still a team responsibility, and estimates is one way of communicating that message to stakeholders. Development work is not, and should not, be treated as a black box.

The team has the best information, experience, and opinions to complete work and… they probably have an estimate.

PS: Building Estimates Successfully

When I say estimate, I mean relative, and not absolute, size. It is common knowledge that a team will not get “absolute days” right with any regularity – and getting “number of days” right simply does not matter. The goal is to be predictable. That is, to be able to set reasonable expectations, verify a common understanding and do this with minimal waste, and then extrapolate ‘time’ from there.

Step 1: Breaking down work into the smallest reasonable, INVEST-principled increments (a good reference in INVEST was shared some time ago from Studios) and then making a guess at “this is bigger than that” rather than a guess at an exact unit of anything is all that is needed to start. At this point I assign fibonacci numbers to the “buckets” starting with “1” for cards in the group that was estimated at “smallest”.

Step 2: Once you have your known backlog organized into “buckets” of like-relative size, next is to iterate through asking the team for feedback on how many they feel they could reasonably accomplish given the following constraints: a) a full sprint, with b) full team capacity and c) given other team constraints (like predictable ceremonies or other constraints on agreed-upon ways of working). 

I mix differently-sized story cards into blind scenarios that the team accepts into the hypothetical sprint and then stops when they think they could not reasonably complete the work anymore. I have found that after a few of these iterations, the team usually lands on a consistent enough ‘quantity’ of work to use to set expectations outside the team.

This activity should be time-boxed and can give a good enough guess at a velocity to retrospect meaningfully later.

After a short enough sprint or two, a team can start to see what “small” really means, check assumptions, and begin their journey toward predictability.

With deliberate work and mindful attention, as time progresses “This is bigger than that” can mature into “these are all around the same size” and then evolve to an observed “story count”. However, starting at this last step robs your team of the conversations to check each other’s assumptions and the clues on retrospective guidance that an estimate brings them, and robs stakeholders outside the team of reasonable expectation setting.

Another good resource worth reading is Agile Estimation and Planning by Mike Cohn, with particular attention to chapter VII’s case study.

Technology Hub

An in-depth exploration of enterprise technology and engineering excellence.

Explore
Related blogs
Transformation

Mastering Digital Transformation: A Case Study (Part 1)

Dr. Martin Kramer
Martin Milcke
Learn more
Agile Project Management

Exploring value-oriented incremental delivery

Vinod Santhanam
Learn more
Agile Project Management

How estimating with "story counts" worked for us

Huimin Li
Learn more
  • What we do
  • Who we work with
  • Insights
  • Careers
  • About
  • Contact

WeChat

×
QR code to ThoughtWorks China WeChat subscription account

Media and analyst relations | Privacy policy | Modern Slavery statement ThoughtWorks| Accessibility | © 2021 ThoughtWorks, Inc.