What is an Estimate?

If you don’t know what an estimate is, you can’t avoid using them. So here’s my attempt to define what is an estimate.
The "estimates" that I'm concerned about are those that can easily (by omission, incompetence or malice) be turned into commitments. I believe Software Development is better seen as a discovery process (even simple software projects). In this context, commitments remove options and force the teams/companies to follow a plan instead of responding to change.

Here's my definition: "Estimates, in the context of #NoEstimates, are all estimates that can be (on purpose, or by accident) turned into a commitment regarding project work that is not being worked on at the moment when the estimate is made."

The principles behind this definition of an estimate

In this definition I have the following principles in mind:

• Delay commitment, create options: When we commit to a particular solution up front we forego possible other solutions and, as a consequence we will make the plan harder to change. Each solution comes with explicit and implicit assumptions about what we will tackle in the future, therefore I prefer to commit only to what is needed in order to validate or deliver value to the customer now. This way, I keep my options open regarding the future.
• Responding to change over following a plan: Following a plan is easy and comforting, especially when plans are detailed and very clear: good plans. That’s why we create plans in the first place! But being easy does not make it right. Sooner or later we are surprised by events we could not predict and are no longer compatible with the plan we created upfront. Estimation up front makes it harder for us to change the plan because as we define the plan in detail, we commit ourselves to following it, mentally and emotionally.
• Collaboration over contract negotiation: Perhaps one of the most important Agile principles. Even when you spend time and invest time in creating a “perfect” contract there will be situations you cannot foresee. What do you do then? Hopefully by then you’ve established a relationship of trust with the other party. In that case, a simple conversation to review options and chose the best path will be enough. Estimation locks us down and tends to put people on the defensive when things don’t happen as planned. Leaving the estimation open and relying on incremental development with constant focus on validating the value delivered will help both parties come to an agreement when things don’t go as planned. Thereby focusing on collaboration instead of justifying why an estimated release date was missed.

  Here are some examples that fit the definition of Estimates that I outlined above:

• An estimate of time/duration for work that is several days, weeks or months in the future.
• An estimate of value that is not part of an experiment (the longer the time-frame the more of a problem it is).
• A long term estimate of time and/or value that we can only validate after that long term is over.

How do you define Estimates in your work? Are you still doing estimates that fit the definition above? What is making it hard to stop doing such estimates? Share below in the comments what you think of this definition and how you would improve it.

This definition of an estimate was sent to the #NoEstimates mailing list a few weeks ago. If you want to receive exclusive content about #NoEstimates just sign up below. You will receive a regular email on the topic of #NoEstimates as Agile Software Development.

Subscribe to our mailing list

* indicates required

Email Address *

First Name

Last Name

Picture credit: Pascal @ Flickr

What is Capacity in software development? - The #NoEstimates journey

I hear this a lot in the #NoEstimates discussion: you must estimate to know what you can deliver for a certain price, time or effort.

Actually, you don’t. There’s a different way to look at your organization and your project. Organizations and projects have an inherent capacity, that capacity is a result of many different variables - not all can be predicted. Although you can add more people to a team, you don’t actually know what the impact of that addition will be until you have some data. Estimating the impact is not going to help you, if we are to believe the track record of the software industry.

So, for me the recipe to avoid estimates is very simple: Just do it, measure it and react. Inspect and adapt - not a very new idea, but still not applied enough.

Let’s make it practical. How many of these stories or features is my team or project going to deliver in the next month? Before you can answer that question, you must find out how many stories or features your team or project has delivered in the past.

Look at this example.

How many stories is this team going to deliver in the next 10 sprints? The answer to this question is the concept of capacity (aka Process Capability). Every team, project or organization has an inherent capacity. Your job is to learn what that capacity is and limit the work to capacity! (Credit to Mary Poppendieck (PDF, slide 15) for this quote).

Why is limiting work to capacity important? That’s a topic for another post, but suffice it to say that adding more work than the available capacity, causes many stressful moments and sleepless nights; while having less work than capacity might get you and a few more people fired.

My advice is this: learn what the capacity of your project or team is. Only then you will be able to deliver reliably, and with quality the software you are expected to deliver.

