The Atlassian Jira Align team is pleased to announce the release of Jira Align v.10.97.

• Enhancements and Features
• Defect Fixes

Enhancements and Features

These features will be released to environments on the continuous release track on June 18, 2021, in version 10.97.0. The features will then be released to environments on the bundled release track on July 2, 2021, in version 10.97.2:

Important: API 2.0 changes (previously mentioned in 10.96 release notes)

In an effort to match property names with the Align UI and standardize property naming conventions, we changed the properties listed below. We understand that these changes impact existing integrations, but believe the changes will significantly improve the usability of the API. We’re delivering all necessary changes to an object in a single release (e.g. all changes to the Epic API will be in this release), and we expect to complete the work for all objects within the next two to three feature releases.

Epics

• isCanceled was added
• startDate changed to startInitiationDate
• estimateDate changed to portfolioAskDate
• targetDate changed to targetCompletionDate
• driver changed to strategicDriver
• budget changed to budgetTw
• complexity changed to kanoComplexity
• certainty changed to kanoCertainty
• kano changed to kanoCategory
• opExE changed to externalOpEx
• capExE changed to externalCapEx
• capEx changed to totalCapEx
• opEx changed to totalOpEx
• irate changed to discountRate
• initialInv changed to initialInvestment
• fyears changed to forecastYears
• f1 changed to yearlyCashFlow1
• methodType changed to planningMode
• bimpact changed to businessImpact
• appetit changed to riskAppetite
• fimpact changed to failureImpact
• fprob changed to failureProbability
• abilityExec changed to abilityToExec
• leanUx changed to leanUxCanvas
• rank was removed
• globalRank was removed
• backlogType was removed
• rank was removed
• dropCount was removed
• lastModifiedDate was removed

Capabilities

• kano changed to kanoCategory
• leanUx changed to leanUxCanvas
• startDate changed to startInitiationDate
• estimateDate changed to portfolioAskDate
• targetDate changed to targetCompletionDate
• backlogType was removed

Iterations

• lastUpdatedDate was added
• sprintScheduleId changed to schedule
• stateId changed to state
• velocity changed to overrideVelocity
• typeId changed to type
• owner was removed
• ownerUid was removed
• weather was removed
• isTerminated was removed
• used was removed
• goalState was removed
• teamCommit was removed
• notes was removed
• used was removed

Important: API 2.0 changes planned in 10.98.0

To allow for more time to prepare for property changes, below are the planned changes for release version 10.98.0.

Features

• isSplit was added
• spendToDate was added
• estimateAtCompletion was added
• blocked changed to isBlocked
• ticket changed to associatedTicket
• countryIds changed to affectedCountryIds
• parentSplit changed to parentSplitId
• startDate changed to startInitiationDate
• estimateDate changed to portfolioAskDate
• targetDate changed to targetCompletionDate
• opExE changed to externalOpEx
• capExE changed to externalCapEx
• capEx changed to totalCapEx
• opEx changed to totalOpEx
• irate changed to discountRate
• initialInv changed to initialInvestment
• fyears changed to forecastYears
• bimpact changed to businessImpact
• appetit changed to riskAppetite
• fimpact changed to failureImpact
• fprob changed to failureProbability
• abilityExec changed to abilityToExec
• leanUx changed to leanUxCanvas
• createdDate changed to createDate
• categoryId changed to category
• driverId changed to businessDriver
• functionalAreaId changed to functionalArea
• lastModifiedDate was removed
• iterationId was removed
• split was removed
• featureStory was removed
• firstName was removed
• lastName was removed
• emailAddress was removed
• scenario was removed
• revenue was removed
• development was removed
• roi was removed
• targetRelease was removed
• grade was removed
• impact was removed
• solution was removed
• fileName was removed
• position was removed
• featureName was removed
• useCases was removed
• addRequirements was removed
• dropCount was removed
• rank was removed
• capacityRank was removed
• epicRank was removed
• portfolioRank was removed
• releasePortfolioRank was removed
• releaseRank was removed
• releaseGlobalRank was removed
• valueStreamRank was removed
• valueStreamReleaseRank was removed
• globalRank was removed
• methodType was removed
• pendingApprovalDateEnd was removed
• readyToStartDateEnd was removed
• inPRogressDateEnd was removed
• devCompleteDateEnd was removed
• testCompleteDateEnd was removed
• backlogType was removed

Stories

• lastUpdatedDate was added
• typeId changed to type
• automationId changed to automation
• acceptedUserId changed to acceptedBy
• split changed to parentSplitId
• droppedDate was removed
• backlogType was removed
• lastModifiedDate was removed

Tasks

• lastUpdatedDate was added
• lastUpdatedBy was added
• taskTypeId changed to task
• effortHours changed to effortHours
• lastModifiedDate was removed

