Just a heads up: On March 24, 2025, starting at 4:30pm CDT / 19:30 UTC, the site will be undergoing scheduled maintenance for a few hours. During this time, the site might be unavailable for a short while. Thanks for your patience.
×I am playing around with Kanban capacity planning visualization in Advanced Roadmaps and it looks like that instead of spreading the estimated hours evenly across the iterations (ie. weeks) between start and end date, Advance Roadmaps always assumes 100% of the capacity per iteration up until the last, when it all piles up and turns red.
Is there any way to have this show similar to eg. BigPicture? There I could immediately see, if a task is overloading a team and how allocating more time could make it feasible. Am I missing something (or even the point) here? Thanks in advance!
The behaviour you've described is the way that we currently expect Advanced Roadmaps to work, and unfortunately there's currently no way to configure this to spread the capacity evenly among the sprints.
That being said, this behaviour was actually raised internally by one of my colleagues recently as behaviour that's unusual, so I can confirm that this is on our radar and we certainly agree it could be better! At this stage I can't make any assurances that this will be worked on in the short term, but having feedback like this does help us prioritise our work.
Sorry I can't provide any better solution at the moment! Do feel free to reach out with any further feedback or questions you have about Advanced Roadmaps though.
Cheers,
Daniel
Many thanks for your feedback! Appreciated to hear it straight from the team, as this will help to manage customer's expectations towards the available options.
I have opened a Feature Request in the meantime via https://jira.atlassian.com/browse/JSWCLOUD-23210 to see if there is more interest for this potential change in the community, but will mark this as answered for now.
Thanks again and kind regards
Fabian
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Prior to Advanced Roadmaps being rolled into JIRA, (when Roadmaps was a separate product) the feature worked exactly as desired... We used it for capacity planning and forecasting. When we created a new project and added estimated initiatives for each team it would show places in the timeline where the effort would exceed certain teams capacities.
Now that we are looking at moving to 9.2, we see this 'new functionality' as a regression that will break our planning processes. This prevents us from moving to 9.2 and will keep us on an older version until this is resolved (even though I know Atlassian does not see it as a regression)
JIRA 8.13 Roadmaps
JIRA 9.2.0 Roadmaps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
A quick follow-up... not sure if this fixes for everyone, but I found a checkbox that turns off this "feature"
I am using 9.2 Data Center
Administration -> Manage Apps -> Advanced Roadmaps Early Access Features
Uncheck "Enhanced capacity distribution"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You're going to even more disappointed when you're forced to move to Cloud. There isn't an option to have the more expected load leveling views like Chris pointed out. It just dumps all of your overruns to the end and is just like "bad news, this last sprint overruns by something like 400% but I couldn't tell you why or where the problem happens."
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We would also love to do this, and are surprised by the pre-set allocation logic for the same reasons as Fabian.
Roger
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.