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
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
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
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
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
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
Thanks a lot for taking care! I wish you merry christmas holidays and a a happy new year!
Best regards, Alessa
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
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
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