I think this is a more of a bug than a suggestion.

In the backlog view, the bubble on hover says it's the Story Point value, but under Fields it is the Estimate toggle that turns it on and off. There is no way to say it should show Story point estimate.

I have the same use case (and problem) as @stefan-seervision. 

Is there any workaround for being able to have a backlog show story points from both company and team managed projects?

I had an automation to sync the two story point fields which was working fantastically! Until a week ago...

Now it gives this error:

Action details:Multiple issue events
Rule was triggered by event:com.codebarrel.automation.trigger.multiple.created
Edit issue
Could not find your configured field, it may have been deleted, or may need to be added to the project "Story Points"
No fields or field values to edit for issues (could be due to some field values not existing in a given project):ED-2184 

iteong, With Team Managed projects getting official support in Plans (Advanced Roadmaps), and the Plans supporting a harmonized Story Points column, can we expect this same level of support in the backlog and reports soon? 

Is this going to be worked on? There's no documentation covering the difference between these fields, and responses from Jira support in forums are conflicting and contradictory. If the recommendation is to use the Story Point Estimate field, why doesn't it show up in any of the issue lists of sprint reports?

you know, Atlassian, be agile... get a way to display SP across projects, really... Your "workaround" does not work anymore.

It's impossible to have a company managed project that contains tickets that are also in a team managed project and for reporting to work or for boards/backlogs in the company managed project to show story points (because they are story point estimate in team managed project). Really unhelpful. Considering migrating team managed projects to company managed projects to resolve it

Is this issue being worked on?  We ran into this problem in sprint 1 of our next gen project.    Is there a documented workaround?

Greetings!

If this is ever fixed...please lean way forward to notify customers, as this has the potential to break automation for Jira rules and REST API users.  Some automation rules could be automagically fixed by coalescing these fields, but other rules which handle both CMP and TMP projects could not; those will require customers to manually update and test rules.

Thanks, and kind regards,
Bill

We have the same issue and would love to see a fix that there is only one Story point field and those points can be calculated and processed as one.

Hi guys,

I have the same issue. I've got two projects (one classic, one next-gen). I want to have one board and one backlog for both projects, so we can plan better. We use the field 'Story Point' for issues in the classic project. However, this field does not exist for the next-gen project. So there is no way to sum up the estimates of issues of both projects.

I'd expect that issues from the next-gen project also have a field 'Story Point' that is used in the common backlog and sprint board to show the total 'Story Points'.

Best regards,

Stefan

Hi, Jira team! 

The issue with Story Points field is very important to be fixed as I can't see Sprint reports. 

My classical Jira Cloud project has next-gen view, which deals with Story Point Estimate field, but reports use Story Point field that is not displayed in the next-gen view (in tickets).

It would be great if you unite these 2 fields into one or let Jira users somehow merge their values.

Thanks,

Stanislav

Is this issue likely to be resolved in the near future ? We discovered the problem today and now we're moving back to classic projects, but had hoped to use next-gen. If this is going to be resolved in the near future, i wonder if we should hold off.

The Expected behavior is wrong.

I would expect to have JUST ONE Storypoint field and can USE IT CONSISTENTLY ON BOTH TYPE OF BOARDS

Otherwise, the projects are incompatible and most features (Epic Progress, Stp Sum in Epic,...) as well as cross project reporting etc. is not working.

Currently, in my old-gen project, in each standard type form, I have two fields that each say:

STORY POINT ESTIMATE

and 

STORY POINT ESTIMATE

Is this the behavior you are describing here? It seems like you are talking about a version that is not what is in production. 

And i really cannot tell which field is being used for reports, portfolio, for roll-up from sub-tasks to stories to epics and so forth.

so this thing you did (could you not have named them at least 'new' and 'old'? and renamed them in all the forms? but probably you couldn't find anyone who knew which was which in any but the one place you changed them) has made it impossible for me to get a complete implementation working for the THIRD TIME in four years of trying to get this put together!

How can you conscientiously put out advertising and documentation, youtube videos and all else claiming that this application is usable at a small business level, much less an enterprise level!>??>Dljhladc:
You guys spend time thinking up new crap, can't you just get one thing working all the way? And document it accurately all in one place instead of telling part of the story here and then some more over there?  or where?

Now I have to go back to using it as a stinking big spreadsheet!!!

OHHH!!! maybe the difference is that your ungainly field management logic is confused in certain forms, or in everywhere you didn't look for requirements, so its just putting up a field label that is associated with the metadata where you didn't have time to verify it?

But... of course, the actual values aren't showing up in the right places and I can't tell whether any calculation is accurate.

And I'm trying to just get a couple projects with real data into portfolio in a repeatable, well-defined manner...

What the HECK!!! Why are you messing around like this?

Hi Eoin, no objections to using this ticket, just wanted to ensure this issue is tracked somewhere to be resolved. Thanks

That's a good summary Ivan! We don't have an externally facing ticket to deal with it as this will be part of our internal roadmapped work. Any objections to us adding to the description of this ticket and keeping this open for tracking?

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'm with Ivan on this one and believe that this isn't a "Suggestion", but rather a "by design defect" that is causing much confusion. Also, in the new view of cards on the board, the field name is called "Story point estimate" even though the actual populated field is "Story Points". This seems like a labeling issue that needs to be corrected 

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.