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

Picture credit: John Hammink, follow him on twitter

11 thoughts on “What is Capacity in software development? – The #NoEstimates journey

  1. Yes, capacity for work can be measured from past performance. Question is, is that capacity open to improvement? What should it be, what could it be. What it is, is only one of three assessments processes in any improvement plan.

  2. How is this #NoEstimates? Is it because all stories are counted as 1 without being estimated? If so, then do you also encourage all stories to be as similarly sized as possible?

  3. Great post, thanks! But capacity alone does not answer the question at the beginning of your post: What can be done by a certain date / within a certain budget? To answer this, we need to have an idea of how much work there is ahead of us. And there it gets tricky.

    Counting user stories for forecasting, as you suggest, brings its own problems: The forecast is implicitly based on an average size of past user stories. You assume that this is the same for future stories – Which is probably a good guess – But a guess nevertheless.

    Also, you need to break down future work to small user stories, at least for the forecasting period. But we don’t want to break down stories that are in the future because this is possible waste. So we need two categories of stories: Large and small. We are moving closer to story points…

    Even the projection of future capacity is just an educated guess.

    So, as long as you try to answer the question in the beginning, can we finish by X, there will be guessing and estiating, whether you do it explicitly or implicitly. Maybe we should instead find ways of working where the answer to this question is not that important…

  4. That series of numbers has nearly a 100% variance from the mean. It’s be pretty sporty in a larger project to forecast future performance with a confidence varying 100% from the mean, without finding out what the root cause was of the variance.
    Imaging getting a quote for a car. “Vasco, the price will be €10,000 ± €5,000? !

  5. @Glen
    Can capacity be improved? Sure, but can you “bet” on that improvement?
    Using a simple heuristic (update your projection once you need to) is enough for most cases.
    Where it is not, then a lot of effort should be spent with the project team figuring out what are the constraints, etc. (Theory of Constraints).

    RE: variance: The data on the graph is from one project only, and it is for *weekly* delivery. The variance is smaller if you take larger timeframe. However, the variance was not an obstacle for this team to predictably project when certain parts of the product would be ready. And this was the key question for them.

  6. @David
    It is rather simple to know “how much work is ahead us”, also, you can define that variable.
    It is not required that you estimates (or break-down) future work up front, but it does require you to update your forecast all the time.

    Re: future capacity. You can guess it (not addvisable) or you can assume that it will be similar to what you have now.

    “When will X be done?” If we care about that question, there’s a much easier answer: “do it now, check back soon” 🙂 However, when we are talking about a project we can’t really do that because the project content will change during the project (including content and priorities). So the question is still valid when you talk about more than 1 single feature/story.

  7. It’s not the distribution that is the issue. Although “normal” is rarely ever the case in software work efforts nor is Weibull, since that is a failure mode distribution. Triangle is best when nothing is known.
    But testing those samples for their population distribution would tell you no much.

    The STDev is 100% of the Mean. Those kinds of numbers are pretty much meaningless in forecasting future performance anywhere I work, where we do statistical forecasting of the future.

  8. @Glen

    Re: distribution. As stated in the blog post. I’m not trying to create scientific model for forecasting. I’m trying to create an engineering model for forecasting.

    It is precisely the fixation on “the perfect mathematical model” that has led the software industry into the mistaken idea that improving “the tool” (estimation) is the solution. When in fact the solution is to change tools. To discard the old tool of estimation (PERT, GANTT, Buffers, 100% decomposition, etc.) and focus on a new tool: using data you already have for a end-to-end process (not the intermediate steps) and forecasting the longer term on a rolling wave basis.

    You say that STDEV is 100%, but conveniently forget to state that the average of the first 3 sprints gives you a 87% accuracy on the forecast for the remaining 18 sprints! Not to mention that with every sprint your forecast gets better.

    87% accuracy after completing 16% of the project is pretty darn good, and much better than what scholars such as S.D. Conte, H.E. Dunsmore and V.Y. Shen consider “good estimation”: being within 25% of actuals 75% of the time.

    Although you have a statistical point (as I conceded in the post), the practical application is far better than what is out there. But I have hope someone will improve further on what I propose – in a practical way.

  9. Hi Vasco. At pmo/program/product/org level the trouble is mainly caused by the things not done because we didn’t know, things done but not really needed, assumptions that change etc. How does your approach scale beyond the team? Br, Morten

    Morten Elvang

    Agile in a day? (Im)possible! Check out the #AgileSpark concept – as.42stc.com

Comments are closed.