How to determine capacity?

Determining the capacity of capability of a team, organization or project is relatively simple. Here's how

• 1- Collect the data you have already:
  • If using timeboxes, collect the stories or features delivered(*) in each timebox
  • If using Kanban/flow, collect the stories or features delivered(*) in each week or period of 2 weeks depending on the length of the release/project
• 2- Plot a graph with the number of stories delivered for the past N iterations, to determine if your System of Development (slideshare) is stable
• 3- Determine the process capability by calculating the upper (average + 1*sigma) and the lower limits(average - 1*sigma) of variability

At this point you know what your team, organization or process is likely to deliver in the future. However, the capacity can change over time. This means you should regularly review the data you have and determine (see slideshare above) if you should update the capacity limits as in step 3 above.

(*): by "delivered" I mean something similar to what Scrum calls "Done". Something that is ready to go into production, even if the actual production release is done later. In my language delivered means: it has been tested and accepted in a production-like environment.

Note for the statisticians in the audience: Yes, I know that I am assuming a normal distribution of delivered items per unit of time. And yes, I know that the Weibull distribution is a more likely candidate. That's ok, this is an approximation that has value, i.e. gives us enough information to make decisions.

You can receive exclusive content (not available on the blog) on the topic of #NoEstimates, just subscribe to the #NoEstimates mailing list below. As a bonus you will get my #NoEstimates whitepaper, where I review the background and reasons for using #NoEstimates

Subscribe to our mailing list

* indicates required

Email Address *

First Name

Last Name

Picture credit: John Hammink, follow him on twitter

Coming out of the closet - the life and adventure of a traditional project manager turned Agilist

I’m coming out of the closet today. No, not that closet. Another closet, the tabu closet in the Agile community. Yes, I was (and to a point still am) a control freak, traditional, command and control project manager. Yes, that’s right you read it correctly. Here’s why this is important: in 2003 when I first started to consider Agile in any shape or form I was a strong believer of the Church of Order. I did all the rites of passage, I did my Gantt charts, my PERT charts, my EVM-charts and, of course, my certification.

I was certified Project Manager by IPMA, the European cousin of PMI.

I too was a control freak, order junkie, command and control project manager. And I've been clean for 9 years and 154 days.

Why did I turn to Agile? No, it wasn’t because I was a failed project manager, just ask anyone who worked with me then. It was the opposite reason. I was a very successful project manager, and that success made me believe I was right. That I had the recipe. After all, I had been successful for many years already at that point.

I was so convinced I was right, that I decided to run our first Agile project. A pilot project that was designed to test Agile - to show how Agile fails miserably (I thought, at that time). So I decided to do the project by the book. I read the book and went to work.

I was so convinced I was right that I wanted to prove Agile was wrong. Turned out, I was wrong.

The project was a success... I swear, I did not see that coming! After that project I could never look back. I found - NO! - I experienced a better way to develop software that spoiled me forever. I could no longer look back to my past as a traditional project manager and continue to believe the things I believed then. I saw a new land, and I knew I was meant to continue my journey in that land. Agile was my new land.

Many of you have probably experienced a similar journey. Maybe it was with Test-Driven Development, or maybe it was with Acceptance Testing, or even Lean Startup. All these methods have one thing in common: they represent a change in context for software development. This means: they fundamentally change the assumptions on which the previous methods were based. They were, in our little software development world a paradigm shift.

Test-driven development, acceptance testing, lean startup are methods that fundamentally change the assumptions on which the previous software development methods were based.

NoEstimates is just another approach that challenges basic assumptions of how we work in software development. It wasn’t the first, it will not be the last, but it is a paradigm shift. I know this because I’ve used traditional, Agile with estimation, and Agile with #NoEstimates approaches to project management and software delivery.

A world premier?

That’s why me and Woody Zuill will be hosting the first ever (unless someone jumps the gun ;) #NoEstimates public workshop in the world. It will happen in Finland, of course, because that’s the country most likely to change the world of software development. A country of only five million people yet with a huge track record of innovation: The first ever mobile phone throwing world championship was created in Finland. The first ever wife-carrying world championship was created in Finland. The first ever swamp football championship was created in Finland. And my favourite: the Air Guitar World Championship is hosted in Finland.

