Economics in Jira Align: Demand vs. Supply Forecasting

[#1]

INTRODUCTION

As Agile ways of working emerged, companies have struggled over the years with Agile Forecasting.  The evolution from the waterfall PMO world of estimating Projects into a reasonable "will it fit?" approach for pull based systems is still challenging for most due to business expectations for commitments made to timeframes.

With recent improvements in the Jira Align Forecasting and Capacity modules, I'm going to share some practical ideas to consider.  Additional changes that are upcoming in Jira Align should be helpful to the user experience, but carry an expectation for setting the "Supply" for the Agile Teams to meet "Demand".

To keep things simple, this discussion will focus on Feature level Forecasting.  Start here and work up to higher level work items once operating well, unless your organization has existing requirements that mandate otherwise.  However, the functionality in Jira Align is nearly duplicative for items like Epics (Initiatives) and Capabilities, if used.  

Also, I recommend configuring all Portfolios to use Points for sizing Features rather than T-Shirt or Member Weeks.  Although it may be tempting for less mature groups to start with either of these, the real benefit of Forecasting is Predictability.  This can occur through a feedback loop based on the "actuals" of effort ultimately required.  This exists as Story Points, so let's avoid the [T-Shirt = x Points] conversion necessary to establish a proper learning cycle.

BACKLOG FEATURE ESTIMATION

We can start with the Backlog planned for an upcoming Quarter or Planning Increment timebox.  Although some Frameworks like SAFe guide decomposition of Feature to Stories with Point size estimates, many groups do not make a comprehensive type swag estimate that detailed at the start of a Quarter.  Sizing Features rounded in Points can help ballpark the effort. 

(Note: We'll assume rough estimates that where the Program (ART) agrees to apply some level of normalization with the points across teams that co-contribute to a Feature.  If this is not possible due to requirements that each team sizes Stories independently, the Forecasting will be difficult.)

I prefer the Prioritize button in Backlog to quickly set high level Point estimates on ranked features for the timebox.  Even though in terms of Points, these should be simple and rounded.  Simply exposing the Points field on the Backlog List view, alongside the Story Points field can provide a great starting point for retrospective learning at the end of a quarter for planned vs. delivered.  Jira Align shows this also in the Backlog Kanban Column view with the "Estimated" button selected.

Load vs. Capacity is shown for each Quarter.  With Estimates set for each Feature, a level of fit within planned capacity is available even without yet having Actuals from the later to-be decomposed Stories/Points.

FORECAST FEATURE ESTIMATES BY TEAM

If a Program (ART) is operating as Feature Teams that individually deliver a full Feature, this can be sufficient.  However, for collectively owned work on Features across Teams, then Jira Align's Forecast module comes into play.  Users can construct a lower level allocation of estimated Points for each Feature across each Agile Team planning to contribute toward the effort.  Assessment can be done on the aggregated Points then to the original Ballpark swag for the Feature, and assuming the refined estimate is considered more accurate then replaced by it. 

Note: Be sure to manually Pull the Backlog rank of the Features into the Forecast page by selecting the "Program & PI level rank" option.

SET SUPPLY TO MEET DEMAND

Now let's turn attention to the Capacity side for Agile Teams rolled up to the Program.  This new module in Jira Align allows users to apply various options.  The classic assumption is to use historical Velocity of each team, which Jira Align provides from a calculation of average points accepted from previous 5 completed sprints.  This is a great approximation, but some prefer alternative approaches which are now supported by Jira Align in the module. 

Ultimately, I'd suggest to start by applying Velocity across and then manually enter either the same or adjusted amount based on any values which appear inaccurate.  By manual entry replacement for each, this will lock the velocity value assumption for each team, rather than having the velocity calculation adjust over time as more sprints are completed.

CUT LINE: WILL IT FIT?

Now we can return to the Forecast page.  Overloaded Teams were shown further above in red.  Review and mark as Out of Scope any that will not fit, working from the bottom up.  If removal from the PI Scope is not possible, then make adjustments to rank order or review alternatives to fit the plan.

Additional Reference information on Forecasting in Jira Align can be found here: https://help.jiraalign.com/hc/en-us/articles/115000592373-Run-a-forecast