Defects

• lastUpdatedDate was added
• categoryId changed to category
• areaId changed to functionalArea
• blockedChk changed to isBlocked
• blocked changed to blockedReason
• duplicateOfChk changed to isDuplicate
• reproduce changed to stepsToReproduce
• suite changed to defectSuiteId
• databaseUsed changed to database
• customerIssue changed to isCustomerIssue
• commercialize changed to isCommercialized
• pmReview changed to isPmReviewed
• affectDoc changed to isAffectingDoc
• lastModified was removed
• detectedBy was removed
• detectionDate was removed
• productType was removed
• testCaseId was removed

Jira Connector usability improvements: The Why button

We've made three key improvements to how the Jira Connector works with relation to the Why button:

• Connector performance
  We've made some changes to reduce the number of updates the connector needs to make in order to keep the Why field updated in Jira. We will continue making small changes like this iteratively, as we move closer to an optimal solution to keep this field current between Jira Align and Jira. Since we know there will be some time before we can provide an optimal solution, we have added some functionality to improve the experience on the Jira side.

• Why button now uses a work item's State field instead of Progress
  The goal with this change was to keep the value of understanding how close a parent item is to being done, while reducing the number of updates the connector needs to make in order to keep states up to date. Currently, the connector will continue to only update the Why button information when a feature in Jira Align is updated, while additional changes to improve sync are planned.
  

• Why button contents now include Jira Align IDs
  Because the connector needs a Jira Align feature to be updated in order for the Why button contents to update, we have added Jira Align work item IDs to the contents of the Why button display in Jira. This way, if a work item title changes in Jira Align, you still have a consistent way to search for the work item through its ID. 

Jira Connector usability improvement: Capability parent sync

We now sync the Capability Parent (read-only text field) field with Jira, to provide more top-down visibility when working in Jira. This field functions the same as Feature Parent Name and is available for both Classic and Next-Gen Jira project types.

As part of this effort, we have exposed this field within feature Details panels in Jira Align. See the next enhancement below.

Feature Details panels now display parent lineage

While we were making changes to improve the connector integration experience, we had an opportunity to improve the Details panel experience for features. Now, you can see the entire parent lineage in the Contained In field when viewing a feature. This provides a direct link to each parent level in your work item hierarchy, up to themes. You no longer have to select Requirement Hierarchy and search within all the items to find direct parents.

Work Tree views pagination

We've improved the performance of Work Tree pages that contain large and complex hierarchies. For all Work Tree views, we added pagination whenever there are more than 50 child work items underneath a parent. Use the View More button to load items in groups of 50, similar to the other pages in Jira Align.

This improvement helped to resolve several customer-reported defects and enhanced average loading speed for many Work Tree configurations by a significant amount.

Invalid filter option removed from Work Tree

To resolve a customer-reported defect, JIRAALIGN-2309, we removed the Text/Tag option from filter settings found in the Extra Configs menu. Note that no functionality has changed, as this option did not function correctly. 

Changes to session timeout warning

We've improved your experience when a session with Jira Align is about to expire. As reported in JIRAALIGN-1637, many users were not seeing the pop-up message at the top of the screen that warned a logout was about to happen. Users who were logged out were not returned to the log in screen and could continue making invalid edits in an open item's Details panel. We've changed the format of the warning, which will not allow page edits to take place when a session ends. 

Updates to Activity Log to display API actions

To resolve JIRAALIGN-2883, we've changed the icon displayed inside of Activity Logs when a change is made through our APIs. User-made changes will continue to display a clipboard icon, which API-issued changes will display a gear icon on the left side of the entry's row. 

Defect Fixes

The list of defect fixes will be updated to reflect changes in weekly maintenance releases. You can see the contents of individual maintenance releases in the Supplemental Release Notes section.

• Enhancements and Features
• Defect Fixes

Enhancements and Features

Important: API 2.0 changes to the Themes and Release endpoints

In an effort to match property names with the Align UI and standardize property naming conventions, the following property changes were made:

Releases

• lastUpdatedDate was added
• uid changed to lastUpdatedBy
• relStatus changed to status
• beginDate changed to startDate
• short changed to shortName
• synchronize changed to scheduleType
• predecessor changed to predecessorId
• active was removed
• manualPercentComplete was removed
• picType was removed
• mode was removed

Themes

• lastUpdatedDate was added
• lifeCycleStateId changed to developmentalStepId
• lifeCycleSateIdop changed to operationalStepId
• createdDate changed to createDate
• targetDate changed to targetCompletionDate
• startDate changed to startInitiationDate
• estimateDate changed to portfolioAskDate
• lastModifiedDate was removed

