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 have a dozen Themes, 45 or 50 Initiatives, and over 1000 issues on our Advanced Roadmap. Here are a few of my questions:
1. To show the Roadmap and only show the current Sprint, selecting the Sprints -> Current Sprints causes much of the Themes, Initiatives, and even some epics and issues to be display grayed out. Is there a better way to only show what is involved in the current Sprint and not show so much outside the Sprint?
2. I have tried to limit what would be displayed on the Roadmap with a Filter and adding it to the Issue Sources. I have a dozen different Scrum boards as issues as well. Does the filter work across all of the Issue Sources? If not, how does it work?
3. There is a debate on whether Target start and Target end dates need to be entered for issues below an Epic. I know you can inherit from the Sprint, but would it be better to enter the Sprint Target dates on all the issues, or is that overkill?
I'll stop here to see what wisdom you can share with me. Thank you very much!
Hi @Don Hames
Regarding 1. In the filters section (at the bottom) untick the "Show full hierarchy" box.
Regarding 2. Adding a filter doesn't filter the existing Issue sources, it adds another issue source. So by adding your new filter, you have just added everything that the filter retrieves into your plan. Each Issue source is....a source for adding issues to the plan. Think Filter Query for a Jira board, but 3 dimensional (i.e. Whole Projects, Boards or Filters)
Regarding 3. It is a fair debate....no perfect answer, so it depends on what you want from the plan, current team ways of working etc.
If all teams work in sprints, then perhaps sprint data is good enough. If not, then adding dates makes sense....though may well incur an overhead if teams are not used to adding such info currently.
Hopefully this helps?