Agile Forecasting with Focus Factor

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 the 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 non-working days and time spent in meetings)

A team's focus factor is calculated as: focus factor = velocity / capacity.

Example: If my team has seven members who are productive for six days each, and as a team they have a velocity of 31, then the focus factor is calculated as:

• Focus factor = 31 / (7 x 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 x 5 x 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 no 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:

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 x 0.8 = 21.6

• High multiplier = 27 x 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 x 6) = 1.29

• Tester's focus factor = 31 / (3 x 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 x 3 x 6 = 23 [story points]

• Tester's forecast = 1.72 x 3 x 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 x 4 * 6 = 31 [story points]

• Tester's forecast = 1.72 x 1 x 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.

If you're a Scrum Alliance member, find out how to help your team limit WIP in a Learning Journey course. You’ll find out what anti-patterns look like, what success looks like, and how you can guide the team as a scrum master. 

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.

Read more about forecasting here.