Additional information about Story Points versus Story Point Estimation fields

Leigh Bingham

We have a JIRA cloud instance with dozens of shared-configuration projects to support shared processes; some people are starting to make use of the next-gen project types.

The fact that there are now two fields for story points is enormously troubling. We use story points for many things, and have no room for adjusting a well-tuned process to accommodate something silly like *the same data being held in two different fields*. 

Also troubling: at least one user is is seeing the new Story Point Estimate field when using the new *view* on a *classic* project. In other words, the actual value is in the database in the Story Points field, but the user is seeing it as Story Point Estimate in the browser. 

What is the rationale for two fields in an instance that mean the same thing? What is the recommendation for managing this? This has proven to be disruptive already, so I'm hopeful I'm misunderstanding something here and won't have to start doing ridiculous things like copying field values from one of those fields to the other every time either of them changes.

Andy Heinzer

Hi Leigh,

You are not the first to notice this additional story point field that exists in next gen projects.  There has been a suggestion ticket about this problem over in https://jira.atlassian.com/browse/JSWCLOUD-17173

In the comments of that issue, one of the product managers provides a more detailed explanation about why this has happened:

Hi Ivan. Sorry for the delay in responding. Also apologies for the confusion this has caused you. I'm a product manager working on next-gen projects and I was involved in making this decision. It's a bit of hard to explain problem but I'll do my best to be transparent about why we have taken the step to create a new story points estimate field.
Within Jira, certain fields behave in different ways. This is in part due to experience requirements and in part due to technical restrictions at the time a field would have been created. The existing story points estimation is what we call an unlocked global field. The fact is is unlocked allows users to modify/remove this fields as they see fit. There are also restrictions on this field as to what issues types it can be included on (which can be circumvented by custom field contexts but this all gets very complicated). There were also considerations around default values with a locked vs unlocked field type.
For next-gen we've decided to start fresh and make this a locked global field, and to fix the limitations with the product that didn't make this an option at the time the story point field was first released.
Now unfortunately as we wanted to get story point estimation out as soon as possible this puts us in a short term situation where we have two similar fields that can cause confusion for admins.
In the medium term, we will look to consolidate the existing story points field into the new story point estimate field - it's not an insignificant task however so we are bundling this with a broader set of migration tasks where we will provide users with a migration style wizard to allow them move from classic projects to next-gen projects (if of course they want to move).
In the meantime, we'll look at whether we can provide any additional clarity within the product to try minimise confusion.
I hope this helps.
Cheers