How To Do Effective Capacity Planning on The Scrum Team

by Avienaash Shiralige

During sprint planning, scrum teams often face this challenge of sprint commitments. How many stories can we commit in this sprint? How to plan for the team capacity?

I ask teams to do commitment driven planning during early stages of scrum adoption.  For you to commit to a sprint goal, you need to know current team capacity. Team capacity is calculated as per people availability in that sprint.

Capacity Planning

Let’s take an example.

Say team is of 5 people, then total capacity assuming 8 hour day, 2 weeks sprint(10 days) is = 5*8*10 = 400 hours. Planning for this total capacity will be disaster. It will lead to team working over time, rushing towards the end, quality cuts and low team morale.

Then to what capacity team can commit for? How can team make this sprint planning effective?

I prefer to use Focus Factor (F.F) on this total capacity to arrive at real capacity for sprint commitments/forecasting. This factor lies in the range 0.6 – 0.8.

So what is focus factor then?

Traditionally, project managers used 6-6.5 hours as planned hours in a day for project execution. Focus factor is teams ability to remain focussed on the sprint goals without any other distractions. After multiplying total capacity with focus factor you get real capacity against which you can make sprint commitments or forecasting.  This is the effective hours you can expect from the team.

In this example, applying focus factor say 0.6, then this team real capacity will be 400*0.6 = 240 hours.

Now this 240 hours of work is what the team can take up in the current sprint. Teams take top priority stories from the backlog as per ordering done by PO. Divide those stories into tasks as shown below and estimate each task for hours. Team will take on the stories till the time all the tasks sum to not more than 240 hours(in this example).

Story-Task breakdown

I use lesser focus factor(say 0.6) on the following situations:

  1. When team is starting new on a project
  2. Team is using scrum for the first time
  3. Team is working on a complex product or new to technology domain
  4. Team is less matured, needs lot of handholding and so on…

I prefer to start a team on successful note(improves morale). Using lesser focus factor when you start fresh and then if team meets sprint goals early, then they can take up more in the current sprint. Retrospect on this in coming sprints to see if you want to increase focus factor marginally and fine tune, iterate this factor as you go, to reach sustainable pace/Flow. Going beyond 0.8 can be risky and can derail teams too.

If organisation is very chaotic then this factor will remain on extreme left like 0.6 or may be below. Chaotic organisations have lot of unplanned meetings, pre-sales urgency(team pulled for the estimates for new prospects), hiring team coming to the project team at a last minute with a interview request, not having defined core working hours and list goes on… To summarise –  no rhythm in the organisation.

This factor takes care of all the team distractions(SM effectiveness), time taken by the team to do scrum ceremonies, team meetings facilitation effectiveness, organisational efficiency and more.  During the retrospectives, analyse WHY and put action items to fix them.

Tip 1: Please don’t use buffering at task level as FF will take care of it at sprint level. Use ideal time(actual effort if there is no distraction) for task estimation in hours.

Tip 2: One major factor that drags focus factor is people being allocated to multiple projects, overhead of task switching comes to play. Try to minimise this if you can not avoid.

References and Recommendations

Spread the love
Kapil Saxena January 17, 2014 at 3:52 pm

Good Post!

I’d like to explore more on how to determine the exact focus factor in various scenarios? Do we have any formulas to derive it apart from the examples given above?

Sumit Goel January 17, 2014 at 7:16 pm

Nice article Avienaash!! Just wondering how the FF is calculated?
Sumit Goel recently posted..Collect Centrify DirectControl Debug Log

Paul Osborn January 19, 2014 at 9:34 pm

Small modification/suggestion that might make this even more powerful. I think you might start with max capacity based on ideal hours (6 per day) – and not an 8 hour day. This will increase your focus-factor percentages, and not give the impression that you can actually ever get to your definition of 100% (8 hours of completely productive work).

Vincent Brouillet February 5, 2014 at 5:35 am

Hi Avienaash, this is pretty much the approach I’ve been following so far. As you noted, it is very important to consider those factors:
– new team
– new technology
The FF will reduce dramatically.

Another challenge I find with the FF approach and estimating the story based on the hours per tasks within that story: comes a time at the end of the Sprint planning session where the scrum master would ask confirmation: do you, as a team, commit to those stories for the next Sprint ?

The team can think about the number of hours and the tasks and most of the time agree, with their own estimation, they just did. So they’d say yes, we commit to it.
Fair enough, with the hours estimated for each task, we have a scientific approach. Which to me conflicts with the question above, where we ask for a “gut feeling”. Developers are pragmatic people and would tend to follow the scientific reasoning (hours estimated) rather than their guts feeling, especially at the end of a long meeting when everybody wants to leave for lunch break.
What I’m trying to say, is that by applying such scientific approach to estimation and commitment, we steal away the other approach which is based on overall feeling: whether the team can commit to a certain group of stories, not to hours and tasks.

The latest approach is crucial. Because, there are numerous number of tasks that will be forgotten or might not be directly related to building the feature, but non the less useful. It could be some troubleshooting, some issues with a framework, last minute fix on the automation of deployment, testing the feature locally, testing the feature on the integration environment, walk through with the BA and so forth.
Often I find, the tasks don’t take into considerations manual testing by the developers (during development and when feature is completed) and the issues they might face along the way. Most developer focus on the coding time, not the testing and deployment time. As you said, adding buffer is not a good idea neither.

I’d say estimating tasks can be useful and dangerous at the same time.
Your thoughts ?

Comments on this entry are closed.

{ 2 trackbacks }

Previous post:

Next post: