days
0
-8
hours
-1
-2
minutes
-5
-2
seconds
-5
-1
search
#NoEstimates

Another look at #NoEstimates in the Agile world

Tomas Rybing
Team image via Shutterstock

To wrap up our spotlight on Agile this week, Tomas Rybing is back with another look at the #NoEstimates movement and a review of the book that could propel the philosophy forward.

#NoEstimates is something I see and hear more and more about in the Agile world. Is it one of those buzzwords that will fade away, or is there a real movement behind it? I wasn’t sure; all I saw was a lot of tweets from people such as Woody Zuill (@WoodyZuill), Henrik Ebbeskog (@henebb) and Vasco Duarte (@duarte_vasco). One of those tweets caught my attention:

Here was an opportunity to end my curiosity about #NoEstimates, and maybe also make a small contribution as well. I couldn’t resist, so I signed up and got the first chapter and started to read. Since it is a beta and the scope of the book can change, this blog post will not be like one of my ordinary book reviews, but rather some thoughts about the book and #NoEstimates as such.

#NoEstimates – What is it all about?

The book starts with talking about the problem with estimates and why you shouldn’t plan and rely your business on them. This fact is sort of common knowledge in the business I would say, but no-one seems to be doing anything about it. Until now that is, with Vasco Duarte writing this book. After all, estimates are just guesses, sometimes they are educated (some type of work is behind the numbers) but nevertheless they’re still guesses. Maybe that’s why they’re also called guesstimates?

According to The Project Management Institute a project basically depends on three variables. They are:

  • Time – When the project can be delivered
  • Cost – How many people and other resources are working with the project
  • Scope – The content (features and functions etc) of the project

These three variables can be depicted in something that is called The Iron Triangle (but doesn’t it look an awful lot like a pyramid?)

irontriangle

A common IT project of today can look like this: ”In nine months we would like to have project X delivered to the cost of 1 Million USD”.

As a supplier of that project you have to make two hard commitments, in time (delivery date) and cost. The only thing left that can vary is the third valuable, namely scope (that you can control and manage). By doing so your project is ”value driven” instead of being ”scope driven” (where you can control time, i.e., delay the project or add more resources to it, which seldom works, thereby adding cost).

The #NoEstimates book is about how you can measure progress in a project, to be able to make forecasts (are we on or behind schedule) and take on an active management of the scope. You may think that the scope is also fixed, after all it has probably been agreed to in a requirement specification. But you can still work with the features and slice them to only deliver the functions that are of true value to the customer.

Content of the book

Since it’s a beta the content will most probably change in the released book, so I will only give a quick overview here.

noestimates_book_coverChapter 1
Talks about the problem with estimates and why they don’t work (Hofstadter’s Law & Parkinson’s Law).

Chapter 2
In this chapter an alternative to estimation is introduced, namely forecasting, i.e. when you predict the future but you do it based on collected data. An example:

  • ”Tomorrow I think it will rain”, that is an estimate (guess about the future)
  • ”Tomorrow it’s likely to be sunny since it has been sunny for the past two days”, this is a forecast based on previously collected data.

Chapter 3
This chapter rethinks estimates and questions why they are needed to control deadlines, costs and scope. It also talks about the necessity to prioritize your scope.

Chapter 4
This is a core chapter of the book. In it, we’re told how to measure progress in a project without doing estimates. It starts by working and managing the scope early on in a project, warning against doing it in the end (as is the norm when the project is running late). In the beginning you can question the scope, in the end all functions usually have dependencies to each other so you can’t take anything out, and your only option is to ”push as hard as you can” to deliver everything (at a later date). Concepts that are being introduced:

  • RTS (Running-Tested-Stories) – Progress in software development is measured by running, tested (high quality and user-accepted) software
  • Independent stories (called INVEST stories)

Chapter 5
Another key chapter, sort of the fast track to #NoEstimates. Now slicing of User Stories is explained and how you can use that to manage scope. The slicing can be done in different ”dimensions” (functional dependencies, acceptance criteria or time). Determining progress from historical data and how you use that to manage your project is also shown.

Chapter 6
The basic message here is to have fully transparent discussions with the customer about progress and managing the remaining scope, the latter being called flexible requirements management.

Chapter 7
This chapter completes the book by explaining rolling wave forecasting.

Summary

Now I totally understand the buzz about #NoEstimates in the Agile world! This is one of the biggest problems that our industry is facing today, and #NoEstimates provides ways to solve them.

SEE ALSO: The role of estimates in software development

But I have a tiny problem with the name as such. Why not call it something it really is? It’s not about not doing estimates – it’s about forecasting and active scope management! The name #NoEstimates can be controversial and provoking, and there is an initial value in that, but I can see a problem if this message goes beyond the early adopters and reaches out to the majority.

What do you think? Comments welcomed below.

This blog post originally appeared on The Agileist, Tomas Rybing’s blog about Lean, Agile and Management.

Author
Tomas Rybing
Tomas lives in Stockholm, Sweden and has been working in IT since 1996, starting as a consultant and programmer. From 2007 his focus has switched to team leading, project leading, product management and development methods. He's a big fan of penguins and pyramids.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of