Does #NoEstimates Really Work?-EN

My fellow instructor, Miquel, wrote an article about using Planning Poker and Story Points for project estimation. I’d like to address another estimation technique: #NoEstimates.

Agile Estimates as a Tool

Extensive and careful planning is typically a part of the development process when working under a traditional project framework.

In an agile setting, however, extensive planning is often the first element to go. In its place, many have adopted the use of Story Points to estimate their effort and delivery speed.

While this tool has certainly helped communication and collaboration between teams (or departments), many organizations have merely switched to estimating in points instead of hours. That is, nothing else has changed.

What is #NoEstimates?

When members of the PMO first hear the concept of #NoEstimates, you can typically see the hair stand up on their arms. This reaction is follow by the inevitable questions: “You don’t estimate? Then how do you plan? How do you know if you’ll finish the work on time?” And, I’ll admit, I had the same questions too.

To clarify, the concept of #NoEstimates does not mean that work is chaotic, with no control over progress and total blindness to predictability. On the contrary, #NoEstimates actually allows us to offer the closest possible predictability. So, we are estimating, but in a very different way.

No Estimates is based on the fact that software development, by its very nature, is not repetitive and is unpredictable. The exact product being built is not fully understood until it is developed. Therefore, it is hard to assign strict values ​​of “difficulty” to product requirements that are changing and/or are unknown. It is important to be aware that knowledge from a prior experience is variable. No two products are the same, prior work experience is not directly transferable, uncertainty exists!

Use Uncertainty to Estimate

Consider an example of ordering a shed. You ordered an unassembled 12 x 12 ft shed. You can look at how long it took someone else to put it together, but you won’t know exactly how long it will take you until you are able to unpack it and assemble the pieces. Unlike relative estimates, it is not about whether a 12 x 12 ft shed is 2 or 3 times more complicated to assemble than a 6 x 8 ft shed. It’s about whether or not we could assemble it in less than one morning. Which would be easier to decide?

The functionalities of the product are not estimated by comparison between each other, but instead they are evaluated in terms of a “maximum duration”. This duration is half an iteration.

Instead of providing an estimate for each task in the backlog, ask, “Could we do this in half an iteration?” If the answer is “yes,” then go on to evaluate the next task. If not, the goal of #NoEstimates is to divide that task up so that it results in multiple tasks, and each of those tasks can be accomplished in half an iteration.

#NoEstimates: Advantages and Disadvantages

No Estimates has several advantages:

• Collaboration and communication between team members:
  • Much like using story points to estimate, the team must come to a shared understanding of difficulty compared to their experience and skillset.
• Saving time in the estimation process:
  • This is the greatest advantage of #NoEstimates. By focusing on the most valuable part of the estimate,the dialogue between team members is more streamlined. They are able to eliminate the back-and-forth of whether it is a 3 or an 8 or a 13.
  • Don’t go into extensive detail for each of the tasks in the backlog. Discuss them just enough to achieve a shared understanding its difficulty.
  • When estimating the full scope of a project, the effort to estimate an entire backlog is drastically reduced.
• More accurate project governance: 
  • Given the maximum duration of all the tasks considered, a team who has completed 90% of their tasks has basically completed 90% of the project.
  • Compare this to a team that uses relative estimates. One backlog item could be as large as the rest of the backlog combined. Completing 90% of the tasks might only represent 50% of the project work.

On the flip side, I also see disadvantages to using #NoEstimates. Breaking down tasks that exceed the maximum size into smaller parts can result in having items in the backlog that don’t have much value, or that only contribute to a part of the value. 

However, I think this could be a small price to pay for the time saved and a more accurate vision of progress. (And, often, when working on a complex project, breaking down stories to fit into a sprint will result in the same disadvantage of delivering items that do not show value to the customer.)

Now, let’s see #NoEstimates in action. I’ll walk you through a recent experience.

Looking for Predictability

I was working with a small company that won an RFP to develop a solution for a third- party company. The third-party company required a set of products, some of which were already being worked on and others that needed to be created from scratch.

In order to finalize the contract agreements, they needed to provide predictability to the third-party company in order for them to properly communicate customer expectations. Ultimately, they needed to determine if they would hit their delivery date, given the project scope. Although having a pre-determined project scope and delivery date doesn’t seem very agile, it is often the reality of many companies.

So… We Started Estimating

We faced marathon sessions to estimate backlogs with hundreds (actually, almost a thousand) requirements. And this was just at the highest level; those requirements still had to be divided into tasks.

The process was tedious. First we identified the team that was needed to implement a requirement, then each team broke down its part and estimated it at the team level. We faced several challenges. Many times one team didn’t know if the cost of implementing a user story would be 1 or 5 or 8 story points, since it depended on how another team implemented it. To combat this, we decided to make estimates with team representatives to improve collaboration.

The next challenge was the disparity of the criteria of the referenced user story. We needed teams to estimate sizes similarly in order to determine their combined velocity. Since the objective was predictability, we didn’t want to compare their velocities.

We also had trouble determining the definition of “1SP” (1 story point). We conducted sessions between the teams to reach a consensus and then tested it by doing a joint estimate. For some it was 2, for others it was 8… and, so, we returned to a day of discussions. The result was to add more complexity to the estimation process, which was an anti-pattern. It became evident that after much time invested, estimates with a common reference standard did not work for us.

Enter #NoEstimates

We discovered the #NoEstimates concept almost by chance and immediately saw the possibilities, so we decided to try it. At this point, we didn’t have a lot to lose.

We decided to test the tool in a controlled environment, with a few teams, to see the results and go from there. The first test had amazing results.

The concept was simple. User stories should be able to be completed by the team in half an iteration, or 5 working days. This unit of measurement was the same for all teams.

The first teams who used the #NoEstimates technique were able to complete their estimate in just 25 minutes, compared to what had previously taken 2 hours. The team loved how much time this saved, and so we started to apply it to projects with more than 8 teams. Because the estimation process doesn’t add value to the final product, the less time spent doing it, the better. This method of estimating allowed the teams to synchronize and have predictability.

The next step, almost in parallel, was to start working with the Product Owners and Product Managers to define the high-level business requirements (typically a level of abstraction higher than user stories) at about half a high-level iteration (6 team iterations). This helped the teams spend even less time estimating!

About that Predictability…

Instead of determining velocity by the number of story points completed per iteration, we started determining velocity by the number of user stories completed per iteration. Now we counted only the number of tasks completed, no matter their value, since we knew the maximum size was half an iteration.

To predict our completion date, we just needed to count the number of tasks in the backlog, along with the combined speed of the team. It took about seven iterations for our speed to stabilize, but from then on, customers were given a more precise level of predictability faster.

In summary, #NoEstimates is estimating using a more predictable, less time-consuming technique than traditional projects might use.

I hope this helps!

– Victor