Get certified - Transform your world of work today



An analytical perspective

16 June 2016

Ramesh Lakkaraju

Samir Goswami
Hexagon Capability Center India

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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (6 ratings)


Scott Duncan, CSM, 6/16/2016 6:35:03 AM
I believe when Ramesh and Samir say

"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."

that they make a crucial point. If stories are small enough that they can be fully done in no more than a few days, the nature of the Sprint changes a great deal.

Teams will go to a strongly "pull" oriented system and, as Ramesh and Samir say, not worry about estimating the work compared to having a continual flow of work. Instead of committing to a fixed set of stories estimated to fit the Sprint capacity, the team will simply develop story after story and the Sprint Review becomes a true presentation of what has been done rather than also what was expected to be done and didn't get done.

The largest problem I have seen with teams and estimation and delivery is how many teams end up with work planned (and usually started) that does not get done by the end of the Sprint.

Also, with very small stories, pointing is easy: everything is basically a 1 point story. The burndown can fade away as well since there isn't a promise of what will get done (and no hours by task). Sprint and release burnups can show progress, of course.

As Ramesh and Samir say, though, "the concept is a paradigm shift and cannot be brought into a company within a day or two" and that the "maturity of the team members" is critical in making this work. I'd say:

1. start with making stories very small;
2. build the habit of completing stories before starting on more;
3. get organizational support to remove impediments that block story completion;
4. then, start experimenting with changing the planning and estimating approach.
Ramesh Lakkaraju, CSP,CSM, 6/16/2016 6:55:44 AM
Thanks a lot for the detailed review and comments Scott.
Rohit Ratan Mani, CSP,CSM, 6/17/2016 1:26:14 AM
Well put.

Thanks for putting this up.
Ramesh Lakkaraju, CSP,CSM, 6/17/2016 1:37:12 AM
Thanks Ratan
Karl Barthel, CSM, 6/20/2016 12:07:57 PM
I would love to hear what Sutherland thinks about this...
Ramesh Lakkaraju, CSP,CSM, 6/26/2016 11:46:32 PM
Yes Karl. We would also be very much interested to hear from Sutherland
Jaakko Koivula, CSPO, 7/4/2016 6:00:22 AM

thanks for the article, really interesting! #NoEstimates sounds like a interesting train of thought, completely missed this before this. Now I have my reading list full for a week, "thanks". :D

My gut feeling is that using #NoEstimates take a pretty damn mature team but also a ridicilously mature customer. I'm a consultant helping customers with their first agile software projects and don't think I would be brave enough to suggest not estimating at all to them... Not before I read some more about this, at least.
Samir Goswami, CSPO, 7/5/2016 2:50:22 AM
Thanks Jaakko Koivula for your feedback/comments. Maturity of the team is definitely a factor here. Team need to understand what will they gain bringing in this philosophy. Grooming backlog with the stories small enough so that sizing them does not matter much is another important point which will require lots of matured thinking from team. Personally I do not see any direct role of client in this, as this is something team need to adopt and practice for better output.
Ramesh Lakkaraju, CSP,CSM, 7/5/2016 5:26:37 AM
To add to Sameer's comments, it might not be a good idea to go with #NoEstimates to start with for someone who is doing their first agile projects.
Ramesh Lakkaraju, CSP,CSM, 7/5/2016 5:33:08 AM
To add to Sameer's comments, it might not be a good idea to go with #NoEstimates to start with for someone who is doing their first agile projects.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up