You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

Agile – Capacity Planning

0.00 avg. rating (0% score) - 0 votes
“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. To attain that intelligence we here at naukri use agile methodology. 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, we do some planning to
  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.
Rajendra, Mayank and Rohit are generalists while Arpit(Python) and himanshu are specialists
Scenario 1 – At about the end of the iteration, we get to know that Rajendra needs unplanned personal leave for rest of the iteration.

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

The current estimate for Max has increased from 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 near future and assign it to the specialists, this will make the specialists happy too.
 
How we do capacity planning?
We know the no of days in the iteration (10), team size (7), available hours (9) so this is simple
The capacity of the team is 10 * 7 * 9 = 630 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 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 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%.
  • Time needed to prepare for and attend daily Scrum meetings.
  • 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 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 think are unplanned during the course of iteration. This may vary for member in accordance to their experience and domain knowledge of the product.
 
Overhead – These office hours are spent on important tasks having 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 individual team member.
 
 
Hope this article helps you to plan capacity better and improve throughput.
 
Stay tuned for more articles on agile !
Posted in Agile