Hello all,
Thank you for watching, voting, and commenting on this ticket.
We understand that having the two fields that are conceptually the same thing is easily confusing and an undesirable experience.
As this ticket is a duplicate of JSWCLOUD-17173, we are closing this ticket so that we can aggregate the feedback on a single ticket.
Cheers,
Emily Chan
Product Manager, Atlassian.

P.S.: if you’d like to understand the cause that led us to having these two fields, please see this earlier comment.

Greetings, and a suggestion to Atlassian product managers/champions:

Please remember to consider: valuable, usable, and feasible when selecting features.  A data modeling conversation may have uncovered earlier the potential technical and usability problems with having two attributes for the same piece of information.

Thanks!

Thanks adkolhekar. We'll most likely look to do a migration of data to the new field rather than looking to make the two fields work together. This is on our backlog and something we will resolve - although it's unlikely this will be in the very near term. Apologies for the inconvenience in the meantime.

Hi Eoin,

My organization has a use case where this two field separation is causing a bit of a problem: 

We have a classic scrum project with a "master" sprint board that shows issues from multiple other projects. One of the projects is a Next Gen Scrum project. We are able to set the story point estimate in the next gen project issues, but since Story Point Estimate is a different field in the next-gen project, they don't show up in the total estimate on the scrum project that contains the "master" sprint board. 

If both Story Points and Story Point Estimate fields could be considered when totaling up the story points that would be perfect! 

Best,
Aditya

Hi Eoin,

Thank you for the detailed explanation. If I understand correctly, the main reason behind introduction of this new field is that you wanted a locked Story Points field and rather than converting Story Points to locked in all existing Jira instances already using it, you have opted to add a new custom field called Story Point Estimate, thereby creating some technical debt (by duplicating fields) to be dealt with at some point further down the line.

Is there a ticket already logged to ultimately merge these fields? And if not is this something that can be logged now as a placeholder, as currently I see no open tickets addressing this duplication problem.

Regards,

Ivan

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

I cannot understand the rationale behind the introduction of Story point estimate. Atlassian's justification for adding this field is:

For the Jira admins out there: When you navigate to the issue type configuration screen, you might notice that there will now be two Story point estimate fields when you do this. This is because one is for classic Scrum/Kanban projects, and the other is for next-gen Scrum/Kanban projects.

Suggesting that the addition of this field was necessary for next-gen projects, but why when there is already a field of the same type, description and used for the same purpose? Atlassian did not create duplicates of other fields that are used by classic project templates (like priority, summary), so why create a separate one for Story point estimate??

The original Story Points field was introduced by Atlassian some time back, this field is created by Jira Software OOTB. Recent introduction of Story points estimate, is a duplicate of the original Story Points field. I can see from the Custom fields page this field has more or less the same name, exactly the same description, type and seem to have been created with the same purpose in mind.

PS given this duplication was introduced by Atlassian themselves, I would hope to see explanation of why duplicate field has been introduced, so far I have not seen reasonable justification from Atlassian as to why a duplicate field was introduced.