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.
We’re making a big change to estimation systems and conversions in the release of version 10.104.0, which will be deployed to environments on the continuous release track on January 7, 2022. Production environments on the bundled release track will see this change in version 10.104.2, which will be deployed on January 21, 2022. Please read on if you manage or support estimation activities in Jira Align, especially if you use our Jira Software connector.
- Current estimation systems
- Changes we're making
- Examples of how data may change
Current estimation systems
Today, there are a total of five different estimation systems in Jira Align for estimating the effort needed to deliver features, capabilities, and epics:
- Weekly systems:
- Team Weeks
- Member Weeks
- T-Shirt sizing
- Point-based systems
- Open Text Field
- Power of 2
This can quickly become unruly and confusing when the platform is converting these values to generate outputs for key calculations like Program Increment Load, which is displayed on the Backlog page, Program Room, and more.
Changes we're making
After a review of our estimation systems with customers and our Customer Success teams, we have identified an opportunity to reduce estimation complexity, and also better align with Jira Software. We will be removing the Fibonacci and Power of 2 point-based options. These systems are comparative systems, which are better suited for prioritization.
▾ More on Prioritization vs. Estimation (click to expand)
Prioritization is the task of stack ranking opportunities and work to inform broad-stroke, and often initial, decision-making oriented around moving (or removing) items through a flow. Asking if feature A is larger than feature B is helpful in this exercise to weigh the overall value; think of prioritizing with a framework like WSJF. This is where comparative systems shine: Feature A is 4 points and Feature B is 2 points.
Estimation is the task of sizing work, specifically to weigh supply vs. demand. Saying Feature A is larger than Feature B is not helpful in this context if the capacity available can only complete a small part of either feature. This is where comparative systems become ineffective. We recommend using a system focused on effort for estimation: Points, Weeks, or T-shirt size*.
*Note: T-shirt size is a unique system that overlaps both prioritization and estimation, depending on your mental model. T-shirt size is a great system to inform initial prioritization. Yet, often, most teams also associate an effort estimate to those sizes, such as a Small size equaling approximately 20 member weeks. For this reason, T-shirt size will continue to be available, and converted into Weeks using the Estimation Conversion Settings panel in Administration settings, which will support forecasting efforts.
With the release of 10.104.0, Fibonacci and Power of 2 will be removed as estimations systems for features, capabilities, and epics. This affects the Display Estimates In setting found at Administration > Platform > Portfolio, which displays when Points is selected in the Estimation System setting. The Estimation Conversions menu will also have these two options removed. However, you will still be able to use Fibonacci or Power of 2 numberings when performing WSJF prioritization, and when estimating stories.
If you are currently using either of these options, your estimation settings will be changed to Open Text Field, and any values you’ve previously set will be retained. If you have estimated a feature as 2 Fibonacci points, after this change that 2 will be retained, but as Open Text Field points, or simply, Points.
The Points system aligns with Jira Software’s offering for point-based estimation. Jira Align will continue to treat these points in Align as an equivalent metric to story points in Jira. In the past, a Fibonacci or Power of 2 value would be converted when syncing a feature estimate from Jira Align to Jira. Going forward, any point values in Jira Align will simply be treated as story points, and will not be converted when syncing.
Examples of how data may change
Expand each of the sections below to see more detail on how data may be updated automatically after these changes are released.
▾ If you use WSJF as your primary estimation system (click to expand)
Because we are transitioning WSJF from an estimation system to a prioritization system, your financial value calculations may be affected if your portfolio settings have WSJF listed as the primary estimation system. Let’s look at how a financial value that uses a feature's estimate would update.
Data before the change:
- Estimation method is WSJF, using Fibonacci numbering:
- Admin > Platform > Portfolio > Use WSJF with Other Estimation Techniques setting is No
- Admin > Platform > Portfolio > Estimation System setting is WSJF
- Admin > Platform > Portfolio > Portfolio Specific Configuration > Story Points System setting is Fibonacci
- Feature A has a WSJF value of 20
- The Program Spend per Point for Feature A is $100
- Estimation Conversions for Fibonacci are set such that a value of 20 is converted to 200 story points
Results: WSJF value of 20 is converted into 200 points. 200 points * $100 Program Spend per Point = $20,000 Estimated Spend.
Data after the change:
- Estimation method is Points (Open Text Field):
- Admin > Platform > Portfolio > Use WSJF with Other Estimation Techniques setting is no longer available
- Admin > Platform > Portfolio > Estimation System setting is Points
- Admin > Platform > Portfolio > Portfolio Specific Configuration > Story Points System setting is Fibonacci, however, note that this setting is used for WSJF prioritization and the estimation of stories. It is not related to the estimation system used for features, capabilities, and epics.
- Feature A’s former WSJF value, 20, is migrated to the Points estimate field
- The Program Spend per Point for Feature A is $100
- Estimation Conversions for Fibonacci no longer exist
Results: Estimate value of 20 points is found on Feature A. 20 points * $100 Program Spend per Point = $2,000 Estimated Spend.
After the changes, you will be able to add WSJF Prioritization as a field in Details Panels Settings for features, capabilities, and epics. WSJF options will no longer be available in Admin > Platform > Portfolio settings, as it can no longer be selected as an estimation system.
▾ If you use the Jira Software connector (click to expand)
If you integrate with a Jira Software project and have configured the connector to use T-shirt Size estimate and/or Points estimate fields, note that your feature estimates may be converted and updated between Jira and Jira Align automatically.
Point sync direction and conversion are controlled through the Enable feature point sync setting found at Administration > Jira Settings > Jira Setup.
If the setting is set to No, point values synced are only synced from Jira to Jira Align, and will not be converted. 5 points entered on a Jira epic will sync as 5 points on a Jira Align feature. If Jira Align is using an estimation system not based on points, such as t-shirt size or team weeks, those fields will not be updated or converted during sync. Changes made to points in Jira Align will not sync back to Jira.
If the setting is set to Yes, point values synced from Jira to Jira Align will be treated like other estimates, which are converted automatically, behind-the-scenes. This automatic conversion will let you easily change your estimation system in Jira Align and see updated values instantly, without waiting for large amounts of data to process. Conversions are done using your settings in the Estimation Conversions menu.
Since there’s no matching conversion menu in Jira, an initial estimate you’ve entered could be overwritten after data syncs round-trip. This is because point sync is bidirectional when enabled, while t-shirt size is a custom field that only syncs in a single direction, from Align to Jira. Consider the following scenario, which could occur after we release these changes:
Settings for an epic issue type in Jira:
- Story Points field set to 20 points
- T-shirt size field set to X-small
- Both Story Points and T-shirt Size fields are configured in the Jira connector
Settings for a feature work item type in Jira Align:
- Estimation system is set as Points
- Estimation Conversions settings between points and t-shirt sizes:
- 10 points = X-small
- 20 points = Small
In this example, when a new epic is created in Jira with 20 points in the Story Points field and X-small in the T-shirt size custom field, a matching feature is created in Jira Align. That new feature will initially have the primary points estimate of 20, and a hidden t-shirt size value of x-small, matching Jira (the t-shirt size value is not visible in the Jira Align interface because it is not the selected estimation system).
Jira Align intakes the point estimate of 20, and using the Estimation Conversions menu, converts that 20 into a t-shirt size of small. The t-shirt size is updated in the Align database to small.
When the new Jira Align feature is updated – by editing another field – it is added to the sync queue. The correct conversion from 20 points, a small t-shirt size, is synced back to Jira software, overwriting the original value of x-small.
This change to Jira points or t-shirt size can happen with any estimation system used by Jira Align. As another example, if you use team weeks as your Align estimation system, but sync back points to Jira through the Enable feature point sync setting, changing the team week estimate on an Align feature would update the points set on the matching Jira epic, according to your Estimation Conversions settings.