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

What is Velocity? (in agile software development)

Velocity is a term used in agile software development to illustrate the "rate of progress" for a team or a set of teams (i.e. a project/program).

The simplest way to define velocity is: the number or user stories a team/project can do in one sprint ("do" here means that it really is done and potentially ready to ship).

Without the use of velocity you would not be able to draw your teams's burndown, as velocity is the slope of the burndown curve, i.e. how fast are you burning down the stories (or story points or hours) that you committed to for the ongoing sprint.
At a project/progam level, velocity is the rate at which the whole project is burning the User Stories (or requirements) from the backlog.

Also, without knowing your team/project's velocity you can not make longer term planning (over 1 sprint) or even release planning. Hence the importance of knowing your velocity!

In the first 1 or 2 sprints that you run, you will have to estimate your team/project's velocity as you don't have enough data to project your past performance into the future. However, after 3-4 sprints you should start using an average of your past velocity to plan the future and update the release plan.

Note that velocity is a range, not an exact number. For example, if you have developed 2, 5 and 4 stories respectively in your past 3 sprints, then you know that your velocity is 2-5, not 3 or 4. This range will allow you to communicate your best case scenario and your worst case scenario to your stakeholders instead of committing to one single number that is most likely wrong. Always use velocity as a range when communicating outside your team.

In short, velocity is how fast you are developing your software.

Some more resources:
An extensive example and definition of velocity.
A simple definition of velocity:
The mathematical definition of velocity (from Physics).

My thinking on velocity and Agile Estimation has evolved

If you want to know what I have learned since I wrote this article, check out my #NoEstimates white paper and the following articles:

• Simple estimation techniques work! Use the data you already have
• Story Points considered harmful, or why the future of estimation is really in our past
• A better way to predict project release date
• Focus on what matters, a #NoEstimates advocacy post
• The #NoEstimates how to