Agile Resource & Capacity Planning

The Scrum framework was designed to enable small, self-sufficient teams deliver rapidly and with quality. When applying this framework in an Enterprise, it is important to maintain a few of the characteristics of this small-team mentality to enable Agile teams to be successful in a much more complex environment

Projects can be big, but Scrum Teams should still be small

Estimates of the “ideal” team size in Agile range from around 5 to 10 team members. Various sources cite different information as to why this is the case, and that number may or may not account for a Product Owner and Scrum Master. The bottom line is that Agile team sizes should be kept small, but have all of the skillsets they need to deliver. This includes: Product Ownership, Scrum Master, Development, Testing, Infrastructure, Data, or any other project needs. Usually, this will result in a team size of about 7ish people.

But what about those projects that are large and will require many, many people to deliver? Say, a massive marketing campaign with a web-based foundation, or a new content management system for an enterprise? The answer to this is to Scale your Agile delivery team. This can be easily accomplished using a concept called Scrum-of-Scrums.

In a Scrum-of-Scrums model, the entire delivery team is organized into sub-teams, or individual Scrums. These Scrums are each responsible for their own part of the delivery, and an overall Product Ownership and Delivery management framework is set up to provide oversight to the project as a whole. This can be visualized in an example like the following:

Illustration: Scale Up Agile Team Structure (Scrum-of-Scrums)

In this model, the delivery team is organized as follows:

A Business/Product Ownership team, which could consist of a Chief Product Owner (who will own the overall solution), and individual Product Owners (each of whom will act as Product Owner for a team and oversee their particular area of expertise). This team will regularly meet to prioritize the scope of the overall solution and align Release and Sprint Planning
A Scrum/Delivery Management team, which could consist of a Program/Project Manager (responsible for financials, timelines, contract delivery, etc.), a Chief Scrum Master (responsible for overall solution delivery through Agile), and individual Scrum Masters (each of whom would act as Scrum Master for a team). This group would regularly meet to discuss delivery status, impediments, and potential changes that would be needed to help the team deliver in alignment with the overall project needs & schedule.
4 Delivery Scrum Teams, consisting of a Product Owner (from the Product Ownership Team), a Scrum Master (from the Scrum Delivery team), and the Agile team members to deliver that portion of the solution. This team would organize itself according to the Scrum framework and conduct the Agile Ceremonies outlined below

Representatives from EACH TEAM then will together conduct a Scrum-of-Scrums meeting, which mirrors the Scrum team’s Daily standup. I n this meeting, they will report on what their team delivered since the previous meeting, what their team is currently working on, and bringing any impediments, risks, or issues that impact the overall solution to bear, in order to get the assistance of the delivery leadership or business leadership.

Scrum is built for whole people, not percentages of resources

The Scrum framework is a daily work cycle, embedded in a 2-4 week time box, embedded in an overall delivery methodology. Because it is built around daily work and around rapid, frequent iterations, progress, and status, it is very difficult for people staffed across several projects at once to be effective and give an Agile team what it needs to move forward rapidly.

As such, Agile projects are most successful when they are able to allocate whole people to Agile teams. The Scrum model assumes each person is 100% dedicated to all and only his or her team’s activities, and operates most rapidly (i.e. higher velocity) when that is possible. Thus, when planning for an Agile team or person’s capacity dedicated to the project, it is best to get it as close to 100% as possible.

It is understood that in an enterprise environment, there are cases when whole people cannot be allocated. In these cases, it is critically important that Agile teams identify, document, and plan for the dependencies that can result from non-dedicated resources For example, if all infrastructure resources are in a shared-services model, the team must plan in advance for the lag time that will be necessary to procure the hardware they need, etc. The best guidance is to have agile teams plan to NOT START work on a particular feature/system until the team/person they are dependent upon for that work has delivered what the team needs. They should do other work in the interim

For the First Sprint, estimate based on Capacity (to determine target velocity). Once a team delivers, use historical velocity

Velocity is the measure of how much stuff a team is able to deliver. That begs the question: How do you plan for a velocity in the first iteration, if the team does not have any delivery experience?

To do this, a team should look at its backlog and select enough stories that are deemed Ready to try to “fill” a Sprint (see Definition of Ready in later sections) and try to have the team decompose them into development tasks with ideal hour estimates (see detailed Task Decomposition steps below).

For a team’s first Sprints, it should be assumed that a Team’s Agile Delivery Capacity will be 50-60% of their schedule hours (or less) as they get used to the Agile framework. For example, if a team has 5 people working 8 hour days, and a Sprint is 10 working days, the teams scheduled work hours will be 400 hours for the Sprint. Applying our percentage in this scenario, this means we can plan that the team will be able to deliver 200-240 ideal hours of backlog scope, the remainder of their scheduled time being spent on the Agile ceremonies, fixing bugs, setting up environments, etc.

Using this approach, the team should be able to tally the total story points that it takes to get the team to a “full” first sprint, and this can become the team’s first Target Velocity. This can also then be used to project the delivery of the rest of the backlog in a Solution Roadmap (see below). Once a team then has a delivery history, that projection should be updated based on the team’s true average delivery velocity, to see if it is in line with the original plan. REMEMBER: in agile, it is ok for a plan to change. Thus it is important that a proper contingency be planned during project initiation. Usually, this can be 1-2 additional Sprints for every 5 or so planned Sprints.