How Jira Align Supports Agile Forecasting
Overview
One of the most exciting things to emerge from SAFe recently is the increasing clarity about how enterprise finance becomes a vocal, active, and engaged participant in the move to scaled agility. SAFe’s Lean Portfolio Management (LPM) guidance offers a range of well-thought-out practices that provide the right amount of oversight and governance while meeting the requirements of finance organizations to forecast as needed.
Within the context of finance and agile reconciliation, organizations may also need to shift their ideas about how agile teams forecast. This blog will describe a common tension that exists around agile forecasting; a legacy anti-pattern from project-based funding. It will then describe how SAFe LPM processes alleviate that tension. Finally, we will provide recommendations for handling agile forecasting in Jira Align for organizations shifting to LPM.
Forecasting in a Project Based World
Many organizations have yearly annual budgeting meetings to determine funding for big initiatives. Business Units are usually in competition with one another to present a compelling financial case. To do this, they must get estimates from people who will do the work. This puts a lot of pressure on those people. First, they have to estimate based on current state and it’s guaranteed things won’t be the same even three months in the future. Near term estimates are more accurate than long term estimates. Second, if they are practicing agility, they believe in building in small increments and in not starting work, or even estimating work, if there is a lot of uncertainty. So, an agile team will push back and say something like, “I can’t possibly give you estimates on work that far out.” And the project manager will then say, “but I can’t fund you without the estimates.”
This creates tension in the system between business and delivery teams.
Forecasting in a Scaled Agile World
In an LPM world, things are different.
First, LPM advises that organizations move from yearly competitive funding cycles to twice yearly participatory and collaborative budgeting cycles with processes and funding models that can accommodate mid-year shifts in priorities. LPM asks that we focus on creating the leanest business case possible, so that we don’t have a lot of admin overhead and don’t have to create big cost models upfront. To reduce the risk of spending too much, SAFe advocates that organizations test a hypothesis first with a minimally viable product, a small unit of value to be built and proven before more money is funded.
These two ideas help to make the initial investment smaller and testable. This reduces financial risk and the need to justify a huge spend.
Second, LPM encourages that stable Portfolios (defined as groups of value streams) are funded. The portfolio budget is not dependent on the initiatives budget; the portfolios will always be funded independently of initiatives. The concern moves from, “How much money can I get for my thing so that I can hire people to do my thing,” to, “What is the priority thing we want the teams to work on?”
Third, with smaller testable initiatives and funded stable teams, the only thing left to think about is: which initiatives should the portfolio work on? LPM advocates that all parties participate in deciding priority. Gone are the days where business units have one-to-one relationships with fiduciaries, hoping to gain influence for one big initiative. Instead, business owners, fiduciaries, and technical architects are all part of the prioritization of the work. Initiatives enter into a funnel of ideas, and then are reviewed and analyzed. Enterprise architects provide size estimates to be considered in prioritization. A collaborative evaluation process – the portfolio Kanban – is put in place.
This moves the tension back to where it should be, among leaders who need to consider highest value and highest priority items for the enterprise. Deciding priority is not easy. There will be difficult conversations. But they are to be had prior to requiring a huge outlay of energy or estimates from delivery teams.
Team leaders are brought in to forecast only when initiatives are approved. The forecast at this point is a forecast of how much of the stable capacity of the teams will go to which initiatives.
For example, suppose a program with two agile release trains has proven that they can produce 500 points of work every Program Increment (10 week period). Now suppose that two initiatives have gone through the prioritization process and been approved, each one estimated to be about 200 points by the enterprise architect.
The Program will then be notified to look at the epics and advise how much of their capacity they can give to the epics. THIS is agile forecasting. The idea is to give the programs an early look into upcoming initiatives and for them to provide an estimate of how many points they believe they can do for those initiatives for each Program Increment (PI).
In our example, we can see that each train is forecasting that it can provide 80% of its capacity to each epic. From this process, business leaders will know how many PIs are forecasted to complete the epic. In this example, it will take one PI for each epic to complete.
Jira Align and Agile Forecasting
Jira Align handles agile forecasting through the Forecasting module. SAFe’s Epic page provides an example worksheet for forecasting an epic’s duration.
Jira Align can accommodate the data on this sheet, though the graphical presentation is slightly different.
The Forecast page shows a list of all epics for a program in a PI. Jira Align calculates program velocity automatically. There is also a manual override on this page if there will be anticipated changes in velocity. In this example, we see that the AI program has 1,000 total points of velocity. 400 points has been reserved for epic 881.
To enter a percent capacity as shown on the SAFe worksheet, go to the epic and click on ‘Multi-Portfolio Epic Estimation’. Here you can enter the negotiated Agile Release Train (ART) capacity for each ART that is assigned to the epic.
As data starts to aggregate on the forecast page, it also is housed on the epic itself. This is a nice feature in that programs can look across all epics and use the forecast page as a place to enter forecasted capacity across epics without having to go back and enter that information again on the epic. We can see in the example below, that 400 points have been entered for the epic on the forecast page and that Jira Align has saved that number automatically the ‘Forecast’ tab on the epic.
Conclusion
We are encouraged by thought leadership and innovation in LPM that helps to remove tensions between finance and agile teams. Jira Align provides the needed support to implement and accelerate the mind-set shift to this new, positive direction.
