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.
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?
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:
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:
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.
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.
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.
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.- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
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:
- 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.
- 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?
- 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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
