“Can your QA team handle this?” When I hear this question, the gears in my head begin to spin. What day is it? Who is available? What is on our plate? Do I expect my team to call in sick after the upcoming team happy hour tomorrow? Whether you are doing sprint planning or an impromptu project, if you lead a team, then you have to be comfortable with Capacity Planning!
Level of Effort (LOE) is Not Duration or Capacity
Let’s say you are reviewing Task 1 with your analyst:
Lead: How long will this task take you to do? Analyst: Two days.
Many people stop here. They have successfully obtained the Level of Effort (LOE) which they can plug into their plan. But the conversation should continue:
Lead: Are there any dependencies to complete this task? Analyst: Yes. When I am halfway done I will need the other analyst to complete Task 2 before I can proceed. Lead: I see she will be taking about a day to complete Task 2. Given that, it looks like it will be 3 days to complete the work from start to finish.
Now you have the Duration. The remaining question is: Do you have the Capacity?
Understand the Team’s Obligations
I once had a conversation with a team I had just joined. They were complaining about being overworked, and more being piled on. This was preventing them from doing normal sprint activities, such as reviewing tasks for the upcoming sprints. We decided the best way to prove this to management was to identify all of the tasks they were responsible for on a regular basis, and estimate how much time it was taking from their capacity to take on new work. We discovered the following:
Sprint Meetings - The team (a QA team) was responsible for supporting different scrum teams, each with their own set of meetings. A 15-minute meeting means at least 30 minutes of your time if you take the time to save what you are doing, quick-prep for the meeting, and finally get your mind back to the original task. Assuming a two-week sprint, with 10 daily scrums at 30 minutes each (due to the time lost per meeting), plus four hours of other sprint meetings (planning, audits, closeout), this is about a day and a half of lost sprint capacity per person.
More Meetings! - Every manager has meetings with their teams. Company obligations, events, and training can also pull the analyst away from sprint tasks. It adda up.
Bug Verification - As this was a QA team, they had a constant stream of bugs being fixed during the sprint. While many were anticipated during the planning, a good number were passed to the team unexpectedly. We determined that each bug would take an average of an hour to verify, and based on history, we were able to determine about how many to expect for each sprint.
Bug Rejects! - This turned out to be our biggest pain point. By pulling ticket history we discovered a large percentage of bugs went through multiple rounds of rejections. By taking this percentage and multiplying it by the average number of bugs, we were able to determine a more realistic number of bugs the team was reviewing each sprint.
Once we had these basic, easily determined numbers, we were not only able to show our shortage of Capacity to take on sprint tasks, but we were also able to show the development team their impacts to the QA team with poor quality. Steps were taken to review bug fixes upstream, which increased the QA team’s capacity and morale. Understanding your team’s normal obligations, plus accounting for holidays, time off, and the like, gives you a baseline value to subtract from your team’s sprint capacity.
Capacity Changes Daily
The hardest thing about capacity is that it literally changes on a daily basis. As you progress in the sprint, more and more things will impact your team. The capacity you had on day one is most definitely not the same capacity you have the last few days of the sprint:
Design changes occur, adding overhead to the original tasks
Bugs are found and need attention
Dependent tasks are completed and trigger new tasks, features are delivered; i.e. everything needs attention at once!
Priorities change
Sh...stuff happens!
The more sprints you plan for, the more it will become second nature to understand the capacity impacts.
Account for the Intangibles
Every team has strengths and weaknesses. You have your newbies and your gurus. You should account for this not only for your own team, but any other team directly impacting your project. Have a new designer? You might need to provide subject matter expertise while he comes up to speed. New developer? Expect more bugs. Trust your gut instincts. A simple way to account for these and other influences is to apply a multiplier against your final capacity. In my group, we just assume 6-hour days when planning. This equates to a 25% multiplier. So if you start with a 10-day sprint, times 25%, you are starting with 8 days of capacity before you even start. Figure out what works best for you.
Conclusion
Knowing your team’s capacity is critical to planning. Combine this with LOE and duration, and sprint planning can become routine. Joe Nolan is the Mobile QA team lead at Blackboard. He has over 10 years experience leading multinationally located QA teams, and is the founder of the DC Software QA and Testing Meetup.
