Announcing Upcoming Enhancements to Estimation Conversions

[#1]

We are very excited to roll out some big changes to the Estimation Conversions settings menu. Many of you have voiced concerns that one estimation conversion for all types of work items is an inhibiter to improving estimation fidelity when planning. We agree.

Background

For those unfamiliar with the estimation conversions functionality, here’s a quick recap. In Jira Align, there are three main estimation systems that can convert values between each other: Weeks (which have Member Week and Team Week variants), Points (which have Fibionnaci and Power of 2 variants), and T-Shirt Size. Portfolios select different systems to use as a metric for estimations.

Stories generally use a point-based method. Larger work items, like features and epics, use T-shirt size or week-based estimations entered as Member Weeks (the effort of one employee during a working week) or Team Weeks (the effort of one team during a working week). These larger estimation methods are helpful for understanding the general level of effort needed for delivery, prior to breaking down a feature into child stories.

Conversions are necessary, as not all calculations can use Member/Team Weeks as an input. Take Estimated Program Increment Load as an example. This calculation is displayed on the Feature backlog to help Program Managers understand if the program increment (PI) is currently underloaded or overloaded. Estimated Program Increment load is essentially estimated planned work divided by the predicted amount of work a program can deliver (aka Program PI Velocity). But! Program PI Velocity is measured in story points. For that reason, we must convert the weekly estimates entered on features into points.

That’s where the Estimation Conversions menu comes in. Found within Platform settings on the Administration page, organizations can set up conversions between estimation systems. Once the settings are saved, sit back and let Jira Align do the hard work of converting various calculations platform-wide based on your configurations.

What’s coming?

In the upcoming 10.85 release, which will ship to test environments on December 5th, 2020, we will roll out separate estimation conversions for epics, capabilities, and features, as well as a revamped settings panel:

The new settings use Member Weeks as the primary pivot for conversion into other estimation systems, as it is an easy concept to understand. Your teams, program leaders, and portfolio managers should work collaboratively to determine the following value:

How many points can one person, working for one full week, consistently deliver? 

Set that number as an organization-wide benchmark.

How will this affect current conversions in my environment?

At first, it won’t! All of your current configurations will be migrated over to the new panel for each work item level. When your team is ready to switch over to the new Member Week based conversions, your Jira Align admin can follow the steps listed below. Upon clicking Save, calculations in Jira Align that use conversions will be updated.

Note: While the estimation system used for point and week-based estimates can be set per-portfolio, Estimation Conversions are global settings that apply to all portfolios in a Jira Align instance.

How do I use the new conversion options?

Admins should perform the following steps once the new settings panel becomes available in their test or production instances to use the new conversion options:

Step 1: Select your work item level

Easy! Start by selecting the work item level you’d like to configure – epic, capability, or feature.

Step 2: Establish the primary pivot

Next, as a team, determine your Member Weeks to Story Points conversion. While this is specific to each work item level, it is the primary pivot used to generate conversions across each of the work item’s estimation systems (T-Shirt, Fibonacci, and Power of 2).

For example, if your team decides that 1 member week is equivalent to 5 story points, then 5 will become your multiplier used in the conversion table.

Step 3: Enter Member Weeks for each system

Within each system – T-shirt sizing, Fibonacci, Power of 2 – all you have to do is set your conversion to Member Weeks. The rest will automatically calculate on its own based on the following multipliers:

• 6 Member Weeks = 1 Team Week
• 1 Member Week = 30 Hours
• 4 Member Weeks = 1 FTE/mo (full-time equivalent per month)

Story points will also be automatically calculated based upon the value entered in Step 2.

Step 4: Save

Click Save to confirm the new conversions (once confirmed, old estimation conversions cannot be recovered).

Done! Check out the new estimations on the affected pages listed in the following section.

What pages and values are affected by Estimation Conversions?

Once set, you’ll notice calculation changes across the platform. Below are the key areas by work item:

Epics

• Epic Backlog Column View>
• Portfolio Room > Execution View
• Portfolio Room > Resource View
• Portfolio Room > Financial View
• Forecast

Capabilities

• Capability Backlog Column View
• Portfolio Room > Execution View
• Portfolio Room > Financial View
• Forecast > Agile by Program
• Forecast > Agile by Team

Features

• Feature Backlog Column View
• Feature Backlog list, step and state view
• Portfolio Room > Execution View
• Portfolio Room > Financial View
• Program Room > Program Increment Load
• PI Scope Change

Standalone Features

• Epic Backlog Column View (for standalone features)
• Portfolio Room > Execution View
• Portfolio Room > Resource View
• Portfolio Room > Financial View

[Richard Wilson _Jarow Digital_]

Kyle, how does this impact on Instances that use Points as their estimation system?

[Michiko Quinones]

+1 Richard.  SAFe suggests using points for epic estimation and many of our clients are using points. 

[Kyle Clark]

Hi @Richard Wilson _Jarow Digital_, are you referring to the Custom Points section that currently displays in the old version of the settings panel? 

If so, we will continue to provide a conversion for that value, which will display directly below the entry box for your Member Weeks to Points value. 

For example, if you enter 5 points in the box, you're stating that 1 MW = 5 points. The reverse calculation of that is that 1 point = 0.2 MW. We display both of those calculations below the value entered, and that is applied across the reports mentioned in the announcement. 

If that's not quite it, let us know!

[Michiko Quinones]

Hi Kyle, 

This configuration.  We have clients that are relying on this right now.   Note that when they use points/open text they essentially by pass the conversion table, so i'm guessing probably there is no impact. But want to confirm with you. 

Thanks!

Michiko

[Kyle Clark]

@Michiko Quinones I reviewed your question with the Product Management team and can confirm that your understanding is correct. When using the Open Text Field option in the Display Estimates In platform settings, the conversion table will not impact those values when running point-based calculations. 

[Michiko Quinones]

eggslent!  Thank you!

[Michiko Quinones]

Hi Kyle, 

As I mentioned earlier, we have a number of clients who prefer points/open text.  They use that for SAFe type estimation at the epic level.  They use the backlog at the epic level (column) to be able to see estimates impact for a few PIs out. 

I've noticed that with the change, the Epic Esimtations on the Backlog/Column view is now using the estimation conversion table. 

For those organizations that want to do SAFe without tshirts - ie points - this mean that they will have to go back to tshirts when they may already be at a process point using points.

Here is how that is showing up.  Both portfolios are points/open text. 

Appreciate your guidance. 

[Kyle Clark]

@Michiko Quinones , Thanks for reporting! I'm seeing two things:

1) Part of this is related to a change in how the Load calculations are done for each of those progress bars in the Column view of Epic/Capability Backlog pages. As part of 10.85, we corrected a few labels and updated calcs: 