The removed properties are for internal use only. Because these types of properties are not available in the UI and do not support integrations, reporting, or other API use cases, we decided to remove them to avoid any confusion.

Important: API 2.0 changes planned in 10.97

To allow for more time to prepare for property changes, below are the planned changes for 10.97.

Epics

• isCanceled was added
• startDate changed to startInitiationDate
• estimateDate changed to portfolioAskDate
• targetDate changed to targetCompletionDate
• driver changed to strategicDriver
• budget changed to budgetTw
• complexity changed to kanoComplexity
• certainty changed to kanoCertainty
• kano changed to kanoCategory
• opExE changed to externalOpEx
• capExE changed to externalCapEx
• capEx changed to totalCapEx
• opEx changed to totalOpEx
• irate changed to discountRate
• initialInv changed to initialInvestment
• fyears changed to forecastYears
• f1 changed to yearlyCashFlow1
• methodType changed to planningMode
• bimpact changed to businessImpact
• appetit changed to riskAppetite
• fimpact changed to failureImpact
• fprob changed to failureProbability
• abilityExec changed to abilityToExec
• leanUx changed to leanUxCanvas
• rank was removed
• globalRank was removed
• backlogType was removed
• rank was removed
• dropCount was removed
• lastModifiedDate was removed

Capabilities

• kano changed to kanoCategory
• leanUx changed to leanUxCanvas
• startDate changed to startInitiationDate
• estimateDate changed to portfolioAskDate
• targetDate changed to targetCompletionDate
• backlogType was removed

Iterations

• lastUpdatedDate was added
• sprintScheduleId changed to schedule
• stateId changed to state
• velocity changed to overrideVelocity
• typeId changed to type
• owner was removed
• ownerUid was removed
• weather was removed
• isTerminated was removed
• used was removed
• goalState was removed
• teamCommit was removed
• notes was removed
• used was removed

Detailed API 2.0 error responses

When complex queries return just an error status response, there is little to no information to help identify the actual issue. Now, the error responses include details of the actual issue.

For example, the following is query will execute successfully:

/rest/align/api/2/cities?filter=contains(title,'x')

But with a simple typo in the property name:

/rest/align/api/2/cities?filter=contains(titlez,'x')

The API used to return just the error status:

400 - Bad Request

Now, the API will return a detailed response with the status:

400 - Bad Request
Cannot find cities. Could not find a 
property named ‘titlez’ on type ‘City’.

Defect Fixes

Below is our upcoming release schedule. Sandbox and production environments will be unavailable during our maintenance window, which starts at 11:00PM EST on the day listed below and ends at 2:00AM EST on the following day.

Release tracks

By default, production environments are set to use the bundled release track, while sandbox environments (previously known as test instances) use the continuous track. We recommend using this default setup for your environments, as it allows you to test new features released in a .0 feature release for two weeks in your sandbox environment. Those changes will then deploy to your production environment in a .2 maintenance release. 

You may change the release track from bundled to continuous in your production environment by submitting a request to our Support Team. Note that we do not guarantee a timeframe to make a release track change, but will strive to complete the request as quickly as possible. 

Jira Align's Enterprise Insights (EI) was updated and deployed to test instances running version 10.95 on June 5, 2021, and will be deployed to production instances on June 12, 2021. The following enhancements were made:

• Release highlights
• New tables
• Updated tables

Release highlights

• Work Item Health Status added to capabilities, features, goals, themes, and theme groups.
  • Health Color Code (green, orange, or red) and Reason Text for Budget, People, Quality, Risk/Issues and Schedule added.
  • Health Status History added to capabilities, epics, features, goals, themes, and theme groups.
• Work Item Roadmap Health Status added to features and themes.
• Audit Log Detail added to the Role object.
• Status Report Notes column added to features.

New tables

Updated tables

Note: This article has been republished in order to provide notification emails to users subscribed to announcement updates, and to give additional visibility to the change in this feature’s release schedule.

The Jira Align Product and Engineering teams have decided to reschedule the release of new financial calculations. The release will take place in version 10.98.0, which will be deployed to the continuous release track, primarily used by sandbox environments, on July 16, 2021. Production environments on the bundled release track will see the features deployed in version 10.98.2 on July 30, 2021. This decision was made for a few reasons, all to ensure we deliver the best experience possible:

• Continue our work to confirm that the new calculations are performant across all types of data sets in Jira Align.
• Provide all users with sufficient time to prepare for these changes.
• Adapt to the recently announced changes to our release cadence.
• New! additional features:
  • Spend panels that inform you how estimations and child work items contribute to a Forecasted, Estimated, or Accepted Spend value.
  • Program and team-level Spend per Point reports, which surface any outliers in the team data that could skew financial values.

