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 a 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 pre-requisites for using focus factor are:

1. Velocity calculated as an average of accepted story points over the past 3 to 5 iterations
2. Requirement (such as user stories) estimated using story points
3. 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 7 members who are productive for 6 days each, and 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. E.g., if an iteration has only 5 members available, 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 3 to 5 iterations provides a good forecast of the immediate next iteration. This also helps analyse 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 which must be performed in order to complete this requirement.
   • Make sure that these tasks are small which can be completed within a day or two.
   • If this seems difficult to achieve, attempt to split up the requirement into smaller functionality which 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 if 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 it will lead to unnecessary technical debt.
5. Repeat this exercise for the requirements moving down in the backlog until the team runs out of the 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.

The stories picked up for implementation in the iteration one can be considered as a ‘reference story’ from an estimation perspective. All the other stories in the backlog can be estimated on the basis of the ‘reference story’ implemented in iteration one.

Forecasting with Limited Historical Data

Lack of historical data to derive the average velocity in 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 analyse the team’s capability and performance. The following table can be used for the 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, and taking an average of these results.

E.g.: 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. In these cases, it is wise to have focus factor calculated for each functional group within the development team, rather than the team as a whole.

E.g., if a development team has 4 developers and 3 testers who are productive 6 days each, the focus factor must be calculated as:

• Developer’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. E.g.: if I have 3 developers and 3 testers available for the next iteration, the forecast would be:

• Developer’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 development.

Another e.g.: if I have 4 developers and 1 tester available for the next sprint, the forecast would be:

• Developer’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 development is complete since it will not be possible to finish the automated tests.

Careful project management of the critical path, detailed planning with risk mitigations, 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 Developers, 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 appendix A – Constructive use of the available capacity). 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.

Conclusion

This article provides only one of the many methods to forecast deliverables in 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 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.

Appendix A.: 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 organisation and project’s culture.

• Googlers spend 20% of their time every week on pet projects.
• Deloitte has a culture of “Firm Activities” where employees contribute towards improving the firm’s capabilities by performing social and knowledge sharing activities.
• Atlassians spend time volunteering for their favourite charities – “Fun & Philanthropy”
• Arrk Group promotes “Communities” to improve collaboration, perform analysis, research and development towards latest IT trends.
• Improve your knowledge, take up a hobby, listen to music, go trekking, party, or simply spend time with your family.
• In any case, learning must never stop.