Guest post by Jan Krüger on No Estimation

Jan Krüger provided this Guest Post. Jan is @j_hkrueger in Twitter.

Jan recently attended the Global Scrum Gathering in Berlin and held an Open Space session on No Estimation. and asked if I would post these notes.

Notes from the No Estimation Session at the Global Scrum Gathering in Berlin

Recently I attended the Global Scrum Gathering in Berlin.  On the last day there was “Open Space”.  Open Space is a meeting pattern for large groups who want to work on their own topics.  Anyone can contribute topics and conduct a half-hour session about it. My topic was “no estimation”. There was applause at the market place, and someone shouted “Good Luck!”.

IMG_0285

Fig: One of the mottos of “Open Space”

My thesis is:

  • Estimates are waste (defined as work which delivers no value)
  • Even worse, estimates are harmful because they build a bridge into the non-agile planning world and thus prevent the transition to an agile product development.

It doesn’t matter whether we estimate in story points, man days, euros or whatever, if we do magic risk surcharges, etc. These are workarounds to the planning fallacy. Some work better than others but an estimate is always an estimate. I take #noestimates literally. Simply don’t do it and see what happens.

The Open Space session was very enlightening for me (and hopefully for the other participants).

The first topic was the definition of “estimation” and if it were at all possible, not to estimate.

Somehow you always implicitly estimate, e.g. if you are planning a sprint, you will estimate what fits into it.

There was an interesting consensus of the participants: “All estimates are wrong”.

A Product Owner, who participated in the session, stated he needed to estimate to determine the benefit / cost ratio. By that he gets a kind of mini business case for every backlog item which allows him to prioritize.

Someone emphasized, estimation is great to foster communication about new stories.

One participant argued that the Scrum Guide requires the backlog items to be “estimated”. (That’s correct; it is written black on white)

Someone told from his team they hide the estimate in the story size by simply slicing all stories to the same size. (This is hardly #noestimates, if you take it literally as I do).

“All estimates are wrong”.

I can confirm that from my own observation. There is one saying that estimates are particularly difficult if they relate to the distant future – e.g. for release planning. In the Scrum team I serve it often happens that the PO asks for estimating an implementation detail to decide whether to build it or not (the mini-business case says hello). A short-term and easy to overlook estimate. Even with these I regularly hear afterwards, “that was more complex than I thought.” Even worse there are the many unknowns from peripheral systems, interfaces, sick leave, team coordination, individual performance, on-boarding, foreign activities and similar hardships of life.

Also you might ask yourself, what happens to the mini-business cases, if I underestimate the benefits and overestimate the effort? Will I possibly never build an important feature? What if I overestimate the benefit (which happens quite often)?

Let’s do a thought experiment: Estimating does not work. What would be the optimal strategy for steering software development? Why do we need the estimate? What is missing, if we can’t do it, how do we solve the problem otherwise?

Everything we build has a cost. As the team builds one item after the other, each item the PO prioritizes for implementation moves all the other items cost- and time-wise into the future. How far? No idea. We will have to act purely evidence-based. The only way to knowing what the item will cost and how long it will take, is to actually build it. Is this a risk? Yes it is, that’s why we need to slice to the smallest possible units that move us forward. Ideally, the items of highest value first. “Highest value” is uncertain – a hidden estimate? Absolutely, so we need evidence as soon as possible about the actual value of the items.

“Smallest possible” sounds like a size comparison. Is there always less effort in less functionality? In my experience, yes. Is there a hidden estimate? Maybe – at least it’s good to involve the DevTeam in the story slicing.  It also improves communication about new stories.

For our risk management, we need to define the “done” (and then comply). The popular “80% complete” is an estimate and these are always wrong.

As a software service provider it’s not our job to change our customer’s project management process. If the customer, however, decides to take the agile way of product development, we can support this transformation by stopping to estimate. It never worked anyway.

 

Neil Killick

Neil Killick has been an important part of the NoEstimates discussion for several years.  He has presented many conference and user meetup sessions and many are available on-line. I’ve watched all of his presentations that I’ve been able to find, and really appreciate his clarity and ability to keep the focus on making things better in the world of software development.

Neil has over 18 years of experience delivering software in various capacities. He’s a Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO) and Certified Scrum Professional/Practitioner (CSP).

Neil Killick Blog- neilkillick.com

Here is a link to his talk on Alternatives to Agile Estimation at Agile Australia

Also…

 

Vasco Duarte

I’ve really enjoyed my conversations and interactions with Vasco.  His vision and ideas have helped me a great deal in clarifying and expanding my thinking, and I recommend you follow him both in Twitter and at his blog.  Vasco has been sharing, talking, and presenting on the subject of “NoEstimates” and related topics for several years and has a deep understanding of the needs of software development management.  If you get a chance to see him presenting at a conference or user meet-up I’m sure you will find him interesting at the very least, and you could end up clarifying and expanding your thinking as well.

I highly recommend his blog: Software Development Today

He has many videos from conference presentations, and I’ve enjoyed them all.  Here is one you might want to take a look at:

Vasco Duarte at Agile Adria 2014: “How to improve estimates for software: The #NoEstimates view”

Call for links to NoEstimates content

Hello All –

I have a favor to ask.  I’d like your help to gather links to blog posts, presentations, videos (or whatever) that adds to the “No Estimates” conversation.

You can see examples of the sort of thing that I’m looking for by taking a look at the materials I point to on the “Links” page: Links Page

If you are exploring these ideas and have some materials or know of things you think I would be interested in, I would appreciate it if you would let me know by leaving me a note in the comments, or by Tweeting to me.

Thanks for your help!

NOTE:

I am not offering to address all (or any) of the objections to the idea of “No Estimates”.  That is for someone else to do.  I am interested in conversations, not arguments.

I am not offering to tell you how to “do” NoEstimates in your company.

I am not looking for information on “How to Estimate”, “How to Estimate Better”,   “How To Use Estimates To Get People To Talk About Things”, “Why We Must Estimate”, or anything of that sort.

I am not interested in opinions on “Why NoEstimates Doesn’t Work”.  If you have a blog you can write about that on your own blog, or you start a blog so you can write about that.

Cheers!

NoEstimates as a starting point

“#NoEstimates” is a hashtag I use in Twitter to connect up with like-minded people working in software development (business people, managers, developers, “stakeholders”) who are interested in exploring issues that seem to be related to estimates.  The hashtag itself is merely a hashtag. A way for interested folks to gather.

The power of the “#NoEstimates” hashtag to fulfill my goal to “connect up with like-minded people” has been phenomenal.  I haven’t counted the number of people I’ve been able to meet (both on-line or in person) but I’m pretty certain it is in the hundreds, and perhaps more than a thousand.

My intention here is to maintain this blog as a collection of articles, links to other resources like blogs, articles, videos, conference sessions, and whatever other things I find that are interesting to me in relation to “#NoEstimates”.

To me “No Estimates” is just a one possible starting point – it just happens to be one that has gotten a lot of attention.  There are many other possible starting points about things that could be better in the world of software development.  It is not my intention to cover those things here.  If they come up, I’ll try to point them out, but it isn’t my focus for this blog.

Overall, I think that working in the world of software development can be much better than what most people experience. I love programming software, and I love working with teams to create great projects that deliver a lot of value and usefulness.  In a larger sense, I want to work in an industry where people can excel at their work, and in their lives.  I think the software development industry can be that way.

Cheers!