Get certified - Transform your world of work today

# Agile Forecasting with Focus Factor

7 July 2014

How many deliverables should we commit to our customers in, say, the next two weeks? An intriguing question asked by many Agile teams at the beginning of every iteration. The answer to this question depends largely on the team's thinking, philosophy, and skills -- which unfortunately cannot be measured. Then how do we forecast the deliverables?

How about a mathematical formula that provides an unbiased control based on the historical achievements of the team, which can be used for prediction? That's exactly what focus factor does.

### Focus factor is simple mathematics

Focus factor is a simple mathematical formula for forecasting the number of deliverables possible in an iteration. In an Agile environment, this number can be arrived at by considering the capacity and velocity of a development team. The prerequisites for using focus factor are:
• Velocity calculated as an average of completed story points over the past three to five iterations
• Requirements (such as user stories) estimated using story points
• The development team's capacity (excluding nonworking days and time spent in meetings)
A team's focus factor is calculated as: focus factor = velocity / capacity.
Example: If my team has 7 members who are productive for 6 days each, and as a team they have a velocity of 31, then the focus factor is calculated as:
• Focus factor = 31 / (7 * 6) = 0.74
This focus factor can now be used to forecast the deliverables for the future iterations. So if only five members are available during an iteration, the achievable story points are calculated as:
• Forecast = Focus factor * Capacity = 0.74 * 5 * 6 = 22 [story points]
Maintaining the average velocity and focus factor of the past three to five iterations provides a good forecast of the immediate next iteration. This also helps us analyze and adjust the team's current performance and capability.

### Forecasting Iteration One

It is difficult to estimate the first few requirements based on story points with a fairly new team or project. It is even more difficult when the team needs to commit the amount of deliverables without any prior experience on the project. A fairly extended approach can be taken under these circumstances to arrive at the forecast for the very first iteration:
1. Estimate the high-priority requirements from the backlog using story points.
• Make sure these requirements are small enough to be completed in a single iteration.
2. Select the highest-priority requirement and break it down into granular tasks that must be performed in order to complete this requirement.
• Make sure that these tasks are small enough to be completed within a day or two.
• If this seems difficult to achieve, attempt to split up the requirement into smaller functionalities that can be delivered independently.
3. Estimate (in hours) the amount of time it will take to complete the individual tasks.
4. Add up the estimates and check whether the team has the available capacity to commit this requirement for this iteration.
• It is advisable to assume not more than six hours of productivity a day.
• Available capacity must be calculated for each team member keeping in mind the holidays (if any) and time spent in meetings.
• Refrain from partially committing requirements, as that will lead to necessary technical debt.
5. Repeat this exercise for the requirements, moving down through the backlog until the team runs out of available capacity for this iteration.
This exercise is time-consuming and will not be consistent for every iteration, as the estimates will change with experience -- tasks that took longer to complete today will not in the future. Once the first iteration is completed, teams must improvise to come up with better forecasts, as explained in the sections below.

### Forecasting with limited historical data

Lack of the historical data needed to derive the average velocity at the beginning of a project can hinder one from calculating the team's focus factor. A way to tackle this problem is to keep the team size constant for the first few iterations and analyze the team's capability and performance. The following table can be used for this purpose:

Iterations Completed
Low Multiplier
High Multiplier
1
0.6
1.60
2
0.8
1.25
3
0.85
1.15
4 or more
0.9
1.10

Source: Agile Estimation and Planning (Mike Cohn)

These numbers have been derived by observing many Agile teams and have proved to be a good starting point for new projects. A forecast can be derived by multiplying the story points achieved in the previous sprint with the low and high multipliers, then taking an average of these results.

Example: If a team achieved 27 story points in iteration 2, then the forecast for iteration 3 is calculated as:
• Low multiplier = 27 * 0.8 = 21.6
• High multiplier = 27 * 1.25 = 33.75
• Forecast for iteration 3 = (21.6 + 33.75) / 2 = 28 [story points]
Assuming that the team's capacity has remained constant, it should achieve a stable velocity by the end of the fifth iteration. This stable velocity can then be used to derive the team's focus factor.

### Forecasting with specialist team members

An ideal Agile development team would consist of cross-functional individuals -- sadly, that might be difficult to achieve all the time. Therefore it is wise to calculate the focus factor for each functional group within the development team, rather than for the team as a whole.

Example: If a development team has four programmers and three testers who are productive six days each, the focus factor must be calculated as:
• Programmer's focus factor = 31 / (4 * 6) = 1.29
• Tester's focus factor = 31 / (3 * 6) = 1.72
Using this data, forecasting the amount of deliverables will depend on the weakest link. So if I have three programmers and three testers available for the next iteration, the forecast would be:
• Programmers's forecast = 1.29 * 3 * 6 = 23 [story points]
• Tester's forecast = 1.72 * 3 * 6 = 31 [story points]
This simply means that the development team cannot deliver more than 23 story points, since there won't be enough time to finish programming.

Another example: If I have four programmers and one tester available for the next sprint, the forecast would be:
• Programmer's forecast = 1.29 * 4 * 6 = 31 [story points]
• Tester's forecast = 1.72 * 1 * 6 = 10 [story points]
This means that the team cannot deliver more than 10 story points even if the programming is complete, since it will not be possible to finish the automated tests.

