The concept of the Focus Factor when it comes to estimating capacity is a funny one. It seems straightforward and reasonable, but there are some considerations that we tend to overlook.
I have been using the concept of the Focus factor to estimate the capacity of my team since I became a Scrum master, and despite I not only find it extremely useful but also quite accurate with reality, there are some constraints I did not have into account when I first started utilising it.
So, what is the focus factor?
The focus factor is based on time, and defines how focused a resource is within a Sprint depending on the availability of the person in question. To put it in a real-world scenario:
- A team member works in a 10-day sprint. The initial focus is, obviously, 100%.
- This team member has got 3 days of holidays during that sprint. This decreases the focus 30%.
- This same person has a half-day training during that sprint. Another 5%.
- The focus factor of that individual is 65% during that Sprint.
If we take all the team member’s focus factor, we just need to find the average focus factor. What do we do with it?
A simple formula: Average velocity x Focus factor = Forecast velocity.
If our average velocity (I always take the last three sprints into account, and no more) is 50, and the team’s focus factor is 80%, then our forecast velocity is 40 points.
On top of that, I do not stick to a fixed figure. I normally have a range in place, of 20%. This means I like to think that our capacity is between 32 and 48.
The concept itself is simple and accurate. It provides a proper cap on what our minimum and maximum capacity should be. But of course, this has to be approved and validated by the team.
Now, it’s not that simple. There are some considerations to have into account when this concept is used:
The focus factor normalises itself
Let’s say a team member consistently works half of a day for a sustained period. Or a part-time worker. When that person joins the team, this needs to be taken into account by reducing their focus factor. But after three sprints (in my case), the focus factor of that person goes back into 100% even with this constraint. Because this person’s work has surely affected the average velocity in the last three sprints. And if by any chance that person starts working more time instead of less, my advice is to leave the focus factor in 100%, as it will normalise itself again.
The focus factor isn’t meant to be precise, just accurate
The sole reason of using the focus factor is to increase predictability. But as the Scrum process indicates, velocity isn’t meant to be precise. Just provide a range of security in estimations. If our story points are consistent, there is no reason to mistrust it. However, every single sprint is different. That is why the velocity range needs to be validated by the team.
The focus factor can be misleading
Yes, it can be. I remember I had the case of a team of five members, of which two of them had a two-week holiday in different sprints. Normally, this team had a consistent average velocity of 16 points per sprint. The holiday reduced the focus factor, the estimations, and the average velocity for two sprints (11 points average). When both were back, the average velocity indicated that we had a forecast capacity of 13 points, and the team highlighted that they could do more than that and come back to 16 points. There’s more to this, as there is a recovery time into account (see below), but the important thing to have into account is that the team has the last word, and that the estimations are never precise.
The focus factor has the recovery time into account
When there is a disruption in the team, there is necessarily an overtime effect. This means that the team will likely under-perform until they return to the baseline performance. This is taken into account when someone, for instance, goes on holidays or is away from the daily routine. The impact of this absence is different every time, but the example above is a good example: the forecast after the return of both members was “only” 13 instead of the “usual” 16. This is okay and even sensible. But it is, at the end of the day, the team’s decision to trust that metric.
Above we can see the chart that reflects the effect of overtime in a team. Something that can also be applied to general disruptions or re-adapting to routine after a break.
The focus factor is a powerful ally and if you have all possible constraints into account (these are just a few), also considering there are many ways of using it, the estimations for our teams can be what they’re meant to be: predictable and accurate (not precise!).