#NoEstimates being such an exotic approach to software development it must, of course, have its first world-premier workshop in Finland as well! Me and Woody Zuill (his blog) will host a workshop on #NoEstimates on the week of October 20th in Helsinki. So whether you love it, or hate it you can meet us both in Helsinki!

In this workshop will cover topics such as:

• Decision making frameworks for projects that do not require estimates.
• Investment models for software projects that do not require estimates.
• Project management (risk management, scope management, progress reporting, etc.) approaches that do not require estimates.
• We will give you the tools and arguments you need to prove the value of #NoEstimates to your boss, and how to get started applying it right away.
• We will discuss where we see #NoEstimates going and what are the likely changes to software development that will come next. This is the future delivered to you!

Which of these topics interest you the most? What topics would you like us to cover in the workshop. Tell us now and you have a chance to affect the topics we will cover.

Contact us at vasco.duarte@oikosofy.com and tell us. We will reply to all emails, even flame bombs! :)

You can receive exclusive content (not available on the blog) on the topic of #NoEstimates, just subscribe to the #NoEstimates mailing list below. As a bonus you will get my #NoEstimates whitepaper, where I review the background and reasons for using #NoEstimates

Subscribe to our mailing list

* indicates required

Email Address *

First Name

Last Name

Picture credit: John Hammink, follow him on twitter

The most valuable question for your software project

Every time a software project is started, a dance starts: the dance of project approval. Decision makers and project delivery team take different positions at a table, some ask questions, others do their best to respond, given that these questions are typically about the future. Some of the questions are so much into the future that it would be foolish to pretend we know the answer. Yet we do.

This was the main lesson I learned in my life as a project manager: you have to learn how to dance.

How to dance...

In the dance-like meetings there are 3 types of people:

• A) Those that pretend to know the future
• B) Those that know they can't know the future
• C) And those that don't want to know the future

The question below is only valid for the people in category B). The other two categories are beyond help from me or anyone else.

What is the likelihood this project will fail?

When a project starts, the best question anyone can ask about the project is this:
The most important question: What is the likelihood this project will fail? Why is this question important?

• First, if you don't have an answer to this question you are either in the first or third category of those listed above, and there's nothing I (or anyone else) can do to help you.
• Second, by discussing the possibility of failure we are actively looking for possible causes of problems for the project (rule 1 of risk management).
• Third, having an actual conversation about the failure probability of a project will give you an indication of the "value at risk" for the project.

For example: let's say the project budget is about 100K dollar, and to make it a worthwhile investment we would need to make it between 120K and 90K in total cost (i.e. if it is likely it will cost more than 120K you should not do it). If the answer to the most important question is: 50/50, then you know that the project is not worth doing. It has very little chance of delivering the necessary value to justify it's existence, in fact: it is likely it will be above 100K and up to as much as 200K in cost.
However, if the answer is that we are 80% confident we will deliver the project on timecost, then the project is worth pursuing (although with some strict scope control in place) because the expected worst case scenario would be a total cost of 120K dollars (the 20% margin implicit in the confidence above). In practice an 80% confidence means you expect the project to cost up to 120K (100K + 20%) in the *worst* case.

In a later post I'll explain how we can answer this most important question using the #NoEstimates approach. For now, let me know what you think of the question and the concept of "value at risk" above.

Definition of Value-at-risk [PDF]: "value-at-risk summarizes the expected maximum loss (or worst loss) over a target horizon within a given confidence interval"

Note: A special thanks to @galleman for the idea of the 3 categories of people from which I derived the 3 categories I present in this post.

Photo credit: Steven Depolo @ flick

Using #NoEstimates when deciding which projects to take on

One of the questions (Part I, Part II) that emerged from the #NoEstimatesQuestions discussion on twitter was: “How do I choose between options or opportunities (without having estimates regarding the cost)?”

The thinking goes: I can spend some time doing A or B, but which should I do first? To answer this question we can look at it from two angles:

• 1) How much does A or B cost and how long to they take?
• 2) How much will I learn from doing A or doing B? Which knowledge is more important for me now?