The Estimated PI Load bar at the top uses the PI-specific Estimate fields from the main tab of an epic's Details panel to feed that calc, while the Estimated Program PI Load bar for each program uses the entries made on the Forecast tab. Our planned doc changes for backlog articles will call-out this difference, and I've updated the backlog changes section of our 10.85 release notes to be more explicit about the calc's sources.

2) I set up a scenario to match yours in a test system, and I am seeing a small inflation in points. Using the same estimation system, and putting 10 points on an epic, I'm seeing the top Load progress bar showing in the tooltip that 10.2 points are used for the calculation. I did a screen share with our product team, and they are treating this as a defect. I suspect that although point systems should bypass the conversions table, they are not, and a rounding error is being introduced when converting round-trip.

If you review the entries made in your epics' Details panels, inside the [Release/PI Name] Points: fields, does that match the sum displayed in the tooltip of the top progress bar? Conversely, do the bars for each program line up with entries made on the Forecast tab?

I'll post a new comment here once a defect is filed, so you may track progress. 

[Michiko Quinones]

Kyle,

Question from a customer - are you going to release to prod with this issue and fix it after the push, or are you going to address the issue before you push to prod. 

Thank you!

[Kyle Clark]

@Michiko Quinones , great news, this morning we were able to get confirmation from the development teams that this defect has been fixed in time for the next release! As a result, you will not see this incorrect behavior in the production release of 10.85 or test release of 10.86.