A common theme throughout this book has been a focus on building software in small manageable chunks so that we can deliver incrementally and gather feedback as we go. We discussed adaptive planning and how this compares to traditional project predictive planning back in Chapter 1, The Software Industry and the Agile Manifesto. In particular, we talked about estimates in the software industry and how difficult they were to get right when used to predictively plan large pieces of work.

The Standish Group's Chaos report is an annual report which looks at the state of the software industry. In 2015, it looked at over 50,000 software projects worldwide and assessed them based on their ability to deliver on time, to budget, and to obtain a satisfactory outcome. Based on this criteria, only 29% of projects were successful. Of the rest, the ones that failed outright made up to 19% of the total. Those that were challenged, that is, the final product was compromised somehow, comprised the remaining 52%.

One key aspect of the 2015 report was that the Standish Group used their new metrics for measuring a satisfactory outcome. Previously, they'd only measured on target, meaning the percentage of requirements delivered. In 2014, they re-coded their database to include measurements for satisfied (very high to very low), value (very high to very low) and on strategic corporate goal (precise to distant).

This is a major shift in our industry. As the saying goes, what gets measured, gets improved. In other words, if we measure value, we get value. And up until this point, our industry has had a very poor reputation for value return on investment. As Angel Medinilla points out in his excellent book, Agile Management: Leadership in an Agile Environment, this is sometimes as low as 50 or 60 cents per dollar spent.

 In Chapter 9, Seeking Value – How to Deliver Better Software Sooner, we talked about focusing on value as a more important metric for measuring a user story's successful outcome. So delivering on value is far more important than delivering on time and budget. Think about it; if we deliver on value, then we must have delivered on time and budget, otherwise, all value would have been destroyed by the lack of the latter.

So, when we accept that we're bad at estimating and that value is a better measurement than budget or date, if we combine these two things, our view of how we focus on getting predictability in delivering our work will start to shift. 

If we want to increase our likelihood of a predictable outcome, we first need to focus on aspects of delivery that include stability, frequency, and cadence; all of these contribute to reducing variability. If we focus on these, then because we have more predictable outcomes, we will naturally get better timelines.

If we combine this with a focus on value creation, adopt lean software development principles to maximize the value delivered, and the value we create continues to offset the cost of creating it, then the need for estimates will start to become a moot point. 

Combining lean thinking with incremental delivery means we begin to focus on the flow of work, and as discussed in Introducing some Lean thinking to improve flow in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle, focusing on flow means we focus on the following two aspects of delivery: 

1. How long a piece of work takes to go from to-do to done. Also known as the cycle time. 
2. Breaking down work into small discrete chunks so that we can deliver value, which either adds directly to our customer's business value, or to our understanding of how best to solve the business problem.

Our aim with this is to focus on small batches of work and foster collaboration for end-to-end delivery. Once we can do that, and we have some completed work that we can use as a benchmark, we can even start to forecast how long it will take us to complete other parts of our work. For example, if we complete 5 User Stories in 2 weeks, and we have a further 10 similar User Stories to complete, we can forecast it will take us another 4 weeks.

However, several things make forecasting difficult with or without estimates:

• If we're working in the same area of our system, we can compare User Stories that we haven't done with User Stories that we have done. If our area of work changes, then it will no longer be possible to compare like this. Instead, we'll have to wait until some aspect of that work has been completed before we can start forecasting the remaining stories.
• Our backlog isn't all equal, some stories have been refined and broken down, some haven't. We will be able to compare the stories that have been broken down to stories that we've already completed. This will lead to a more accurate forecast but only for those stories. 

The aim of the No Estimates movement is as follows:

• Focus on value, both delivering and measuring it.
• Make delivery more predictable by focusing on reducing waste (including bugs).
• Understand that there are better options than estimates.

Imagine if we could shift our entire focus to value creation and measure our value return on investment rather than how long it took to build something. This is when our team/organization will become a true learning system.