The Jira Align Product Team could not be more excited to roll out some major changes to portfolio-level work financials. We'll be releasing these changes in version 10.95, which will be deployed to test instances on May 22, 2021, and then to production instances on June 5, 2021. Here are the highlights:
Highlights
Forecasted, Estimated, and Accepted Spend
Now, there are three distinct spend calculations that can be used to understand the scope of investment at the varying stages of the work’s lifecycle.
Spend, not cost
All references to “Cost” are now “Spend”, and more specifically, “Actual Cost” is now “Accepted Spend”.
Roll no more
Before, Jira Align financial calculations were always rolling. If a story was accepted in December 2020, its actual cost would be constantly recalculated based upon its team’s current spend per point. Now, spend will be “baselined” upon either accepting work, or, in the case of Forecasted Spend, completing a program increment.
Recognizing every team’s effort
Large bodies of work, like an epic, are often allocated across multiple programs. Now, Jira Align recognizes this by calculating Forecasted and Estimated Spend using the Spend per Point that corresponds with the program owning and delivering the work.
Welcome, Kanban teams!
Because Kanban teams do not have points or sprints, they were not represented in financials. Now, they are! Using a few mechanisms in Jira Align, we can infer a Spend per Point for Kanban teams to show the financial impact of work.
Streamlined locations
These new calculations and values will be visible inside of multiple Jira Align pages. As part of the improvements, we're distilling the experience for financial users and will be retiring five legacy pages.
Three new spend values
We're introducing three new values to gauge your financial investments:
- Forecasted Spend is based upon the program PI estimates entered on the Forecast tab of an epic or capability’s Details panel.
- Estimated Spend is based upon child feature estimates, entered on the main tab of a feature's Details panel.
- Accepted Spend is based upon effort point estimates from accepted child stories.
Forecasted Spend
Forecasted Spend is intended to provide insight into the scope of investment early in your work's lifecycle. Perhaps child features are yet to be defined and broken out, but, teams have begun forecasting the effort needed from each program for upcoming program increments.
In this case, we’ll generate a spend using each program’s PI forecast (converted into points if needed) multiplied by the program’s current Spend per Point (we’ll delve into this later on). These values are added to form an epic's Forecasted Spend.
▾ Notes (click to expand)
- Forecasted Spend can be calculated for epics and capabilities only.
- To avoid rolling values, the Forecasted Spend for each program PI forecast will be baselined (locked) upon completing the corresponding program increment.
- If program forecasts are estimated in member weeks or team weeks, they will be converted into story points using the Estimation Conversions settings menu.
Estimated Spend
The next level of detail is Estimated Spend. It should be utilized when teams begin to define and firm up features.
Estimated Spend is a feature's estimate (converted into story points if needed) multiplied by its primary program’s current Spend per Point. Spends from child features are added together to form the Estimated Spend for parent work items.
▾ Notes (click to expand)
- Estimated Spend can be calculated for epics, capabilities, and stand-alone features.
- To avoid rolling values, Estimated Spend for each feature will be baselined (locked) upon accepting the feature.
- If feature estimates are estimated in member weeks, team weeks, t-shirt size, or a relative point system (Fibonacci or Power of 2), they will be converted into story points using the Estimation Conversions settings menu.
Accepted Spend
We’ve arrived at a view of investment once work is actually delivered. Accepted Spend is an accepted story's effort points estimate (LOE), multiplied by its team's Spend per Point for the sprint it was delivered in.
For example, a story with 5 points was accepted and assigned to sprint 1. In sprint 1, the team had a Team Spend per Point of $10/point. Therefore, the story's Accepted Spend was $50. For higher-level work items, Accepted Spend is simply a sum of spends from all accepted child stories.
This value is strictly for stories that have been accepted and should be used to understand the variance between what was budgeted, forecasted, estimated, and ultimately accepted.
▾ Notes (click to expand)
- Accepted Spend can be calculated for themes, epics, capabilities, and stand-alone features.
- To avoid rolling values, Accepted Spend will always use the historical Spend per Point associated with the sprint a story was accepted in.
Building blocks: Spend per Point values
You may have noticed how each new spend calculation hinges upon what we call Spend per Point. Forecasted and Estimated Spend use a Program Spend per Point, while Accepted Spend utilizes a Team Spend per Point. At a very high-level, Spend per Point is derived by determining how much each story point “costs”, based upon a team's funding and how many points they normally deliver.
Team Spend per Sprint
Let’s start with the very root of all it: Team Spend per Sprint. This is the rough labor cost for each team based upon sprint allocations.
For the sake of simplicity, consider a team, Team A, with two team members assigned to it (one developer and one tester). Each member is working in a program increment with a Blended Rate of $50/hour.
For the past five sprints, Member 1 was allocated at a full six hours a day (or 60 hours in a 10-day sprint), for a total cost of $3,000.
Member 2 was allocated at three hours a day (or 30 hours in a 10-day sprint). With the exception of Sprint 2 - where Member 2 assisted on another team - their cost was $1,500 for each sprint.
Together, the two team members account for total labor spend of $4,500 for Sprint 1 and Sprints 3-5; Sprint 2 has a spend of $3,000:
▾ Notes (click to expand)
- Burn Hours is a field configured on the team's Details panel, and should be set as the max number hours of story/task work members are expected to invest each day.
- Team member task allocations are set on each sprint's Details panel, inside the Members tab. Member allocations can be manually configured specifically for each sprint, or copied to sprints from the overall task allocation set in the team's Details panel.
- For Kanban teams, allocations are defined from the main tab of the team's Details panel.
- If Jira Connector settings are configured to sync members to a team through issue association, then each team member will default as 100% allocation set for the sprint that an issue is assigned to. If one user has one story assigned to Sprint A and another story assigned to Sprint B, both assigned to anchor sprint 1; then their sprint allocation will be distributed equally (50% on Sprint A and 50% on Sprint B).
- Inside Portfolio settings, you can configure whether to use Blended Rate or Cost Center rate.
- The PI Blended Rate is considered to be an average hourly rate for all team members participating in sprints associated with the PI. This field is set from a PI's Details panel.
- If Cost Center is selected, then each team member’s allocation will be multiplied by the hourly rate configured for their cost center. If a team member does not have a cost center rate, they will not be included in the calculation.
- For Kanban teams, anchor sprints created within a PI are used as the “window” of time to generate Team Spend per Sprint.
- At the completion of each sprint, the Team Spend per Sprint will be baselined (locked). For both Agile and Kanban team types, this will happen at midnight on the end date of an anchor sprint. If any one of the inputs listed in the diagram above is changed after the Spend per Sprint is baselined, the Spend per Sprint will not be updated.
Team Spend per Point
Now that we have a Team Spend per Sprint value, we can move to calculate the Team Spend per Point associated with each sprint. Remember, this is the same value that will be multiplied by the story points (LOE) from accepted stories to generate Story Accepted Spend.
Let’s take our same example of Team A in Sprint 1. They had a Spend per Sprint of $4,500. In that sprint, they delivered 10 accepted story points. That means they had a Spend per Point of $450 / point ($4,500 divided by 10 points).
If the team delivered one 8 pt story and one 2 pt story, then the first story had an Accepted Spend of $3,600 and the second had an Accepted spend of $900. Ultimately, these spends will roll up to parent features and epics.
▾ Notes (click to expand)
- Points Accepted are only included from stories marked Accepted. Any stories in progress will not count.
- For Kanban teams, points accepted are derived from the stories accepted within the date range of an anchor sprint.
- While Kanban teams don’t traditionally estimate with effort points, it is best for financial calculations to use the Auto-populate Estimate option on the team's Details panel, so that the system can atomically assign a consistent point value to all stories owned by that team.
- If a Kanban team's story is accepted on a weekend, in between anchor sprints, it will be counted towards the earlier of the two anchors.
- For Agile teams, if an accepted story is dropped, deleted, canceled, or moved to another sprint, the Team Spend per Point will be recalculated for all stories accepted and assigned to that sprint.
Program Spend per Point (rolling average)
Up to this point, we’ve determined a Team Spend per Point and used it to calculate a story's Accepted Spend, which is aggregated up its hierarchy to calculate Accepted Spend for higher-level work items. Forecasted Spend and Estimated Spend still remain. They use what we call Program Spend per Point.
Program Spend per Point is a rolling average of all normalized Team Spend per Point values from the past five sprints.
Let’s start by specifying normalization: Because story pointing is a measurement relative to each team, it would be impossible to aggregate Team Spend per Point values as-is (it's like saying apples + oranges = a grand apple). For this reason, we normalize each Team Spend per Point using a standard scale before plugging these values into our Program Spend per Point formula.
From there, we take a five-sprint rolling average of those values. Using our example one last time: Program Z has two active teams, Team A and Team B. Team A had a normalized Spend per Point of $450 / point for their most recently completed sprint. Team B had a normalized Spend per Point of $200 / point.
These two numbers are averaged together to get a Program Spend per Point of $325 / point for the most recently completed sprint. This math is done for each team’s past Spend per Point from the previous five sprints.
Once a Program Spend per Point is generated for each sprint, then a rolling average is calculated. In this case, that's $340 / point.
This rolling average helps smooth over outliers that could skew a Program Spend per Point for a particular sprint; for example, holidays or unforeseen escalations that de-prioritize story work.
Now, this Program Spend per Point can be applied to any higher-level work item to derive a Forecasted Spend and Estimated Spend. For example:
- For an epic with a PI forecast of 300 points for Program Z, 300 is multiplied by $340 per point to arrive at a Forecasted Spend of $102,000 (for Program Z).
- For a stand-alone feature assigned to Program Z with an estimate of 78 points, 78 is multiplied by $340 per point to equal an Estimated Spend of $26,520.
▾ Notes (click to expand)
- The rolling past five sprints can and will include Team Spend per Point for sprints that belong to previous PIs.
- If a team does not yet have five completed sprints, they will only be included in the sprint-level calculations for the sprints they have completed. This scenario is included in the diagram above.
Supporting pages
You will be able to view the new financial values from multiple pages:
- Portfolio Room
- Status Reports
- Investment vs Spend
- Currently known as Investment vs Actuals, the page name will change
- Budgetary Tracking
- Forecast
- Roadmap > Program Increment view
Page retirements
We will also be retiring five legacy pages with the release of these changes. With the exception of Investment Distribution, users will be redirected to the recommended replacement page in version 10.95:
- Investment Distribution will be retired. We recommend using Enterprise Insights.
- Strategy Dashboard will redirect to Strategy Room
- Investment by Theme will redirect to Investment vs Spend
- Earned Value will redirect to Portfolio Room
- Program Increment Analysis will redirect to Portfolio Room
