Hi to all,
we use the Roadmap pluging for work planning for a kanban team.
It is possible to set the team capacity and then the "remaining effort" field for each story in the plan. The Roadmap plugin distributes the "remaining effort" over whole planned time period for a certain story.
Expected behavior:
* remaining effort is distributed over remaining time (today until due date)
Observed behavior
* remaining effort is distributed over whole planned time (start date until due date)
** This is valid for "original estimate", but it isn't valid for "remaining effort"
Requirements behind my expectation:
* We configured the plan to show the available/planed capacity of a team in timeline. If we make no progress on a certain story, i.e. "remaining effort" is not changed, we need to do the remaining effort in a shorter time period for each day which pass by and no progress was made (the due date is fixed). That's why we expect to have the remaining effort distributed along the remaining time only.
* We always want to have an updated view on future workload in our team
Questions:
* Is my expectation correct? If not, why?
* Is it possible to configure a roadmap plan to fit to my expectation?
* Is there another way, to fulfill requirements described above?
Thanks in advance and best regards,
Alessa
Hi @Alessa Jaeger _LSY_ ,
Sorry for the late reply, I've just returned from leave.
I've responded to your last comment suggesting that a support ticket would be the best avenue for resolving this particular issue.
Thanks,
Angus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Alessa,
We've recently released a new capacity distribution algorithm that should address this issue for you. You can find the release notes here, but here's the relevant part.
Advanced Roadmaps for Jira - Better Kanban Capacity Algorithm
This update changes how Advanced Roadmaps allocates capacity to Kanban teams for issues that last longer than one week. Before, the capacity of an issue would be spread out evenly across all weeks. With this update, issues will now consume the remaining capacity of an iteration before consuming capacity from next one. For example, if you have an issue that takes 40 hours over the course of two weeks, instead of allotting 20 hours per week, Advanced Roadmaps will now assign as many hours as possible to the first week, then place the remaining hours in the second.
To learn more about this change, see the Understanding team capacity documentation.
The release notes don't mention anything about capacity being distributed into the past as you're describing, but that is addressed with the new algorithm. Essentially this update brings the Kanban capacity distribution algorithm inline with the Scrum version.
It sounds like you don't have this update yet, so I assume your organisation is enrolled in Release Tracks (bundled fortnightly product updates rather than continuous product updates). If that is the case, you should start seeing the feature between November 9 and November 11.
Please let us know if it doesn't meet your expectations.
Thanks,
Angus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear @Angus Russell ,
thanks for your quick answer! The release notes you are referring to are valid for Atlassian Cloud, however, we are working on Server (and will be migrating to Data Center at the end of the year) and I didn't find the addition made in the Cloud documentation in the Server documentation (3.28 and 3.29: "If a story spans multiple weeks, its capacity will be equally distributed among the weeks".). Is it only valid for Cloud or was the new algorithm also rolled out for Server?
Thanks and best regards,
Alessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Alessa,
Sorry, for some reason I assumed you were on cloud.
The change is not rolled out for server or Data Centre yet. It's on our roadmap, but unfortunately we don't currently have any ETA for when it will be available.
As a temporary workaround, you could try setting the team to be a scrum team. The scrum capacity algorithm on server is more advanced than the kanban capacity algorithm.
Thanks,
Angus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear @Angus Russell ,
okay, we will see how we get it to work for us - thanks anyways for the infos and the suggestion! I will try to stay up-to-date on this issue and am looking forward to the new algorithm.
Best regards, Alessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear @Angus Russell ,
I tried the proposal, to configure team as Scrum team. It seems, that the capacity calculation works different. I don't know, if it works better, because another problem occurs then:
Is there any way to change that or get the information I need?
Thanks and best regards,
Alessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Alessa,
That's a good point, and I'm bringing it up with the product managers. We should show that information - either in the tooltip or in the flyout that opens when you click on the sprint.
The workaround is to actually create those sprints in Jira (go to the backlog tab and then click "Create sprint" for each future iteration you want to plan for). Then refresh your plan and you'll get a flyout like this one.
I'll also mention again that the improved capacity distribution algorithm for Kanban teams is coming to server at some point in the not-too-distant future. I apologise for all the necessary workarounds in the meantime.
Thanks,
Angus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks a lot for taking care! I wish you merry christmas holidays and a a happy new year!
Best regards, Alessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear @Angus Russell ,
we tested your suggestion with following example:
Initial state:
Sprint 1
Duration 31.12.2020 - 13.1.2021
Already allocated: 216,5
Sprint 2
Duration 14.1.2021 - 27.01.2021
Already allocated: 120h
Sprint 3
Duration 28.1.2021 - 10.2.2021
Already allocated: 252h
------------------------------------
Created New Story
Estimation 30h
--------------------------------
Szenarios
Changes in sprint allocation are underlined
a)
Duration 21.12.2020 - 13.1.2021
Sprint 1 Allocated: 246,5
Sprint 2 Allocated: 120h
Sprint 3 Allocated: 252h
b)
Duration 21.12.2020 - 14.1.2021 (until 1st day of Sprint 2)
Sprint 1 Allocated: 216,5
Sprint 2 Allocated: 136h
Sprint 3 Allocated: 266h (why sprint 3 is affected?)
c)
Duration 21.12.2020 - 14.1.2021 (until last day of Sprint 2)
Sprint 1 Allocated: 216,5
Sprint 2 Allocated: 126h (Why does allocation changed compared to szenario b) ? )
Sprint 3 Allocated: 276h (why sprint 3 is affected? Why does allocation changed compared to szenario b) ? )
Capacity allocation is even more intransparent compared to Kanban configuration. Bug or Feature?
Best regards, Alessa
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Alessa,
The scenarios you described do sound a bit funny. I'm not sure why sprint 3 would ever be affected (it shouldn't) unless maybe the issue has a sprint assignment to sprint 3..?
I'd suggest creating a support ticket for this as it's starting to sound like a bug - or at least something we could improve messaging and transparency for.
By the way, the improved capacity distribution algorithm for Kanban teams is planned to be released to Jira Data Center in version 8.16.
Thanks,
Angus
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.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.