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.
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).
I use lesser focus factor(say 0.6) on the following situations:
- When team is starting new on a project
- Team is using scrum for the first time
- Team is working on a complex product or new to technology domain
- 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 or product development 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, hiring team coming to the project team at a last minute with a interview request, not having defined core working hours, lesser clarity sprint backlog, wrong team structures(read too much inter-dependency) and list goes on… To summarise – no rhythm.
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
  |
  |
  |
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?
Well.. exact FF can never be determined (Just like an “Accurate estimate”), it has to be gut feeling, otherwise, it will lead us away from autonomy and against “Responding to change over following a plan”. Just a caution about driving individuals through formulas. I would just read team’s morale, their visible commitments, festivities, vacations etc. and go by a ball-part between 0.6 – 0.8 FF. I usually keep 6.5h/day as my baseline.
Just my two cents.
Nice article Avienaash!! Just wondering how the FF is calculated?
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).
Hi,
When we consider the number of people being a part of scrum team. Do we consider BA, PO to be a part of that calculation and consider them also as 1. Or it should be only devs and Qa
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 ?
I like the term focus factor, but as you are using it there is no relation to real data (which, by the way, can be readily available). So as you use it, I would call it fudge factor. Your instructions are to adjust it until things work out. You provide some excellent and reasonable rationales for adjusting it up or down, but they are not grounded in real data.
Real data is available, so why not use it? Here are two ways:
– Do time tracking for a sprint or two to see how many hours the team actually spend on the stories and defects. Divide this by the potential maximum and you have your focus factor.
– Do time tracking for a sprint or two but only for time team members spent off the board. Subtract this from the potential maximum, divide the remainder by the potential maximum , and you have your focus factor.
The first choice may (or may not) be more accurate but the second is less threatening to team members and it may be accurate enough.
The first time I started asking the second question at daily scrums, after a few sprints everyone was working on the board almost 100% of the time. And those external requesters were coming to me for my team’s time. I was saying no and they were living with it.
What if capacity doesn’t fit to the wanted functions which give PO a completed transaction? Example, capacity is 10 MH, while the story is “Login and display the dashboard” is eatimated as 11 MH, with the breakdown:
1. Login, 2 MH
2. Forget passwors, 5 MH
3. Authorization, 3 MH
4. Display dashboard, 1MH
If the #4 is moved to the next sprint because of limited capacity (10 MH), business user is not able to view the dashboard until completed in the next sprint. If include the #4, team has to work overtime
What should be the wisdom choice, please