A question on Agile and how not to Estimate

Recently I have been working with my team to help provide the business with the ability to better forward plan and provide certainty around delivering the items on our product roadmaps. This has formed part of us moving to a more deliberate agile process (which is based on Scrum). Another part, as could be expected, has revolved around improving the estimation of work and understanding what release particular product features will be delivered in.

With regards to estimation I have previously used a number of techniques. The main ones of these and their relative strengths as I seem them consist of:

1. Relative Estimation (Usually using Story Points or T-Shirt Sizes)

Relative estimation is a technique that involves assigning a relative size to each item in the product backlog. This approach does not rely on specific units of measurement, such as hours or days, but instead compares each item to others in terms of relative complexity, effort, or risk. The most commonly used method for relative estimation is called the Fibonacci sequence, which assigns a sequence of numbers to represent the relative size of each item.

The main advantage of relative estimation is that it allows teams to focus on the relative complexity of each item rather than getting bogged down in detailed time estimates. This approach also encourages collaboration and discussion among team members, which can lead to a better understanding of the work and more accurate estimates.

1. Planning Poker (Can also use Story Points)

Planning poker is a game-like technique that involves the entire team in estimating the relative size of each item in the product backlog. In planning poker, each team member is given a set of cards with numbers that represent the relative size of each item. The team then discusses the item and each member chooses a card that represents their estimate. The estimates are then shared, and any discrepancies are discussed until a consensus is reached.

One advantage of planning poker is that it engages the entire team in the estimation process and encourages collaboration and discussion. It also allows for a more accurate estimate by leveraging the collective knowledge and experience of the team.

1. Wideband Delphi

Wideband Delphi is a technique that involves a facilitator who solicits anonymous estimates from team members, compiles them, and shares them with the group for discussion. This approach helps to prevent bias and encourages more honest and accurate estimates. The facilitator then guides the team in a discussion to reach a consensus estimate for each item.

One advantage of Wideband Delphi is that it allows for a more objective estimate by removing personal bias or influence. It also encourages participation from all team members, regardless of their role or experience level.

I have noted however that as Agile methodologies have continued to evolve, there has been a growing view that estimation may not be necessary in the context of Scrum. While estimation has traditionally been a critical aspect of the Scrum framework, some argue that it may not always provide significant value and may even be counterproductive in some cases. To this point I don't believe the current Scrum guide even includes the word estimation.

The idea of not using estimation as part of Scrum has gained traction in recent years, with some proponents arguing that estimation can lead to an overemphasis on predictability and planning, rather than adaptability and responsiveness. They argue that estimation can be a source of unnecessary stress for teams and may not accurately reflect the complexity or unpredictability of software development.

Instead, some teams are adopting a "no-estimates" approach, where they focus on delivering small increments of value and using feedback to guide their next steps, rather than trying to estimate how much work can be done within a given time frame. This approach places more emphasis on collaboration and communication within the team and encourages a mindset of continuous improvement and learning.

I think, it's important to note that the decision to use or not use estimation in Scrum ultimately depends on the needs and goals of each individual team. Estimation can still be a useful tool for teams, especially those that need to provide more predictability or have external constraints. In these cases, the approaches I mentioned above, such as relative estimation, planning poker, or Wideband Delphi, can still be valuable for estimating work and guiding the team's planning.

My question is has anyone had any success with a no-estimation approach and still being able to provide certainty back to the wider business around timeframes on delivery of features? Whilst the no-estimation approach may have benefits to the development teams, I would expect that product teams, marketing teams, sales and account managers would like to be able to give credible timelines on the delivery of products and product features to prospective and current customers. Is there a good way of doing this without some form of estimation? Can we have our cake and eat it too?