Agile has become the mainstream process for software development. Most organizations in the software industry have embraced Agile concepts to achieve a better outcome. Although organizations claim to have reaped clear benefits from transitioning to the Agile way of developing software, many agree that estimation remains their area of concern.
We frequently hear that most teams are unable to deliver what they have committed to, and sometimes their estimates are totally out of sync with the estimate that was planned. Inaccurate estimations result in huge project overruns that hinder the organization's ability to reach the market early, resulting in its poor market performance.
It has been more than seven years since we embraced Agile practices. During this journey, we frequently experienced situations in which we didn't meet the estimated effort and were always struggling to achieve the committed items. The reason was mostly because of lack of clarity, underestimation of the complexity, or lack of a skill set. We were so fed up with our estimates that we hated giving estimates at all. That was when we were exposed to #NoEstimates.
Our understanding of #NoEstimates
The #NoEstimates concept is intriguing because the name itself conveys that estimates are not required for doing the tasks. It took some time to wrap our minds around the concept of #NoEstimates. We went through several articles, blog postings, and discussions on the Internet to understand what exactly it is advocating. We were thankful for Vasco Duarte’s video
, which explains a lot about it.
The main idea behind #NoEstimates is to implement a method that helps with navigating the project and collaborating with stakeholders in a transparent and productive manner so that the team remains focused on the value of the work, which matters the most. This goes well with the Agile principle, "Individuals and interactions over processes and tools."
After being assigned a business goal, the team figured out how to do the work. Following are some important features we noted.
- Allow your team to focus on the value of the project output from day one. #NoEstimates keeps everyone focused on the business impact.
- The value is not in getting better at estimates but rather to get better at making decisions. #NoEstimates as a tool helps you make good decisions with reliable data based on the project progress. The effort spent for accurately estimating the work does not add value.
- For an Agile development team, strength is not the velocity represented by some numbers. It is the clarity of the work that the team has, which helps them to make important decisions for the project or business.
- #NoEstimates does not mean drop estimating from now on; rather, the goal is to get better at our job by adding values to it. Still, there’s a lot to learn and practice.
The core of the #NoEstimate approach is based on smaller slices of work (stories). The smaller the work, the less need for estimating its size. One can start measuring the progress. That is, stop guessing and start forecasting.
Most of the time during the progress of the project/product development, we discover that we need to build something other than what we were actually supposed to build. This is another strong argument for not realizing the value of estimating the complete backlog stories beforehand. The continuous feedback from stakeholders helps in early detection of required changes. Therefore, the smaller slices of work not only help with saving effort with the estimation process but also help with effective decision making to navigate the development.
Recommendations for #NoEstimates
"#NoEstimates is not just about estimates; it is an important step in the paradigm shift from a plan-driven to an empirical approach to software development." — Georg Raeder, Lean Facilitator, EVRY, Norway
As rightly mentioned here, the concept is a paradigm shift and cannot be brought into a company within a day or two. We believe that maturity of the team members and understanding the concept of #NoEstimates are two key aspects for successfully practicing it. By understanding the concept, we mean that one needs to understand well the value of making good decisions for the project/product over playing the numbers game. Team velocity can be a helpful indicator, but it really does not add any value to the outcome.
The maturity of the Agile team is assessed by the way it burns stories in the sprint. The expectation is that the team will focus on one story at a time and complete it before moving to the next. In other words, avoid falling into the trap of a mini-Waterfall during the sprint. It's possible for the team to work on more than one story at a time, but certainly it will not be the case that all stories are in progress and are completed on the last day of the sprint.
It's a best practice to start with the backlog of defects or very small stories that aim to either improve or increment the existing features. These kinds of stories do not require much discussion and estimation, and assigning points to them really does not add any more value than getting them done. The team can complete them in two to three days. This will be helpful in predicting the completion date rather than guessing that date on the basis of velocity points.
Depending on the outcome of this learning phase, the team can further master the process and perhaps even guide other teams toward adoption. If it does not really help in solving the problem of better predictions and decision making, the team is free to adopt what works best for it.
To conclude, we can say that many software development organizations are plagued by the estimation problem. #NoEstimates is a tool that can be adopted as an alternative approach to overcome the associated pain and problems.
Be very careful not to move away from the current practice until the impact of doing so is understood. The estimation process during the Planning One phase is when a team discusses the story in greater detail for the first time and evaluates it against the Ready criteria. If you drop the estimation process, when will the detailing occur? An alternative approach can be backlog grooming, but in the end, the team has to determine what fits well for their practice.