Financial values and calculations

Jira Align provides three unique financial values that provide insights to the cost of developing stories, features, capabilities, epics, and themes. Use these values to forecast the estimated cost of taking on a new project or initiative, dial-in that forecast once it's broken down into features, and finally check back on the actual amount spent. This article will step you through each of the three main financial values, and explain other calculations done on a team, sprint, and program level to drive those outputs. 

To review descriptions of all financial values, where they can be accessed, and the calculations that drive them, check out Financial calculations quick reference. 

• Spend values
  • Forecasted Spend
  • Estimated Spend
  • Accepted Spend
• Spend per Point values
  • Team Cost per Sprint
  • Team Spend per Point
  • Program Spend per Point 

Spend values

• Forecasted Spend is based upon the program PI forecasts entered on the Forecast tab of an epic, capability, or feature'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 work items 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 PI forecast, multiplied by the program’s current Program Spend per Point. These values are added to form a work item's Forecasted Spend.

Program PI forecasts used to calculate this value are the estimates entered on program rows within the Forecast tab of a work item’s Details panel. 

Notes:

• Forecasted Spend can be calculated for epics, capabilities, and features.
• To avoid rolling values, the Forecasted Spend for each program PI forecast will be stored (baselined) upon completing the corresponding program increment.
• If program PI forecasts are estimated in member weeks or team weeks, they will be converted into story points using the Estimation Conversions settings menu.
• Use Forecasted Spend panels to review the data that makes up a work item's reported value. 

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 Program Spend per Point. Spends from child features are added together to form the Estimated Spend for parent work items.

Notes:

• Estimated Spend can be calculated for epics, capabilities, and features.
  • Estimated Spend values from these work items can be aggregated on pages like Investment vs. Spend to provide the total Estimated Spend for a theme or program increment.
• To avoid rolling values, Estimated Spend for each feature will be stored (baselined) 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.
• Use Estimated Spend panels to review the data that makes up a work item's reported value. 

Accepted Spend

We’ve arrived at a view of investment once work is actually delivered. Accepted Spend is the cost of delivering a story, and can be calculated using either an accepted story's effort points estimate or the number of hours logged by team members working on the story’s child tasks. 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.

A team can choose whether to calculate a point-based or hourly-based Accepted Spend for all stories they own through the Track By setting found on the team’s Details panel. The default selection for newly-created teams is Points.

Different teams within the same program can select different tracking methods, and the values from each accepted story can be summed to provide a rolled-up feature Accepted Spend that consists of hourly-based spend from some stories, and point-based spend from others. 

Hourly-based Accepted Spend is calculated by multiplying the total number of hours logged on a story’s child tasks by the Weighted Cost Rate. Weighted Cost Rate is a calculation that allows team members with different Cost Center hourly rates to be accounted for, based on the percentage of hours they logged.

If a team is part of a portfolio that is using PI Blended Rate instead of Cost Center rates, then only one hourly rate exists for all team members, and weighted cost rate is equal to the entered Blended Rate on the program increment that the story was accepted in. 

Point-based Accepted Spend is calculated by multiplying a story's effort points estimate by the Team Spend per Point value from the sprint the story was assigned. 

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 $85/point. Therefore, the story's Accepted Spend was $425. 

Notes:

• Accepted Spend from stories can be rolled-up to themes, epics, capabilities, and features.
• If a story is synced to Jira through a connector, task hours must be reported through Jira. 
• To avoid rolling values, point-based Accepted Spend will always use the historical Spend per Point associated with the sprint a story was accepted in.
• Use Accepted Spend panels to review the data that makes up a work item's reported value. 

Spend per Point values

You may have noticed how Forecasted, Estimated, and Accpeted Spend calculations hinge 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 effort point “costs”, based upon a team's funding and how many points they normally deliver.

Team Cost per Sprint

Let’s start with the very root of all it: Team Cost per Sprint (sometimes referred to as 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 PI 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 cost of $4,500 for Sprint 1 and Sprints 3-5; Sprint 2 has a spend of $3,000:

Notes:

• Burn Hours is a field configured on the team's Details panel, and should be set as the max number of hours that team members are expected to spend each day on story/task work.
• 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).
• Using the Costing Method portfolio setting, you can choose whether to use PI 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 Cost per Sprint.
• At the completion of each sprint, the Team Cost per Sprint will be baselined (stored). For both Agile and Kanban team types, this will happen at 11:59 PM on the end date of an anchor sprint. 

Team Spend per Point

Now that we have a Team Cost 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 effort 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 Team Cost 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:

• Points accepted are only included from stories with a status of 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.
  • Because Kanban teams don’t traditionally estimate with effort points, it is best for financial calculations to enable the Auto-populate Estimate option on the team's Details panel, so that Jira Align 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.
• The Team Spend per Sprint report provides details on data outliers that may skew a team's spend values. 

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 effort point estimation 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:

• The rolling past five sprints can and will include Team Spend per Point values from 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.
• Program Spend per Point can be viewed in detail from the Spend per Point report.