Capacity Planning

Capacity Planning is a process whereby an organisation comes together to agree on what they are going to focus on in the medium term. There are two outputs from the Capacity Planning process:

1. An ordered backlog of initiatives (MVDs) that the entire organisation agrees on.
2. A list of the constraints and options within the organisation.

The Capacity Planning does NOT produce a plan or schedule of work.

The purpose of Capacity Planning is to provide the organisation with focus. To agree a backlog based on the constraints that exist within the organisation. Rather than determine the capacity of the organisation based on its headcount, the capacity is based on the capacity of each group within the organisation.
Without an organisational backlog, there is a very real chance that the organisation will end up with too much work in progress because each group will seek to develop their own locally optimised priority.


The start of the process is to create a roughly ordered list of Minimum Viable Deliveries (MVDs*). This provisional list is then pruned to create a list that is probably about twice the size of the eventual backlog. I call this a list of unicorn horns as it little to do with reality.

The groups are the set of Scrum Teams that look after a particular system, service, component or function within the organisation. In fact, any potentially limited resource that needs to participate in the delivery of an MVD.

The (product) owner of each MVD then engages with the product owners working with the groups. The groups create an Epic for each MVD they need to contribute to, and provide a SWAG, a Sweet Wild Assed Guess. The minimum effort required is that the group’s product owner makes up a SWAG. It would be too much to involve the team in a story point style estimate (even if bulk estimation is used) as they are only needed to help order the backlog and identify constraints. They are not a commitment by the team. The units for a SWAG are team weeks, the work that a single “Scrum” team can do in a week. One of the main reasons for the SWAG is to ensure that there is engagement between the MVP Owner and the Group’s Product Owners, To ensure that the groups are aware of any work that may be required of them in the medium term.

You will probably want control reports to help product owners spot any gaps.

Each group calculates its available capacity. The default is the number of weeks in the period multiplied by number of the “Scrum” teams in group, multiplied by 50%. The 50% is based on the work of Todd Little.

<strong>Capacity Planning</strong>

Capacity Planning should involve all key decision makers. If any are missing they may go outside the process to get their MVD done.

Now that you have the ordered list of MVDs, you go through them in order. For each MVD, you check to see if there is enough Capacity in each of the groups to deliver all of the Epics in the MVD. If there is enough capacity, the MVD is included in the backlog and the remaining Capacity of the groups is reduced by the amount on the Epics. Whenever the Capacity of a group becomes zero, the group is identified as a constraint. If there is not enough capacity in one or more of the groups, then the following can be done:
1. The decision makers decides to deselect one of the MVDs that has already been selected in order to free up the capacity.
2. The MVD can be reduced in scope. Theoretically it should be impossible to reduce something that is minimal but given the choice between nothing and something, the MVP Owner will find a way to shave some functionality off.
3. The MVP Owner and Group Owner can defer the decision to reject the MVD by looking for additional Capacity.

Eventually, it will not be possible to do any further MVDs as they all rely on groups that have run out of Capacity.

You will find that about 20% of the groups will be constraints, having used all of their capacity. About 60% will have some work on the Corporate Backlog, and 20% of groups will have no work on the Corporate Backlog. This list is gold dust for the IT management team.

How the spare capacity is allocated will be the subject of a subsequent blog post.

You now have a backlog agreed by all the key decision makers, and the list of constraints in the organisation. You have done step one and two of Theory of Constraints, namely Identify the constraint, and prioritise the constraint. The rest is easy from here on in.

* I have deliberately avoided defining an MVD. Its the smallest piece of work to deliver value.

About theitriskmanager

Currently an “engineering performance coach” because “transformation” and “Agile” are now toxic. In the past, “Transformation lead”, “Agile Coach”, “Programme Manager”, “Project Manager”, “Business Analyst”, and “Developer”. Did some stuff with the Agile Community. Put the “Given” into “Given-When-Then”. Discovered “Real Options” View all posts by theitriskmanager