The Jira Align Product Team could not be more excited to roll out some major changes to portfolio-level work financials. Here are the highlights:

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.

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.

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.

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:

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.

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.

New panels and reports

Because we know you care about how these values were calculated, we're introducing spend panels for Forecasted, Estimated, and Accepted Spends. You can access a panel for an epic, capability, or stand-alone feature by clicking the relevant value from pages like the Portfolio Room:

And because Spend per Point values are the building blocks to calculate work item spends, we're introducing the Spend per point report, which will show you outliers that could be affecting a team or program's Spend per Point:

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.98.0:

• 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

With the Jira Align 10.97.0 release, the release cadence will be changing, and so will our Help Center! We’ll be restructuring the What’s New? category to split one Release Notes section into three:

• The previous 10X: Release Notes section is becoming the Main Release Notes section. Get updates about new features coming to Jira Align. These articles contain compiled information on a Jira Align version, initially published for the 10.X.0 feature release and updated each additional release through 10.X.3.
• We’re adding a new Supplemental Release Notes section. Subscribe to this and the Main Release Notes section to get weekly notifications whenever Jira Align updates. These articles contain information on individual maintenance releases, published each release from 10.X.1 through 10.X.3.
• We’re moving Enterprise Insights release notes to a new Enterprise Insights Release Notes section. These are release notes specific to Jira Align Enterprise Insights (EI).

These new sections will become available with the 10.97.0 release on June 18, 2021.

If you previously subscribed to the old Release Notes section, you’ll be automatically subscribed to the new Main Release Notes section. However, you will need to subscribe to the Supplemental and/or Enterprise Insights Release Notes sections if you’re interested in receiving updates about articles published to those sections.
For more information about how to subscribe to these sections, check out our Sign up for real-time release note notifications article. You can also find out more about the release cadence change here.

In anticipation of the new financial calculations coming to version 10.98, we want to ensure you're set up for success! As we all know, any calculation is only as good as its inputs. To ensure that Spend values in Jira Align are calculated as intended, follow the data hygiene checklist below to ensure that your data is up-to-date for the work items and program increments you hope to report on.

Note that because new financials introduce the concept of baselining historical data (so that calculations do not roll), we advise that all these steps are completed prior to the release of 10.98 on July 16, so that the first set of calculations you view are accurate.

Allocations

1. Check that your teams have the proper allocations:
   1. Allocations for agile team types are collected from the sprint allocations set on sprint Details panels.
   2. Allocations for kanban team types are collected from the general team allocations set on team Details panels.
2. To automatically sync both scrum and kanban allocations for team members working in Jira, ensure that the Jira settings toggle Allow Jira to add users to team if they belong to an issue is switched on.

Story assignments

1. For agile teams, check that accepted stories have effort points and are assigned to sprints. If any accepted stories are assigned to the unassigned backlog, they will not be included, as Spend per Point is associated with the sprint a story is accepted in.

Costing method

1. Check your global and portfolio settings for which costing method will be used. This is the setting located at Admin > Platform > Portfolio > Costing Method. There, each portfolio can select whether to calculate spend values using rates from the cost center, or from the program increment's blended rate.
2. For the costing method you choose, be sure there are corresponding values entered:
   1. When using cost center as the method, ensure that users are assigned properly to cost centers and that each cost center has an up-to-date resource rate. This can be done in Admin > Cost Centers.
   2. When using blended rate as the method, ensure that each program increment you want to report on has a blended rate entered in the PI's Details panel. 

You can subscribe to three Help Center sections to receive notifications the instant release note articles are published:

• Main Release Notes: These articles contain compiled information on a Jira Align version, initially published for the 10.X.0 feature release and updated each additional release through 10.X.3.
• Supplemental Release Notes: These articles contain information on individual supplemental releases, published each release from 10.X.1 through 10.X.3.
• Enterprise Insights Release Notes: These articles contain release notes specific to Jira Align Enterprise Insights (EI).

We recommend subscribing to both the Main and Supplemental Release Notes sections to get weekly notifications on the latest Jira Align version.

What you need to do

To receive real-time release notes publication notifications, you'll need to create a Help Center account and follow the section or sections you want to receive notifications about. Please note, this will most likely be a different username and password than your Jira Align and Atlassian username and password. 

 To create an account (or reset your password if an account already exists), click the SIGN IN button on the Help Center (see the pink arrow).

Next, click the Sign up link, enter your name and email, and then click the Sign up button. You'll receive an email to finish setting up your account. If you receive a message that says a user has already signed up with the given email, click the Forgot my password link to reset your password.

Once logged in, from the Help Center home page, click the WHAT'S NEW section (bell icon).

Then click the header for the section you want to follow. Finally, click the FOLLOW button and then the New articles link.

That's it! As soon as we publish new release notes, you'll receive an email notification with a link!