Tag Archives: No Estimates

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

Why I believe in #NoEstimates

Before I start, as I will be talking about different work experiences, I need to state all my opinions are my own. They do not represent the opinions of my current or past employers.

That being said now let me begin.

What:

When I was first introduced to the concept of #NoEstimates I was a mid-level developer and thought that it was a wacky idea that could never work. Later, still a mid-level developer, I decided that working with estimates was stupid. Then I grew up and learned that the world was not black and white. I listened to what @WoodyZuill had to say and tried to understand the meaning.

Experimentation:

My first experiences with trying #NoEstimates had nothing to do with Woody. I worked in a small company that hired me to take over a legacy VB.Net v1 project which had failed so badly they fired the whole team. They had no source control despite having 13 versions of the application deployed, and only one copy of official source code that didn’t match any of the deployed versions. I hired a new team, we focused on bug fixes that were discreet, understandable and easily repeatable.

We gave no promises and made #NoEstimates. We focused on discovering value, by giving users fixes to things that were easily understandable. Within 3 months not only did we have source control, but we managed to reduce the number of variant applications and we were deploying every week. We had moved beyond bug fixes.

We were so successful, that the company sold in under 2 years. The CEO was able to retire, based on the value we delivered. We did this entirely without estimates.

Tutelage:

Later, I got to experience #NoEstimates in a completely different way. The team I was part of worked on custom line of business applications. We often produced software for different departments within the company. Here we focused on changing discussions that were given to us. We always asked: what is one thing that if we gave it to you now would make your life better? Then we tried to understand that enough to figure out something that is discrete, understandable and has a clear definition.

Once we did that, we would work to deliver it. Once it was delivered, we would follow up with the users to see that it met their need. If it didn’t we changed it. When the need was met correctly, we were told what the next need was.

That is how we worked. The company never had worry about interrupting us, because our deliverables ended up taking less than a couple of days on average. This was not a precondition, or intentional. It happened because of how we isolated something to work on. Occasionally it would take significantly longer. That was ok also because it meant that there were more unknowns in that piece.

 

So What:

#NoEstimates as I have witnessed it accomplishes two things. The first is it moves authority to make business decisions to the current point in time. By delaying the act of what has priority, to the last responsible minute the business is better able to cope with business as it is.

The second benefit is that it places business decisions in the hands of those who have the knowledge to make the decision. I always say that programmers are business people who have not been correctly trained in business. I say that because every line of code is a decision about how the company does business. By focusing on discrete deliverable chunks and using those chunks to measure value/need, a lot more of the decision of what goes into the application goes to those who are responsible for the business.

 

Now What:

#NoEstimates is the beginning, not the answer. There is a lot more exploration that can happen out there. Let’s focus on improving how we do business, and share our successes and failures. Eventually we will always find better.