The first point of view assumes that both A and B have similar value (or Return) and that the investment part (the I in ROI) is the most important factor. I happen to think that in software this is not the case. In my experience the R (Return in Return On Investment - ROI) is often more important than the Investment in defining the overall value of a certain decision. In my experience, the second approach will help you make a better decision when selecting between different options. Asking yourself "what is the value I expect to get from option A or option B?" is often a much more insightful discussion regarding the Business Model for your product or service. Here is how I would answer the question: “How do I choose between options of opportunities (without having estimates regarding cost)?”

• Step 1- Define what you expect from doing A and B. Example: A) If I implement “login in with facebook” I will expect to have more users to access the site due to the simpler registration. B) If I implement “invite a friend” I expect to have more visits to the site and ultimately more people registering than if I choose A.
• Step 2- Now, break the work down into risk-neutral chunks (i.e. chunks that don’t kill your project if you fail to reach the expected goal). This leads me to goal decomposition: given that I can’t test any of the options by tomorrow, is there something that I can test by tomorrow which would help me choose futher? Can I implement the “invite a friend” feature by tomorrow? Yes: great! lets do that. The reason is simple: by tomorrow I can start to test option B, if I had gone with Option A I would have to wait longer to be able to test my expectation.
• Step 3- Now it is time to get to work, deliver the smallest/easiest possible implementation of “invite a friend” by tomorrow, and review the impact of that feature. Once this functionality is live you can can either continue with B (if more changes are needed), or ask yourself what are the next options you need to decide on.

How to tackle Large Problems(™)

The example above will, rightfully, called a “simple” problem. So, the next question is: what if I have to decide between 2 Large Problems(tm), which can take several years of development and months of deployment? For example:

I work in the Ministry of Health and I need to decide between developing a large system to manage the health-care records of 10’s of millions of people, or maintain an existing system with potentially huge costs.

In this environment the Return part of the ROI equation is not easily accessible. In fact, one could argue that in this type of projects the I (or Investment/Cost) is the most important factor in making a decision. Most governments do that and spend considerable amounts of time estimating the costs of both options (with terrible consequences). #NoEstimates asks for a completely different approach to these problems (where cost is the key factor in deciding). In fact I would work to completely eliminate the “develop new system from scratch” option from the table. The reason is simple: we are terribly bad at estimating large software projects, so we should avoid them completely. Instead, we must use the flexibility of software to our advantage: start small and slowly grow the team as well as the final technical solution. How I would do it:

• Step 1- Determine what is the most operationally critical part of the system (e.g. by number of people assigned to work on that part of the system, or by contingency plan size -- don’t spend time estimating criticality, there is plenty information already available). Don’t start by changing this part of the system - it is far too critical (as you just determined). Select any other part of the system that you can change without any long-winded approval processes (random selection is ok, but you probably have a hunch).
• Step 2- With a small team (say 5-7 people) start a 1 week project to change this part of the system (a new version of the same software, including tests to ensure that the new implementation works as expected). Can’t do it in a week? Select a smaller part of that system component until you can. Don’t bother estimating, just ask the team until most agree it can be done. In parallel start listing, every day, other system components you will need to change next. Use the ideas in Step 1 to prioritize that list. By the end of week #1 you will have the first “changeable system component backlog” (don’t worry about the comprehensiveness of this list, you will update it every constantly).
• Step 3- By the end of week #1 you should have a small part of the system component re-implemented to the new standards (maybe a new technology? maybe a new privacy law?). Now ask, how many such components do you have to change to complete the project. 10? good, then it will take 10 weeks or so (don’t worry about being right, you will update your projections as you go)
• Step 4- Take the next part of the system and start another 1 week project. Later you may want to start more than one part of the project by adding one more team. But don’t add all teams at the same time

In this approach we try to achieve the following:

• Evolving understanding of the system in terms that can be used for data-driven progress projection (a- changeable system components backlog, b- how many system components can we change per week?)
• An evolutionary change to the system in a way that the system is always functional and the project - even if stopped prematurely - constantly delivers value to the owners of the system (in this case the taxpayer).

Conclusion

I’m sure that there are still quite many questions about the steps and approach I described here. Leave those questions below so that we can continue the dialog.