You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We use the Backlog view in JIRA Cloud to plan upcoming sprints. Until today, the number of issues planned for each sprint was correct, but as of today it seems to either be counting subtasks or something else, but the number has multiplied. I use these numbers to quickly report on Sprint progress each week, but now that it's incorrect I'll have to manually count the stories or find another way.
Does anyone know if this was a purposeful change?
Is this for a company-managed project or a team-managed project? You may find that information at the bottom-left side of the page expanding area.
When you expand those sprints, how do the listed issues compare to the count shown?
Has the board filter recently changed?
Hi @bill ! Thanks for answering. The issue is no longer occurring. But to answer, it's a company managed project, the issue counts did not in any way match when expanded, this is how I knew there was an issue, and nothing with the project, board, or filter had been changed. Must have been a temporary glitch.
I am glad to learn it stopped happening, and that is curious...
Do you have the "Enhanced board" feature enabled, as I have seen a few posts about changed / apparently broken behavior with that enabled?
I checked and did not see that symptom in the public backlog for defects, and so you may want to send this one to the Atlassian Support team:
If you are on a paid, Jira license, your Jira site admin can submit a ticket at that site.
Thanks for the update, @Jessica Ketcham
I hypothesize this will turn out to be a bad design choice, long-term, and will eventually require an option to enable / disable it.
The intent of the backlog is to help manage items which provide value and can be delivered to production. But a sub-task is neither of those things, and so will just make the work of product owners and teams more difficult...adding noise to their workflow.