Careful project management of the critical path, detailed planning with risk mitigation, and sequencing of activities can improve the amount of deliverables, but it may not apply to every iteration. Care must also be taken to make sure that the principles of Agile, including vertical slices, Definition of Done, and continuous integration are not hampered -- any technical debt must be avoided.

The number specialists, like programmers, testers, UX designers, business analysts, technical architects, etc., within a development team can increase the number of functional groups -- which eventually leads to the problem of the weakest link (see "Constructive use of the available capacity" below). The ultimate goal must be to merge the team's capabilities to be cross-functional as much as possible, or have a team structure that can limit the work in progress efficiently to improve productivity. Until then, the weakest link will drive the amount of deliverables.

### Constructive use of the available capacity

What do we do with the available time? That seems a viable question. The answer may vary based on the organization and project's culture.
• Googlers spend 20 percent of their time every week on pet projects.
• Deloitte has a culture of "Firm Activities," meaning that employees contribute toward improving the firm's capabilities by performing social and knowledge-sharing activities.
• Atlassians spend time volunteering for their favorite charities -- "Fun and Philanthropy."
• Improve your knowledge, take up a hobby, listen to music, go trekking, party, or simply spend time with your family.
In all cases, learning must never stop.

### Conclusion

This article provides only one of the many methods of forecasting deliverables within an Agile team. Although other methods are available, this seems to be the simplest to manage and implement. Care should be taken that historical data is well maintained and referred to regularly to improve the team's estimations. This, in turn, improves the forecast and productivity of the development team and helps them be truly Agile.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

### Article Rating

Current rating: 4.6 (9 ratings)

Zach Bonaker, CSP,CSM,CSPO, 7/7/2014 11:09:43 AM
Let me start by saying that you've written a great article, with wonderful detail, and a very easy to follow breakdown of the quantitative aspects you're proposing. Nicely done!

With that said, I'm highly cautious of our community growing enthralled with velocity, points, etc. This article suggests a path that I'm not comfortable with as part of uncovering better ways to develop software.

Software estimates are waste. Some of you will agree with this statement, others will proclaim blasphemy and shake their fists in anger.

To you fist shakers, take a moment to consider the value of estimates. Customers don't buy estimates, Teams don't need estimates to do work, and - being guesses - estimates are wrong. Estimates do help the business discover a range of dates/features for release planning... no argument there. But let's minimize the time we spend estimating, especially avoiding any form of estimation that becomes process imposed by the business.

Taking velocity and turning it into "focus factor", to me, suggests a reliance on velocity as something more than a lightweight projection. I don't agree that velocity is useful for sprints, therefore to use "focus factor" as a means to forecast work a sprint seems akin to treating a traditional absolute estimate as a deadline.

Here's my rational take:
Let's assume a team has a velocity of 20 points. Suppose a backlog exists that has not been estimated in points, but the team is comfortable with the work (i.e., similar to the "conformation" C of user stories).

What is the difference between the team selecting stories they confidently believe can be done (with no estimates) and picking stories that sum to 20?

In fact, I'd argue the later carries higher risk.

Just a basic scenario highlighting that estimates aren't all that useful. And given that story points are a distribution/range of effort, it seems even more faulty to take these data and try and make them formulaic.

Two cents from an Agile mindset.
Vishal Prasad, CSPO, 7/8/2014 2:50:14 AM
Thank you for your comments Zach, I would have to say that I agree with most of your points. But this article may have been misunderstood on some aspects. To begin with, when I say forecast, it's not a sprint forecast but rather a project forecast.

As you rightly mentioned,

1) "velocity isn't useful for sprints". Velocity is more of a long term projection which one can use to predict the features that will be available for a release; for a product owner it's her release plan. It's that measure that allows CEOs of Apple and Google to go on stage and say with confidence the new features their customers will receive this spring.

2) "customer's don't buy estimates". But customers need ROI which is heavily dependent on time (which theoretically is fixed). A tentative release plan using the velocity provides them enough information to plan their investments. As agile teams, it's our job to deliver working software ASAP and not estimates.

I consider estimates as more of a planning tool than a number to win project bids. During sprint planning, teams need not even look at the story points. If team members estimate sprint tasks using time, it becomes easier for them to plan & sequence their activities. The resulting velocity is just an outcome of the sprint, not a number to be achieved. That's the reason why it's mentioned in the article that the the first sprint should be planned using time. Although, I do feel that a more appropriate section tile would have been "Planning Iteration One".

Focus factor on the other hand is more of a release plan based on the resource plan. If it's known well in advance that a few team members will not be available for a few weeks during the project, it's safe to say that the team's productivity will decrease. This is where focus factor can be used to predict the velocity in these periods to adjust our scope and release plans.

As for the example you mentioned, the pre-requisite of this technique is a backlog estimated with story points. If your flavor of agile does not have it, you're better off without this process.

I do agree that this looks like a long process, but product owners knowingly or unknowingly do these activities on a continuous basis. I've just tried to point out the details. If I've convinced you, do rate the article.

Thanks.
Honey Maharana, CSM,CSPO, 10/7/2015 12:06:57 PM
Nice Article!

Focus factor can also be considered a common parameter to assess and compare the performance of different teams.

However, when you consider work capacity, shouldn't it be more story point oriented rather than productive days of work. By taking productive days into consideration, we are comparing two 2 different units (velocity in story points and work capacity in productive days).

Any views on this issue...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.