Estimate or not to estimate?
Why NoEstimate is an idea worth trying
I remember my first project inception, working as a Team Leader of an Agile Development team. Our team grouped with our main internal clients for a one week immersion workshop. The goal was to understand the and co-create project vision and alongside our main clients (and stakeholders) define an initial MVP and be able to kick start the product development. After defining the main set of features, priorities, and the approach to start the project, our main stakeholder asked a very usual question:
When this MVP will be done?
A Senior Dev from the team answered (with sarcasm):
How long would you like me to say this will take?
The meeting became a little awkward at this point and there was a little tension in the air. The client pushing to get a date, and the team hesitant to estimate things. Have you ever experienced a similar situation?
Fortunately, we manage to provide the client with a raw idea about the project duration, while clearly communicating the assumptions and trade-offs we may encounter along the way that could alter the initial raw estimate.
Estimate or not to estimate? That is the question.
In one side we have the project stakeholders/sponsors trying to decide whether or not to make a sizeable investment and requesting information about the duration of the project in an attempt to make an informed decision. On the other side, you have the Dev team, insecure to give an estimate based on a superficial understanding of the problem’s complexity, and most importantly, afraid that any estimate would be faced as a contract date set in stone.
As a Team Leader you need to balance both needs — team and client. You do not want to over promise an unrealistic date based on a shallow understanding; but at the same time, you need to reassure your stakeholders/sponsor by providing them with useful information, so that they can make the right call.
When estimates are still valuable?
Estimates are extremely valuable at the start of any project as a way to understand the size and risk of an investment. So the catch here is to align both with clients and team, that one section of the workshop will be dedicated to understand risk by discussing the business value, the technical uncertainty, and effort required to accomplish different pieces of work, providing all with a rough idea of project size and risk. Once you have sized the different pieces of work you can then have an idea of project overall size. The lean inception proposed by Paulo Caroli, provided a great framework to facilitate that discussion and calculate MVP's overall effort.
It is important to clearly state that the goal is not to define a rigid deadline set in stone, but instead, a likely delivery date (if mapped scope and assumptions are confirmed during development work). The important is to have everyone engaged and aligned about a target goals and timeframe for the project, and sharing the same view about the uncertainties that may impact the overall effort required to accomplish the project. For example, a project duration can range from 10 to 12 months if a certain set of conditions do not change. This gives both team and clients with a better understanding of the risks involved. At the end, it is up to the client to decide whether to proceed or not based on their risk taking appetite. An early conclusion pointing for a prohibitive risk is a better outcome, than realizing late and when a sizeable investment has already been made.
When estimates become less valuable?
After your project start, the mapped work will be refined iteratively and this will alter the amount of units of work (also known as User Stories). Besides, your team's understanding of the problem and technical complexity will also evolve, and the initial estimates may be outdated. So a common practice is to iteratively re-estimate the work. This idea was popularized by well known and widespread methodologies such as Scrum. However, such approach may gradually become cumbersome and problematic in the long run given:
Estimates accuracy is dynamic
Meaning of estimates must be constantly repurposed and there is a learning curve every time the team move to another area of the scope, play with a new technology, or there is a change in the team formation.
Estimates may introduce noise into your process data
Its is hard to know if delivery throughput changed due to fluctuations in team's process efficiency, or due to fluctuations in estimate accuracy (see charts below).
Estimates may not reflect accurately your progress status
Dynamic nature of scope and iterative refinement makes info to be reported extremely dynamic, which end up requiring constant estimation (or re-estimation) and consume team effort and capacity. Is not uncommon that a status report loose its validity right after being shared.
Estimates may create an overhead for your team
Keeping a plan and estimates updated all the time, requires to constantly stop the team to re-estimate things, specially if we expect team to refine and breakdown work iteratively. This disrupt team’s concentration, flow of development work, and also create undesirable cognitive load on people.
NoEstimates: Myths and misconceptions
NoEstimates is a movement that generates heated discussion within the Agile community. Since I started to manage product development teams, I led many of them into the journey from working with estimates to work with no estimates. Today, I consider myself an enthusiast of the NoEstimates movement and I advocate for eliminating estimates from your product development process as your team evolves and become mature. Before explaining why I advocate for that, I must clarify a few myths behind this idea:
Myth #1: NoEstimates means there isn’t a deadline expectation:
It is naive to think that your client won't have a date expectation in mind. The main change is the approach: with no estimates you will use historic data generated by your process to validate if your client expectations are realistic or if you need to have a conversations to review it. This shift the focus from working with your the team to provide an accurate estimate, to focus on understanding your process capacity/efficiency and have alignment on what are realistic and likely delivery scenarios.
Myth #2: NoEstimate means more autonomy to decide the work
Team autonomy is a by product of trust and not from the methodology you adopt. Working with Noestimate, however, may provide the team with more room for improving its own process, as they can move past estimates and come up with a better system to track progress. It also may bring the responsibility to guide clients on a journey to understand how NoEstimates works, and how this system can improve both visibility and reliability of the team's progress.
Myth #3: NoEstimates means we have no predicatbility
The fact a team does not estimate, does not mean they cannot make predictions of delivery dates. This can be done by gathering data from your process such as delivery throughput, development lead time, and overall user stories' lead time. Then use this data to understand your team's delivery rate and make extrapolations to map future delivery scenarios. As stated by Ron Jeffries:
Kanban approaches generally limit work in process, and for small teams the ideal limit seems to be one. Neither of these approaches has any need to estimate how long something will take. Instead, they measure how long things take, in “cycle time”, and use that to make such predictions as are necessary.
Myth #4: Estimates are always pure waste
Working with NoEstimates and lean processes require team maturity both from team and organization. All people involved in the project — team and stakeholders — must be invested into rapidly making decisions and work alongside each other to maximize flow. For organizations and teams at the beginning of this journey, the process of estimating may provide a framework for discussions and a sense of security. Also the estimate process may encourage the team to have discussions that they won't, otherwise have. So, perhaps, the true value of an estimating sessions, are the discussions and collective learning they foster.
Benefits of working with NoEstimates
More agility to embrace changes
The team creates the habit of breakdown work iteratively without worrying with changing estimates. If a dev pair think that a User Story is inflated and can be broken down into 2 pieces, they can do it to quickly tackle them or isolate a dependency. They just inform the team (in the stand up) so all are in sync.
Easier transition to a lean approaches to continuous delivery
The concept of iteration loose meaning and it is easy to transition to a lean approach — for example, using a Kanban based process and WIP limits.
Forecasts with higher accuracy
By reducing sources of variability resulted from the estimation process, and using historic actual data, your understanding of team's capacity and accuracy of predictions are likely to improve.
Unified understanding and simplified communication
I've worked in teams in which some members used estimates to reflect the effort, while others to reflect tech uncertainty. Using units of work — or User Stories- creates a universal language that is easier to understand and to communicate.
Increased flow by working with smaller units of work
The team start to improve its ability to breakdown big stories into smaller ones, and encourages the team to always think the simplest solution. This shift the mindset from better estimates to better analysis, with positive impacts into the quality of work and frequency of small deliveries.
Other side benefits
It may bring other side benefits related to having smaller stories. For instance, smaller stories are easier to test, problems easier to spot, they provide you with more flexibility to prioritize, make easier to cope with internal dependencies, and simplify the visualization of process' bottlenecks (as you can easily establish and visualize WIP limits and inventory levels using units of work).
The roadmap to eliminate estimates
1. Work to ensure your process is stable
You can achieve that by looking at your team's lead time. Is your leading variation too big? what are the variables contributing for a ever changing lead time? Or is your lead time fluctuating within a time threshold? Depending on those answers, estimation may not be adding much value, and this can be a great topic to share with your team. Below a few examples of how can you assess your process stability:
This chart above shows a series of stories order by date and their associated lead time (from dev to done). By looking at the data we see that the process is very stable and most stories have a lead time gravitating within the 10 to 20 days threshold. Also the time from Dev to prod concentrated in the 5 to 10 days bandwidth.
Another interesting analysis (above) is to look at frequency of stories by the time they spent in development (which is usually what developers estimate). By looking to the chart we can see that more than 83% of stories in this team, took from 1 to 5 days to be accomplished. The higher volume of very small stories (50,72%) may compensate the low percentage of long stories (7,25%).
2. Collect data using story points and using units of work
Trace analysis comparing both datasets. This is the most important step to understand if your team is ready to work with NoEstimates and to generate information to back up a transition. For that you may need to adapt your current tools to work with both units (points and user stories). Part of convincing your stakeholders to experiment with NoEstimates, is to reassure that this transition will be transparent to them. So all tracking tools and reports are still going to generate the information and visibility they are use to have.
In the chart above, we show that the overall size of features delivered by a team using points and user stories converge overtime to a similar value. This may indicate that team is doing a good job breaking stories into units of similar size, and that estimates may no longer add valuable information.
The idea that teams don't like estimating and will happily give up estimating seems obvious. But sometimes this bring a initial disruption to team's processes and a certain anxiety. So dedicate some sessions to explore the data collected from the process with your team, explain the concepts, the tools and metrics used to track delivery (ex: burn up, lead time). In many cases the team may conclude that is worth experimenting a new process without estimating, with the option to revert back to estimates if they feel the need.
3. Get buy in from main stakeholders
Getting buy in from stakeholder might be slightly more difficult. Specially if they have other teams working with estimates. Then introduce the topic as a pilot with a fix duration so you can review the results after a few months working with NoEstimates.
4. Run the experiment and review results
Encourage stories to be broken down into smaller one as a regular practice without the need of meeting with the entire team or formal validation. Dedicate some regular time with your team to review the results. Also share the results with your clients.
Estimate, then don't estimate
Estimate may bring structure and a sense of security both to the team and stakeholders, which can be instrumental when implementing and agile transformation. This is particularly true when the organization is used to process heavy frameworks such as waterfall approaches. Just be careful not to stick too much to a comfortable formula and stop evolving.
Relying too heavily on estimates and invest excessive effort to improve this practice may lead your team to work for the process, and not making the process to work for them.
The discussion " Estimate Vs NoEstimate" should not be avoided, given it can encourage a deeper understanding of team's processes and empower your team to experiment with different approaches.
References
Caroli, P. [Lean Inception] how to estimate the MVP and for the overall product effort? — Jul 2017 — Caroli.org
Caroli, P. Technical, User eXperience and Business Review — Feb 2022 — https://martinfowler.com/
Caroli, P. Lean Inception: How to Align People and Build the Right Product — Oct 2019 — Editora Caroli
Lopez, J. NoEstimates — Jan 2022 — Medium
Jeffris, R. The NoEstimates Movement — Apr 2013 — https://ronjeffries.com/
