Capacity Planning for Dynamic Teams

Projects are often executed by dynamic teams. They start with a small core team and as the project gains momentum, add resources over time. This is commonly seen in IT service organizations that do fixed price projects. Fixed price projects have a defined scope that needs to be delivered within a contracted budget and within a negotiated timeline. For the purpose of this experience report, “Dynamic teams” or “Fixed Price projects” will be used interchangeably.

Unfortunately, as Ron Jeffries put it, “Agile is founded on the management of scope, not predicting when you’ll be done, even if you had fixed team size and “fixed” scope.”

Yet, a significant portion of the software development community does want to adopt some of the Agile/Lean principles that they believe they will benefit from. For example, they see value in making smaller and faster releases to their customers to get early feedback and de-risk their project. They see value in better team interactions that can motivate people to take greater ownership.

However, one of the key assumptions in Agile is about stable teams. Stability in teams is important, both from the perspective of size and composition. Stability helps achieve self-organizing teams. Stable teams make forecasting possible based on Throughput (or Velocity) of the team. If the team is not stable, one cannot use the current team’s Throughput as the basis for forecasting when the backlog and the work-in-progress(WIP) will be completed.

This makes it difficult to ask a very common management question in such projects: How many resources are needed to get the defined scope done within the negotiated timeline? Further, if there is Scope Creep, how does this impact the schedule or the resources plan? This Experience Report, based on the author’s experience in applying Agile/Lean principles to dynamic teams or fixed price projects, lays out an approach to answer these questions.

It must be highlighted that these questions and some of the approaches suggested seem contrary to well understood Agile thinking. For a true Agile practitioner, these are not the right questions to ask. However, these are questions that managements or customers will ask when they need a defined scope within budget and negotiated timeline; yet, adopt some of the Agile/Lean practices to benefit from the same.

Stages of Capacity Planning

Capacity planning is done across the project life cycle:

• At the beginning of the project when a Resource Plan is made.
• During execution of the project.
• As the project is executed, changes happen. Things don’t go fully as originally thought off, resource changes happen because of attrition or other business priorities, etc. This calls for a defined approach of how and when Capacity Planning should be done.
• Further, as the project is executed, Scope Creep happens. Agile teams are expected to welcome scope change. However, when one is executing a Fixed Price project, a re-assessment is needed to find out whether the committed timelines and budgets can be maintained with the allocated resources. If not, then a dialogue with the customer is needed to converge on the revised scope/budget/timeline.
• In this Experience Report, we will look at how to do Capacity Planning for each of the above situations. This report uses the Kanban tools to illustrate with examples. However, the same approach can be applied if one I executing a Fixed Price project using the SCRUM approach.
• Capacity Planning at Project Beginning
• Capacity Planning for a team at the beginning of the project is meant to address the key question – how many resources, and of what profile, do I need to deliver the defined scope in the given time? The method to answer this question does not change compared to how one would do it traditionally.

The approach is as follow:

Identify the EPICS. Decompose them to MMFs and User Stories.

Once the User Stories have identified, make a high level resource capacity plan based that details the skill profile needed for each of the User Stories. One can then aggregate it the capacity plan across user stories by skill profile. So, an example of an output from such a planning process would look like this.

Once a detailed plan is made, it can be aggregated across user stories by skill profile as follows:

Such a Resource Plan will give management the confidence to deliver the defined scope within budget and stated timeline. Once the project starts, things don’t always go as per plan. This is why Capacity Planning needs to be done regularly. In the next stage, we use the Kanban Method to show how this can be accomplished.

Capacity Planning during Project Execution

While an original plan is established, things start deviating from plan shortly thereafter. This is one of the reasons by many Agile practitioners discourage detailed planning (as illustrated above) in the first place.

Nevertheless, having established the need for the same in applying Agile/Lean methods to Dynamic teams, the next question to answer is – how and how often do we keep re-looking at this resource plan? We use the Kanban Method to answer this.

Below is a Board layout for the Backlog before cards get taken for Development. You will notice that this is split into 3 sub-lanes: a) Pending b) Next Priority c) Ready for Development. The Cycle Time for cards moving from “Next Priority” to “Development” should be around 1 month. The Cycle Time for cards moving from “Ready for Dev” to “Development” should be around 1 week.

 

In the next step, we use Explicit Policies to do Capacity Planning during Project Execution:

• For the “Pending” lane, define a policy that states “Before exit, validate resource demand for the card”. This implies that whenever a card is moved from “Pending” lane to the “Next Priority” lane, the team will re-visit the Capacity Plan for that card (as laid out in Step 1) and highlight the needed resources to the Project Manager. If resources are not available, then the card is Blocked and kept in the “Pending” lane. This approach highlights the team management of any potential resource constraints at least 1 month ahead of time.
• For the “Next Priority” lane, define a similar policy – “Before exit, validate resource demand for the card.” If resources are not available, Block the card. This approach helps identify any resource constraints due to last minute/unplanned events. It helps reduce the probability of cards getting stuck in development because of resource issues subsequently. This process would happen for each card whenever it is moved from one lane to next, often during Backlog Grooming.

A few additional points to be highlighted:

• Have a narrower WIP limit as you move from left to right within the Backlog stage. This will help in cards flowing to downstream lanes if some cards in the upstream lanes are blocked for resource constraints.
• When assessing the resource availability in the above stages, take into account the cards that are already in progress with their current Due Dates.
• Capacity Planning for Scope Creep
• When assessing the resource availability in the above stages, take into account the cards that are already in progress with their current Due Dates. Agile projects accept scope changes by continuous re-prioritization of the backlog. Teams continue to be undisturbed, even when Scope changes. That is not the expectation in projects that are executed in the fixed price environment. Scope changes are executed using the Change Control process. A Project Manager has to assess the impact of Scope Change on the already committed timeline and budget.
• Agile methods make this remarkably simple. If you are following the Kanban Method, the team already has the Throughput data. If the current Throughput is applied to the revised scope, the revised timeline can be easily determined. This is done with the Cumulative Flow Diagram (CFD). Let us understand this with the following example: The images below show a Board and it’s corresponding CFD diagram.

 

This CFD shows that for the team to complete the backlog, they need to complete the Value Stream at the 16.13 story points/day.

Now, let us consider a situation where because of Scope Creep, new cards have been added to the Backlog to the extent of 120 story points. These “new” cards are highlighted in red in the Backlog lane.

When CFD is plotted now, it shows the following data:

This shows that the desired Throughput to accomplish the revised scope within the same timeline increases from 16.13 story points/day to 18.09 story points/day, an increase of around 12%.

Once this is identified, the information can be shared with the stakeholders to discuss and evolve the best way forward. Resources could be added to the desired extent (subject to availability) or one could do scope substitution or a combination of both. Worst case, all stakeholders know that at the present Throughput, the revised scope will mean extending the timeline by 12%.

A similar exercise using traditional methods/tools would take an extended period of time. One needs to do a combination of resource loading and balancing, re-identifying the critical path, fast-tracking or crashing to shrink the critical path tasks before they can conclude on the impact to the overall project timeline and budget.

Summary

Capacity planning is a challenge for dynamic teams that want to adopt Agile/Lean practices. This Experience Report shows that the approach for building the initial Capacity Plan is unchanged whether the project is delivered using traditional or Agile/Lean methods. However, during project execution, using the team Throughput or Velocity, the Capacity Planning process becomes much simpler and accurate.