Projections for (large) agile projects

How long will it take? If Charles Babbage had been able to build his analytical engine, Ada Lovelace would probably have been the first developer to be confronted with this annoying question. At first glance, it is actually a legitimate one, especially when it comes to very small and manageable activities and the answer can be expressed as a timespan of just a few hours. Unfortunately, developers are regularly asked this question for much larger projects, too. But how can it be answered at a stage when not even all the requirements are clear, let alone understood? After all, the main task is about working out these details, so we resort to making an estimate. For complex projects with many unknowns, making such an estimate resembles gazing into a crystal ball. So we cling to the hope that our estimate will not be misconstrued as a promise…

Fortunately, this issue is generally recognised in the agile world. As a result, estimates of effort are not measured in absolute time, but in relation to a standard task, taking complexity into account. These estimates are referred to as ‘story points’. From one sprint to the next, the story points (SPs) of the completed backlog items are counted, and the result is used to determine the ‘velocity’ of the team. This velocity is then taken as the basis for forecasting the progress and cost of the project.

In this context it is essential that the team and all stakeholders are aware that SPs serve as a planning parameter for the respective team only!

As can be seen in the table, 12 sprints have been scheduled, and sprint five is currently in progress. Based on previous sprints, the team velocity is assumed to be ‘27’. This velocity is the average value of the SP ‘delivered’ per sprint so far. Taking this value, it is now relatively easy to create a forecast for the upcoming sprints. This is done by making the simple assumption that the team will continue to perform at 27 SPs per sprint. Since forecasts about the future involve a certain degree of uncertainty, the standard deviation is another important figure. Subtracting and adding the standard deviation results in a pessimistic and an optimistic forecast. In concrete terms, the pessimistic estimate is 22 SPs, and in the best-case scenario 32 SPs can be delivered per sprint. At the start of the fifth sprint, it can therefore be assumed that a total of 261 to 357 SPs will probably have been implemented by sprint 12. Of course, forecasts, too, are not precise predictions of the future and, just like an estimate, they depend on a solid basis. The main difference between the two methods is transparency.

Challenges and stumbling blocks

While calculating the forecast is rather simple, there are some challenges:

• How do you arrive at a forecast before sprint 1 is complete?
• How can you make statements about a ‘feature X’ if there are no product backlog items estimated by the team for that feature yet?
• On what basis are the SPs arrived at, and what if the reference basis used to estimate is changed by the team?
• How does this work in a scaled environment (for example, with Nexus) if each team uses its own reference base for estimation?

The first point usually presents the first stumbling block for many agile projects. The idea of looking first at the costs you have or potential profits that can’t be realised if you don’t start is at the core of the agile mindset. Why spend two, three or more weeks on an analysis to make a traditional estimate that ends up being no more accurate than an initial forecast after the third sprint? Why not start right away instead?! In case of an unfavourable initial forecast (after the first sprints), the project can still be terminated, as would be the case if the classical analysis phase produced a negative outcome. However, in the best case, by that time the team may have already arrived at something that can be put to productive use. In other words, the investment will not have been completely in vain. At the very least, new knowledge will be generated.

If it is not possible to avoid making an initial estimate, the classical approaches, which will not be discussed here, are usually sufficient. But you should only focus on the scope to be implemented in the first few weeks (scope, complexity and reduction), and this classic estimate should then be replaced by actual measured facts as soon as possible!

Fortunately, the other points are much easier to resolve. Simply don’t use story point estimations made by the team. This makes sense, because, after all, how should the team estimate something based on very limited knowledge? Instead, you need another parameter that is easy to count, transparent and easy to understand.

There is an easy solution: simply estimate ‘functionality’. This is what Steve McDonnell suggests in his book ‘Software Estimation: Demystifying the Black Art’. Take a kettle, for example. On, off, lid open and lid closed. This is how quickly you can define a basic function set comprising four function points (FPs). It does not take an engineering degree to arrive at this, so any relevant stakeholder can be involved in this type of estimation. Another advantage is that you can have the implementation team and department make separate estimates. This clearly shows areas that need further thought if the estimates deviate significantly.

If the velocity of the team – measured in FP, of course – stabilises after a few sprints, it becomes much easier for the project owner to make predictions about a new feature consisting of X FP. Since a function is an atomic and universal entity, it is also completely independent of the people involved or the duration of the project. Any necessary scaling can also be easily predicted using this method.

Although tempting, just like with story points, the number of average FPs delivered per sprint should not be used to compare teams under any circumstances!

Conclusion

When planning large projects, it is important that the necessary forecasts are based on comprehensible facts and are adjusted continuously. Function points are an ideal tool here: it is easy to collect them, and they are understood by all project participants. All the while, the crystal ball stays in the display case.

Would you like to learn more about exciting topics from the world of adesso? Then check out our latest blog posts.