Organizing a software development team? Plan capacities better.

“Intelligence is the ability to adapt to change.” … Stephen Hawking

We all are working towards optimal approach in almost all the tasks in our life and getting intelligent enough to cater them efficiently. Agile is nothing but ability to move/change quickly and easily. Agile methodology is very simple and sticked to the basics of its dictionary definition. Every element of the entire methodology (be it iteration planning, capacity planning, story estimation etc) is designed so that anything can be changed or moved easily and quickly. Any change should be welcomed and even then it should not drastically affect the scope of product timeline.

This blog is about one of the crucial elements of agile methodology, i.e capacity planning.

Wikipedia says

Capacity planning is the process of determining the production capacity needed by an organization to meet changing demands for its products. In the context of capacity planning, design capacity is the maximum amount of work that an organization is capable of completing in a given period.

( Notice the word “changing” in the definition — close to agile, isn’t it ? )

At the start of every iteration, some typical steps are as below

1. Decide stories to be picked from product backlog
2. Determine size of stories in terms of story points (using https://en.wikipedia.org/wiki/Planning_poker)
3. Determining capacity of the team
4. Committing stories for the iteration depending upon the capacity for that iteration.
5. and finally we try to mark stories done at firm velocity to keep the burnout chart constant.

Capacity Planning

Capacity planning is ensuring that everyone on the team, particularly the specialists, have enough work for the entire iteration.

Capacity planning is one of the main elements of the agile software methodology. It helps the team to commit the story points for the given iteration and mark them as done within the stipulated time.

The wrong estimations for the story sizes lead to the failure of the iteration. Similarly wrong capacity planning leads to wrong commitments and hence very often the velocity of the team will be uncertain and unreliable.

Iteration Team members

Who are the members in your team?

Are they Generalists or specialists?

Managers tend to build teams having generalists, specialists or a mixture of both. Let’s start with a few key definitions:

Generalist — A versatile member with a wide array of knowledge and experience who can work on a number of interdisciplinary tasks.

Specialist — A person who has unique knowledge on the team relating to a particular job, area of study, etc.

People feel like more generalists in agile team is better, because it is better if you have flexibility to rebalance the work between the team at any time to meet the commitment for iteration. With more generalists on board, the rebalancing of work doesn’t affect the throughput for the iteration.

Note that here again the Agile terminology is followed very well — the plan is subjected to adapt change easily/quickly without affecting iteration throughput and we did that very well.

What if the teams find it hard to rebalance work?

This mostly happens with the team composed of specialists and to their relief the capacity planning helps them the most. Capacity planning gives insights to the capacity of the team (including generalists and specialists). So this helps us better manage the tasks among the team so that the specialists are utilized to the maximum for the commitment.

We will discuss some examples here.

Rock, Max and Emmet are generalists while Dawson(Python) and Jones are specialists

Scenario 1 — At about the end of the iteration, we get to know that Rock needs unplanned personal leave for rest of the iteration.

Solution — Any of the two generalists can be given the task of Rock and the throughput will not impact much as shown in the figure below.

The current estimate for Max has increased from the original estimate but Emmet has some bandwidth in the iteration. So the rebalancing is quite possible and agile.

Scenario 2 — While committing stories, every resource committed to the stories consuming their bandwidth for the iteration, while we have no python specific story lined up in the prioritized product backlog. Therefore python specialist resource is empty and not utilized.

Solution — Pick up stories which may not be prioritized for now but will be done in the near future and assign it to the specialists, this will perhaps make the specialists happy too.

How to do capacity planning?

We know the no of days in the iteration (15), team size (10), available hours (8) so this is simple

The capacity of the team is 15 * 10 * 8 = 1200 hours. right?

Wrong

This is just an abstract data not a very meaningful piece of information. This is just the available no. of hours in the office not the productive hours of the team.

All-time we spend at the office consists of many activities like in the image below

To be specific, we consider the following number of parameters to get the actual hands-on work for each team member

• Number of workdays available in a sprint
• Number of company holidays scheduled during the sprint time-box: If a company has 2 holidays during the sprint time-box, the number of workdays in that sprint will reduce by 2, which will also reduce the individual and team capacity.
• Personal vacation or paid time off for each team member: For example, if a team member is planning to take 3 vacation days in the upcoming sprint time-box, his capacity will reduce by 3 workdays (and the team capacity will reduce too by that amount).
• Full-time vs. Part-time membership on the team: If a team member is not a full-time member of the team, but is planning to work only 50% of the time on the project, his capacity will reduce by 50%.
• The time needed to prepare for and attend daily Scrum meetings.
• The time needed to do general e-mail and phone calls, and attend company or non-project meetings.
• Time set aside for contingency.
• Any factors that will reduce the capacity of a team member, such as:

- Support work for the previous release of software

- Preparing the backlog for the next sprint while the current sprint is going on

- Training new member of a team

- Self-training to increase cross-functional skills

Taking above-mentioned parameters into consideration, We can have three set of categories/buckets to pour in the bandwidth of the team.

Unplanned hours — These office hours are spent mostly on the unforeseen activities during the iteration. for example unplanned production/live issues, high priority unforeseen activity, unplanned meetings, unplanned but important bugs identified by the team itself, etc.

For each individual member, depending upon her vital role in the team, we allow her to provide the hours she thinks are unplanned during the course of an iteration. This may vary for a member in accordance with their experience and domain knowledge of the product.

Overhead — These office hours are spent on important tasks having an indirect relation to the iteration plan. For example Technical/product workshops, Story reading for next iteration, Organizational level meetings, etc. Similar to Unplanned hours individual members give their bandwidth spent on such tasks.

Planned hours — These office hours are the actual productive hours. We spend our time to mark the committed stories as done* in the iteration (considering part-time resources, personal vacations, company holidays, daily standup meetings etc).

*Definition of done — Analyzed, Developed, Tested, Verified, Delivered/Live.

Please have a look at the sample snapshot of the xls file, that we use to define team capacity for the iteration defining above buckets for an individual team member.

A glimpse of sample productivity hours of every team member

Hope this article helps you to plan capacity better and improve throughput. The only tip is to keep trying and keep improving.

“I am writing it to help you out, you should recommend it to help others out”

Hit the clap button to get more such articles and give your feedback in comments below.

Keep smiling and keep growing.