Story Points not showing up in Issue Navigator or export, but shows up in Configure Columns?

[Woody Arnold]

I've seen this question posted under Documentation but have not seen an answer. The Story Points field is not showing up in Issue Navigator (or export), but shows up in Configure Columns? (You can even see the point values of the first few records in this view.) But when you go back to the Issues Navigator the Story Points field does not show up. Also, if you choose either the All or Current Fields export, the points field does not come through. Points otherwise work normally. They show up in burndown charts, velocity charts, appear on cards etc. Points are not applied to all issue types (just Stories, Epics and Bugs). We're on Jira 5.1 and GH 6.0.

[Woody Arnold · Accepted solution]

Wow. You were correct. I had to explicitly add issuetype = "Story" into the query, even though the issues had points, the field wouldn't appear until I explicitly added the issuetype into the query string. (Seems like a bug to me...)

[Nic Brough -Adaptavist-]

My first guess is that your Story Points field only has a context for certain issue types and/or projects, and your filter might return issues that don't have story points. Annoyingly (but explainable, sort of), the issue navigator won't show the column in those cases.

Try a simple search that only returns one project and issue type (and make sure one of your issues has it)

[Nic Brough -Adaptavist-]

It's by design, and I questioned it when I first saw it. I understand the reasoning that Atlassian ran through with me, and it makes sense.

But I still disagree with it, simply because it makes no sense to anyone who hasn't been doing this for <mumble> years and even though we might understand the logic, it's still instinctively wrong.

Not a bug, because it's behaving as designed. But it's definitely broken.

[Karie Kelly]

I honestly have never understood the reasoning and have had to remove all issue type contexts because of this problem. Consequently, we get no value out of this feature in which we could receive lots of value if it weren't for the reporting. If they allow this feature and allow cross-project/issues type filters, other programs simply show the column but have no value since it is not applicable for that record.

A user has NO IDEA what fields are valid for each issue type -- and they shouldn't. This feature should help the administrator implement what makes the most senses and easiest for the end user. That is why I originally used the feature. But because I received several questions every week about why they couldn't see or export specific fields, over many months and even after explaining the 'why', I finally removed all of my issue context implementations.

We have similar reporting in our products -values specific to certain features or modules. But, reporting doesn't care and doesn't expect the user to know what is valid or not valide for those features. If there is no value for the field because the field doesn't exist, we dipaly nothing or a null value.

[geoffrey emery]

i am still having issues with this. i can acualty see the story point in the issue navigator configure columns page but when i switch back nothing is there.. even after i do whats stated above the best part is i can filter by story point and specify a number (1,2,3,5) but i can actually see the numbers

[Karie Kelly]

Do all issues in your filter criteria have the story point field enabled for them? You might try selecting issue types that you know story points is associated with them and see if you still have the problem.

[Rainer Burgstaller]

I too have exactly the same problem. My query is like this

project = myproject AND status != done AND labels in (mylabel) and issuetype = story

The project has jira agile enabled and story points show up for all issues of "type = story". Therefore, I am at a loss of whats wrong.

we are using JIRA v6.0.6#6105-sha1:9713ad1

and jira agile 6.3.9

any help would be highly appreciated.

[Akshay Mathur]

Here is the hack, add the line below to the end of your query and it will start to show story points for all issue types.

AND ("Story Points" is EMPTY or "Story Points" is not EMPTY)

[Rainer Burgstaller]

the workaround does not work for me :(

[Bob Hunt]

The workaround works great for me! Thank you Akshay!

[Jon Lykke]

Doesn't work for me either.

[Gary Pyne]

Sometimes it doesn't work due to story points not being selected (i think). Using the below instead should work if the above does not.

AND (issuetype = "Story" OR issuetype != "Story")

[Booster]

So after running through everything previously posted here, I found that if you go to your project settings  > Fields > In the top right click the "(gear) Actions" dropdown and select Edit Fields > scroll down to Story Points and click "Required" on the right for Story Points > Go back to your Projects backlog and try and create a new issue, it will bring up the full edit for an issue and yell at you for not having a story point value. Go ahead and enter a value and then create the issue. You will now note that it shows the story point value both on the issue in the backlog and in the info panel on the right for the issue (click on the issue to see this). Now you can go back and change Story points from Required to Optional and all future issues will have story points as an editable field on the right-hand info panel.

[Ralf Schramm]

For me, in Greenhopper V6.2.3, this issue is still existing. If you view Stories within the issue navigator for a RUNNING sprint, the Storypoints are show as a column. If you search Stories via issueFunction in inSprint("BOARDNAME", "SPRINTNAME"), the Storypoints are not shown. This is described in https://jira.atlassian.com/browse/JRA-29432 and is not resolved for my version. The above shown workaround, adding AND ("Story Points" is EMPTY OR "Story Points" is not EMPTY), does work for me.

[geoffrey emery]

For Online Version at least you need to make it global context for some reason even when i specified the project it was not showing

[Karie Kelly]

Yea, I finally had given up and had to remove all my field configurations to make them global because I kept running into problems as well as mass user confusion because they have no idea - with 40+ projects and 35 issue types, they never narrow down using issue type.