7 responses to “Capacity Planning

  • KentMcDonald

    Thanks for this description. A couple of thoughts.
    1) Any reason for the choice of MVP Owner shepherding MVD?
    2) An example would be helpful right about now.

    • theitriskmanager

      Hi Kent

      Thank you for the thoughtful questions.

      1. I might have misunderstood the intend of the first question. The MVD (Could easily be called an MVP or BVI – Business Value Increment ) should have an owner and a “Scrum Master”. The owner is the guardian of the value delivered by the MVD. As such, they decide whether any reduction in scope will impact the value delivered and make the trade off. As we go through the development process, we always identify opportunities to reduce scope. The MVD owner should be on the look out for these opportunities and take them when they can. However some scope reductions destroy the value completely and should not be allowed. Hopefully we all know lots of examples of these types of trade off.
      2. This is one of those great ninja like questions. Looks simple but hides a host of depth. Thank you. The easiest way to think about examples of MVD is to consider the Cynefin Framework. If the problem is in the ordered domains ( Obvious or Complicated ), then the MVD would be an identified piece of work. e.g. Looking at our take on process, 75% of people drop off on the blah page whilst waiting ten seconds for it to respond. From the analysis we have done, the drop off rate increases dramatically after 3 seconds response time. We invest to ensure the response time is less than 3 seconds. We have identified the changes necessary to do this. The MVD is to do the identified changes to improve the performance for the page. We should have a good idea how it will impact sign-ups.
      If the problem is in the Complex domain, the MVD may consist of several safe to fail experiments to identify a good solution to the problem. e.g. On another page, the drop off rate is higher than we would expect. We identify several different designs to potentially improve sign up by making it easier, and one that is opposite to the others such as one that makes the page harder to understand. (which activates the Kahnmann system 2 function).
      In the Chaotic domain, we state the problem and get a number of independent teams (Wisdom of Crowds) to try and solve it. We bring them together on a regular basis to provide punctuated evolution (See Jabe Bloom talks). Even though we do not have a solution in mind, we can still allocate capacity to work on these itesm. It is an excellent use of the groups that have no work on the prioritised backlog.

      In each case, the MVD is a request for capacity in return for value, which may be in the form of information that resolves uncertainty (and moves a problem from chaos/complex to obvious/complicated).

      Does this answer your questions, or is did I miss the point?

      More questions like those would be much appreciated.


  • KentMcDonald

    Hi Chris,
    Thanks for the reply. I think you did misunderstand the intent of the first question, but that’s because I didn’t word it very well. You ended up applying much more meaning than was intended.

    I was actually being a little pedantic. I get and totally agree the need for someone to shepherd MVD’s, MVP’s, BVI, “Quanta of Value” or whatever you like to call those things, especially if they are getting parsed out to a variety of teams. I was actually curious whether there was a specific reason that you referred to the chunks of value as MVD (emphasis on the D) while the person who shepherds it is an MVP Owner (emphasis on the P). In other words, is there any reason you used D in one and P in the other? If you want to say there was deep implicit reason for doing it I’d buy it (but would be interested to know what it was) or, if it was a Brown M&M (

    As for #2, while real examples are always great, your answer none the less shed a lot of light on a related topic and helped cement a couple of thoughts that have been banging around in my head for a while now. The short version – you explained why Impact Mapping is helpful in a Complex, and perhaps a Chaotic situation, and potentially a waste of time in an obvious or complex one.


    • theitriskmanager

      Hi Kent
      It was not a brown M&M. In fact, it was a typo on my part. I generally use the term MVP and it slipped past my fingers instead of MVD.

      I specifically choose the term MVD because it is meaningless. Just a name I could use in the post. I’ve found that MVP, MMF etc have a whole load of baggage when it comes to using them so created MVD as a simple name with no baggage.

      My study of Cynefin has really helped in understanding where Impact Mapping is useful (Complex, Chaos) and where other approaches are needed, like Feature Injection (Complicated and Complex). For simple obvious, there is always ginger cake.

      An interesting observation is that user choice has a big impact on which domain you are in, In many enterprise software environments, the user has no choice as to the software they use and as a result, the domain is likely to be complicated. Understand the domain / process and write the software. When the user has choice, its about making the software more appealing that the competitor software or at least so that its no so bad they leave (A-B testing rules in the complex domain). Then the user has a choice as to whether they use the software at all. The realm of Games and Chaos. Wisdom of Crowds is needed. Hope this helps.

  • Knowing where to dig. | The IT Risk Manager

    […] Quarterly Capacity Planning – Identify those groups who are a constraint to the organisation. […]

  • Scaling the Product Owner. | The IT Risk Manager

    […] In this situation, we decided to use the “theory of constraints” to find the constraints and create an organisational backlog. We were no longer following a recipe, instead we were having to experiment like Chef’s do. […]

  • Scaled Agile for Practitioners – The Epic | The IT Risk Manager

    […] need to limit work in progress for each team using a technique like capacity planning. This means (SWAG) estimates need to be held against each team within an […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: