# Calculating last Sprint's Focus Factor

We have finished our Sprint in half the expected time and now we want to compute our focus factor to use in the next Sprint. Though, by doing the math by the book, we get an awful number. How are we calculating it wrong? Please take a look bellow:

• Team composition: 3
• Sprint length: 2 weeks
• Team availability: 28 days (discounting team members shared with other teams)
• Estimated focus factor: 70%

• Estimated velocity: 19 ideal days (derived from: 28 days * 0.7 focus factor)

• Actual velocity: 9.8 days (we finished the whole Sprint in half the expected time, clearly overestimated)

which gives us a focus factor of...

• Actual focus factor (to be used in the next Sprint): 35% (9.8 actual velocity / 28 available man-days)

Acording to Scrum And Xp From The Trenches we calculate Focus Factor as "(actual velocity) / (available man-days)". Though, by finishing the Sprint in half time and doing the math, we get a focus factor of 35%! What are we doing wrong?

• You said you finished the sprint using half the time and you are surprised that your focus factor is half the estimated one. You are not calculating it wrong, the only thing you do wrong, is being surprised.
– user2567
Jun 9, 2011 at 15:19
• Something that concerns me is the measurement of velocity in days. Velocity is points per unit of time (typically points per sprint). Defining velocity in terms of time doesn't make that much sense to me. I'm pretty sure that Focus Factor depends on duration and velocity, which is why I'm questioning your measurement of velocity. Jun 9, 2011 at 15:22
• @Pierre 303: I understand focus factor as a proxy to "how focused and concentrated" the team is. By finishing everything in half the time I would expect that focus factor would reflect "super-human" performance, i.e. a focus factor of 200% Jun 9, 2011 at 15:25
• @ThomasOwens, AGREED. One of the common ways that good Agile goes bad is when managers coming from traditional waterfall experience try to blur the lines between "Points" and "Time" and treat them interchangeably. It is unfortunately more common than it should be. Jun 9, 2011 at 15:32
• I think @azheglov's answer pretty much addresses it. Jun 9, 2011 at 15:57

The only thing you're doing wrong is measuring velocity in days. Velocity is measured in points per sprint.

If your velocity (based on several completed sprints) is, say, 10 points per sprint, you can pull stories that add up to 10 points into the following sprint and that's it.

The problem is, what do you do when you don't have such statistical data on your velocity. Kniberg deals with it in his book by suggesting that you estimate in "man-days" initially, but switch to points per sprint later.

The focus factor is simply the percentage of clock time that you can devote to active work on your stories during the sprint. 70% is a good approximation.

ADDED to answer comments: Henrik Kniberg in his "Scrum and XP from the trenches" book suggests that if you don't have velocity (points per sprint) statistics yet and don't have a good grasp of relative story sizing yet, you can approximate it by equating one story point with one "man-day". Because you won't be able, realistically, to devote 100% time to working on stories (meetings, interruptions, etc.), that's where the focus factor comes in.

Focus factor and the story-point-person-day equivalence go together. If you (don't) need one, you (don't) need the other. If the team is ready to estimate relative sizes in points, they don't need focus factor.

• I'e never heard of Kniberg - could you elaborate on how you make your first estimates if your stories have points, and then later make the transition? I was taught that your first sprints, the development team uses their collective experiences to pull down enough tasks to keep them busy for the sprint. If it's over, you pull down less on the next sprint and if it's under, you pull down more points before the sprint is over. Jun 9, 2011 at 15:59
• Kniberg wrote "Scrum and XP from the trenches". Jun 9, 2011 at 16:13
• @Thomas: yes, @wollfgangsz got it right. I added a link to Kniberg's book to the answer. Jun 9, 2011 at 16:38

I think you're getting stuck in the math too much, and losing sight of what's important.

The reason you do all of this stuff is to figure out how much work the team should put into a Sprint and commit to. When you're confident that you have a handle on this, then you can start to meaningfully extrapolate how many Sprints it should take to get a certain way down the PB, although even this gets dicey because the PB is a living evolving thing.

What you really want to do is figure out how many estimated man days, or man hours, or story points, or fable pennies or whatever unit you want to use, that you can get done in a Sprint. Nothing else matters. You can call that velocity if you want, or make up your own term that works better for you.

The real issue that you have is to figure out what happened with your estimates on the last Sprint. Why were they off by so much? Now that is going to lead you to one of a few conclusions:

• It was a one-off fluke and probably will never happen again. Discard the results and continue on like it didn't happen.
• Damn! We suck at estimating and we habitually over-estimate each task. It will never change. So double the amount of estimated work you put into each Sprint.
• We're consistently over-estimating our work by a factor of two, so we'll halve every estimate going forward and leave our estimated velocity the same.
• Damn! We suck at estimating and we're going to improve. IMHO, this is the best conclusion but also the one that gives you the most planning problems. Why? Because your estimates are going to constantly improve in accuracy and your velocity is a measure of your past ability to complete estimated tasks. So your past velocity is only partially relevant to the velocity you'll expect to have in the future as your estimating techniques improve.

When we started doing Scrum 8 years ago, I routinely calculated the number of man days available to Sprint project work by taking the total number of man days that the team members were in the office and dividing by two. That drove my boss crazy, because he wanted to know why we were giving up half a day for each work day without a fight. I figured it was aggressive because I thought I'd be lucky if I ever got any near to 1/2 a day on project work from each team member each day.

So essentially, I just randomly assigned a focus factor of 50%, even though I'd never heard of the term "focus factor". And that was good enough to get Sprints up and running at the beginning of our Scrum experience. Over time, I've learned that we'll do well if we take on between 8 and 11 days of project work for each team member for each 4 week Sprint. I'll adjust that down if someone is on vacation or out of the office for a few days, or if we know that there's something going on with the business that's likely to take one of the team members away from the project for a while.

Our team is not homogeneous in skill sets (yet!), so we actually carve up the tasks to individual members or groups of members during the planning meeting. Then we add up all of the man days for each team member. If I see a 13, or if I see a whole bunch of 11's on the whiteboard then I know we've got a problem. We'll shuffle stuff around if possible, or drop stuff out of the Sprint.

But the point is, there's no math involved. I keep an eye on whether or not everything got done, and whether there was extra time left over for someone, and then we discuss it and adjust as necessary when going forward. It doesn't need to be complicated. You want to keep the project moving forward as fast as possible, but not overloading the Sprints so that stuff doesn't get completed.

Your math should look like this:

• Actual Velocity = 19 man/days (as estimated)
• Sprint Length = 9.8 days
• Focus Factor = 194%

That said, focus factor is pretty much crap and just a way to explain why it takes more than one hour to complete a task estimated at one hour. After a few sprints, your team will get better at estimating and things will start to come more into alignment.

I have a different opinion on this. We have 3 parameters to consider here. Those are;

1. Allocated Time in man hours (AT): Time spent by a person while allocated to a task, say task1 (e.g. if a person work for 9 hours daily and normally spend 1 hour for lunch, coffee etc. then per day time allocated for work is 8 hours, so AT = 8)
2. Focused Time in man hours (FT): The amount of time a person has actually managed to focus on the above task1 (this is going to be most of the time <= AT)
3. Burn Down in man hours (BD): By focusing on task1 person will complete a certain amount of estimated work. That is termed as ‘burn down’.

Now let’s take an example

AT = 16 hours (i.e. 8 hours / day for 2 days)

FT = 12 hours (on average he is distracted by 2 hours per day, say in meetings etc.)

BD = 10 man hours (This is the estimate of the task1)

Focus factor = FT/AT = (6 * 2)/(8 * 2) = 0.75

But this does not take into account the amount of work completed from the estimated tasks (burn down). This person has spent 12 hours (with good focus) to complete a task estimated for 10 man hours. So in order to get that effect into focus factor it is better and reasonable to focus time by burn down in above formula.

Focus factor = BD/AT = (10)/(8 * 2) = 0.625

So in my opinion the focus factor formula should be:

Focus factor = Burn down / Allocated Time

The math may be right, but your interpretation is wrong.

According to your data, your team did nothing for 18 days, so they must be very un-focused!