Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

A quick trip to the future land of no estimates

Why do we estimate? What are the benefits we want to obtain with that practice? In this talk we'll explore the nature of estimates and offer an alternative: #NoEstimates. We'll look at some examples of how we can predict a release date of a project without any estimates, only relying on easily available data. Finally, we'll see how we can follow progress on a project at all times without having to rely on guesswork, and we will review how large, very large as well as small projects have already benefited from this in the past. At the end of the session you will be ready to start your own #NoEstimates journey, the next step in the #Agile journey.

We’ve been fighting accepted truths in the field of software development for many, many years.

We’ve been fighting accepted truths in the field of software development for many, many years.

Many of you are probably not old enough to remember the time when having a very long requirements phase was a must, and when non-incremental software development was the norm. First we had the phased waterfall, then we had to fight the idea that testing was something we did at the end of the project. Paper was where software was developed, do you remember that? Flow-diagrams, UML, etc.

Coding was considered a “lowly” profession, only for juniors. The real software developers used paper, and the cool boys were all over Rational Rose! Code generation was the keyword! This is a photo of an actual code-monkey (just pay them with bananas), but you don’t see many actual code monkeys out there. In fact, a little know fact is: most software developers are human as of today! (I just saw the latest statistics) But many people still look (even 20 years later) at developers as code monkeys.

Again, an old dictum. The Agile practitioners were called undisciplined, chaotic, lazy, idealists. You name it! For many Agile was untouchable, Agile was chaos.

It took our community many years to get Agile accepted as a “serious” way to develop software. And as we can see from this email screen-shot. It now *really* is main-stream, when even the old-farts at PMI think it is worth their attention (no doubt because they want some of that certification money groovy train)

Today, I stand in front of you as an advocate of the #NoEstimates approach to software development. #NoEstimates is just a minor Family in the Agile Species of software development approaches.

What have I observed? I’m also being labeled: incompetent, unaware of customer needs, undisciplined, idealist.

However, what I am proposing is a natural evolution for Agile (from my point of view). Simply, in my experience #NoEstimates is the natural way to implement two of the 4 Agile Values: Customer collaboration over Contract negotiation; Respond to change over following a plan.

Estimates enforce a plan, but what if you find a better way to develop that project? Should you stick to the old plan and be late (guaranteed!) or change your plan and make those estimates obsolete? Estimates marry you to a plan.

And how about discovering what is really important? When you estimate you assume a certain meaning and value for the stories or requirements you are developing. What if your understanding changes? Do you go back and discuss all the estimates again? Or do you just continue because we’ve already planned this in anyway? #NoEstimates is about focusing on what matters, what is the next most important thing to do? Instead of trying to guess at all the things we need to do *and* spending a lot of time trying to guess how long they will take to implement.

We started adopting Agile because we want to focus on what matters. Not on accessory, unnecessary work. Remember, BDUF was once considered essential and even critical for successful software projects. (some say it still is). As an advocate of #NoEstimats I feel like Christopher Columbus did. I know how to balance the egg, and once you experience the solution you too will understand how obvious it was. But no-one can see it before trying it.

“having been told that discovering the Americas was no great accomplishment”

Retrospective Coherence, my great nemesis (aka Common Sense)

These are rules I’ve developed over time based on the SPC rules based on the work by Deming and Shewart:

1- Velocity (in # of stories) falls outside the control limit more than 3 times in a row (”outside limits”) 2- There are 5 or more points in sequence (ascending or descending) (”Run test”)

- You could have a lot more rules and I encourage you to develop these rules for yourself based on your understanding of SPC and your knowledge of your system.

So, let’s take a look at some projects....

Let’s take a look at one example of how we can use #NoEstimates in a real project and what were the results...

Here are the questions that I started with...

Here are the questions that I started with...

Chaos report, 2004

It is far more likely for a project to be late, than to be on time (Parkison’s law)

“Work expands so as to fill the time available for its completion.”

I’ve seen the world from above. The Earth is really round. If we go west we will reach India! As Christopher Columbus did, I also know I’m wrong. But maybe in 500 years people will look back and understand why it is necessary to be wrong and experiment to evolve our industry and profession, not stick to what we know does not work well!

Agile is alive and kicking. Take #NoEstimates and experiment! Be Agile!

A quick trip to the future land of no estimates

1.
A quick
trip to
the
future
Vasco Duarte
@duarte_vasco

2.
#NoEstimates: how you can predict the
release date of your project without
estimating

35.
Click here!
Sign-up and get the paper today!
Sign-up and receive this paper which
explains why we need #NoEstimates
and how to get started!
Includes:
• Why estimates should not be used,
and how they fail
• An example of how #NoEstimates
can reach a 4% accuracy to actuals
• How to apply #NoEstimates:
Vasco’s recipe!