Event has already taken place!
Planning the Capacity means estimate and calculate the capacity of Agile team. There are two widely used capacity measurement units1. Story Points
This is Simple way to calculate the velocity (Average of last 6 to 10 Sprint’s Accepted Story Points). and target the upcoming Sprint to commit the User Story that closely match with the velocity.
I Personally recommend the other way of doing the capacity planning by calculate it by Hours.2. Hours
I personally recommend Capacity Planning by Hours. I will explain only on this way of Capacity Planning in this Article. Its gives better visibility and accuracy. And many other benefits that we will discuss later in this article.
Here we Calculate the available bandwidth of the Agile Team (except PO & SM). By calculate their available hours for the upcoming Sprint.
Will discuss in details about who to calculate it, what are Factors we should consider in this article.
The technique is very simple to calculate & plan your capacity. I have explained below the steps to calculate it manually. However in todays days all major popular ALM tools have that inbuilt, You just need to feed in the details.
At the end of this article will show example of doing Capacity Planning in one or two ALM tool.
I have explained below step by step you can follow to do your capacity planning, even if you are not using any ALM tool, just by maintaining an Excel.
Step 1 – Calculate Sprint Duration
Calculate the Sprint Duration in Days, Identify the Sprint Start Day and End Day. To explain this I have taken a 2 Week Sprint which Start on Wednesday and Ends on Tues day. And we are doing our Capacity Planning for Sprint 2.
The picture in the right Represent a 2 week Sprint – Calendar, of 10 days. Spread in three Physical Calendar Week. Through out the rest of the article, I will explain with this color legends , where
Yellow = Previous Sprint
Green = Current Sprint (for the Sprint we are doing the Capacity Planning)
Blue = Future Sprint.
Step 3 – Identify Allocation %
Now Identify the Shared resource if any, If there is No shared resource, we will count every one is 100% allocated to this Scrum Team. For example lets assume we have one Tester (Tester 3) who is shared between two teams, and his allocation is 50% for this team in example.
Step 4 – Calculated The Standard Hours per day
If we assume every one has 8 hours per day on full allocation, The Shared resource will have 4 Hours per day allocated for this team. For this sprint.
For 10 Days Sprint the total Max capacity is 520 Hours for the entire Team and having 52 Hours per day, Including Shared Tester. Every One has 80 hours for 10 days and the Shared Resource with 50% allocation have 40 Hours, for this sprint Duration.
Now Lets See how does that looks like in our calendar
Step 5 – Consider The Factors
1. Team Holiday
Mark the date that is off for the entire team. National Holidays etc.
2. Calculate the Individual working off.
Calculate based on – if any resource have planned off / out of office.
3. Override default working day hour.
If Required – Take an exception for individual team member, to change default hours from 8 Hours to some thing else, Specially if some one has a plan half day or the plan hours have other than other than the default 8 Hours (100% Allocation)
Assuming – 9th of Jan is a Team Holiday
In this case : we can see from this picture, that the total and Individual capacity is reduced accordingly.
Assuming – Developer 1, Developer 2 and Tester 1 have a Planned full day off for three different days. By applying that we can see from this picture, that the total and Individual capacity is reduced accordingly.
If Developer 3 plans a Half day work on 13th Jan. The plan capacity will change accordingly as below
Step 7 – Consider Focus Factor
Plan it accordingly to your team can focus, for any unplanned time loss keeping in mind the daily time off, adhoc unplanned meetings , other official activity, training, Discussion with SME etc. Remember for planned activity your can still calculate before hand. We keep focus factor for any thing that can not be plan. That value can vary 75% to 95%
So The Final Capacity for this Team for Sprint 2 is 318.32 Hours
Summarizing the 7 Steps
The Values , Percentage and amount of hours are for the above example only. You need to put values based on your own need and facts.
- Calculate the Focus Factor the best suits your project.
- Sprint Duration as per your Sprint Cycle
- Plan it for Developers/ Tester and any other Role in your Scrum team (except SM and PO)
- Team members allocation as actual in your team
- Factors like Team Holiday, Planned Vacation, partial are not just limited to these tree factors.
- Calculate the Times of Ceremonies as per your schedule with addition to any other planned meeting
- In The above example I have not calculated the vacation day is falling under any ceremony day, to avoid complication and granular level calculation.
With Scrum Master’s facilitation A Scrum Team can identify the capacity before the sprint planning. The best time is just before the Sprint Planning for any specific Sprint, That gives the best visibility of Resource’s vacation plan or Ceremony time.
If the Team is using any ALM tool, Individual team can update their available time, Scrum Master can help the team understand how to calculate their Individual Capacity. Before hitting the Sprint Planning, the Scrum Master can conduct a quick 30 min meeting with the team and get the Capacity Calculated and Update accordingly. When I was a Scrum Master I used to calculate all the factors in Excel initially with the team 1 or 2 day before Sprint Planning, and eventually the team was mature enough to do that by their own with very minimal intervention.
Capacity Planning helps the team to gauge the available bandwidth for the team to commit and complete User stories. Specially when you estimate your capacity by hours and map task of committed user stories with the Individual capacity and his/her assigned estimated task hours. The team can identify the limit of committing user story in Sprint Planning. We will discuss more in details how we map our tasks and capacity during Sprint Planning, in a different article of Understanding Sprint Planning.
The Reason why I always prefer Capacity Planning and Mapping on Hours Rather than Velocity is, Its easy to calculate available Hours by simply math with Days, Vacation, Leave, Other Time, Focus Factor etc. to get a Team Capacity. That’s is technically not possible with Velocity and the team needs to make assumptions which is dangerous,
Secondly you can not assign a Story (having Story points) to a single member, as completing a story is mostly a team effort. And distributing any story points between team member, Huh!! Cant even think about it, where One Story (what ever the story point is) can have multiple tasks (each task having efforts estimated in Hours) can easily be assigned to one or more Team Member, each task can assigned to each member. We will see more in details with demonstration in a different article of Understanding Sprint Planning.