Tag Archives: Software development

#NoEstimates Story Sizing

A way to determine if a story is small enough without estimating it.

TL; DR

“No Estimates” is a modern movement in software development that focuses on eliminating wasteful estimates. However how do you know if a story is small enough to be accomplished without estimating its size? There are a series of rules that when followed guarantees a bite size bit of work.

There are a series of rules that when followed guarantees a bite size bit of work. #NoEstimates Click To Tweet

Setup

“No Estimates” is built on continuous delivery of valuable product. That means that the business must be able to measure the output of a development team in near real time. If releases are regularly weeks or months away, then you leave the business with few tools to measure with. Faster the delivery the better they can measure. Stories need to be small enough to complete daily.

How do guarantee that the average story is small enough to be completed in a day without estimating?

The Rules

There are three rules that can be followed to ensure that a story is as small as possible. In all three rules, the word team means much more than the development team. It means the whole project team including the developers, the product owners, testers, management, executive management and anyone else who has a stakes in the product being delivered.

  1. Does everyone on the team have the same understanding of what the story delivers, and what need it addresses?
  2. Does everyone on the team have the same understanding of when the story is completed?
  3. Is the story free of any known preconditions?
Three simple rules for sizing stories in #NoEstimates Click To Tweet

Understanding

Gaining understanding about a story that crosses skill and role boundaries is difficult. To better communicate intention, we must be communicating simpler ideas. The first two rules do a lot to limit the size and scope of a story.

The first two rules also ensure that the right thing is done. A shared understanding means a shared vision and shared responsibility. If we understand what is to be done, and when it is done then we do not mistakenly build the wrong thing.

Preconditions

Once everyone understands what is to be done, and when it can be considered complete then we have a certain level of understanding about the story. If at that time anyone can think of a precondition that must be done before the story is complete, then the story is too big to be worked on. Maybe it is time to work on the precondition, or something else entirely.

The operative word in the last rule is “known”. We could spend an infinite amount of time looking for and understanding preconditions. It also goes without saying that we may find new preconditions as we start working. The important thing is that no preconditions are discovered in the process of gaining group understanding.

During the doing of the work, if we do discover a precondition we then need to decide if we continue or abandon the current story? Most often we can continue, especially if the precondition that was discovered meets the 3 rules, which means we must communicate our progress effectively.

Summary

In short, by following the three rules we can ensure work is taken in bite size chunks, even without estimating.

The problem with the #NoEstimates Debate

The problem with the #NoEstimates debate is that both sides are not arguing the same thing and therefore the debate focuses on invalid points. The #NoEstimates hash tag has almost nothing to do with estimates, despite the focus the debates have. What is really being discussed is fundamental ways of doing business.  The pro #NoEstimates group is talking about a fundamental shift in how business is being done. We are talking about regulating and controlling price of software in a very different way.

Without changing, in entirety, the way in which business is done then a lot of the concerns the anti-#NoEstimates group bring up are valid. However, we are talking about a fundamentally different way of doing business.

The basic tenant of #NoEstimates is to change the way that decisions are made. We start with the assumption that the market is moving faster than we can. If this is true, then anything that delays getting a product to market has a huge cost associated with it. This cost is measured in employee hours, loss of customer faith, and competition gaining market shares before us.

The second tenant is that we are going to make mistakes. We are human, and therefore it is impossible to be correct all the time. If we are going to make mistakes, then let’s minimize those mistakes. We want to release small pieces of functionality often so that we can get feedback quickly. We can use this feedback to find mistakes before they are big and costly.

The third tenant is that the market will move with the introduction of product. Once the customer gets any functionality that is useful to them, that functionality will change what they want from future functionality. We have to be able to sense and move with that change.

This brings us full circle. The market is going to change faster than we can.

#NoEstimates is a way of doing business that attempts to accept these three tenants, while ethically helping companies navigate the new landscape of business. We do this by making business decisions in real-time and trying experiments in the marketplace to determine real value. We make decisions based on evidence instead of estimates.