Issues manually dragged into roadmaps are ignoring time estimates

[jbeg]

When dragging issue manually in the Roadmaps view the original estimates and rollup estimates are completly ignored.

Is there a configuration that I am missing? How is this a useful feature if you have to adjust EVERY single issue afterwards to the correct timeframe?

[Dave]

Hi @jbeg ,

There is no connection between the estimate and the start and end dates when you are manually planning (however if you use auto-schedule then those estimates will be taken into account to suggest new dates).

It sounds like you're expecting that when you increase an estimate that the end date of an issue should automatically extend?

We made a decision not to create that kind of implementation because we wanted to allow the user to retain in control. There are many reasons why there might not be a direct correlation between estimate and dates - for example, an issue might not be worked on continuously, an estimate of 4 days does not necessarily mean that it will be completed in 4 days time if someone is only working on it in parallel with other tasks. Maybe the assignee only works part time or has a planned absence? Similarly it might be possible to complete a task in less time if it is possible for multiple people to work on it.

At the end of the day we didn't want to build too many assumptions into the planning experience that might end up frustrating users. 

I hope this makes sense - very happy to discuss this further if you have suggestions or ideas about how you'd like to see this work though,

Regards,

Dave

[jbeg]

Hi Dave,

unfortunately, this makes no sense to me. The planning experience is frustrating as of now.

• The auto-planning feature utilizes the estimates - so far so good
• I do not expect the target/due date to change when the estimate changes - i expect to get a warning in the roadmap if the new remaining estimate is larger than the time until target/due date 
• It is not reasonable that the suggested timeframe in manual mode does not utilize the estimated time
  • it would be very helpful if the suggested timeframe matches the estimate. The user still has full control to change that. But using 7 days as a baseline for every issue is just bad design
• Jira does not support working with multiple assignee on one task. This argument makes no sense regarding estimated and dates.
• The old planning interface had an capacity view - this is completely missing
  • You mentioned parallel work - How can you see in the roadmap if an assignee has more work than his weekly capacity?
  • You mentioned part time work - This is not relevant for planning because the weekly capacity of the user already reflects that.
  • Why is there no warning when the remaining estimate is larger than the timeframe until target end/due date?
  • How can you plan for abscence of users or make the absence visible?
  • If not using the auto-planning feature, i dont see how we are supposed to see if an assignee can work on certain issues in timeframe x-y or if he is already assigned with too much workload?

The only thing you got right with the new planning interaface is the usability. But feature wise you made a huge step back. As of now, it looks to us that 3rd Party vendors like BigPicture or Structure offer a way more refined and feature rich plugin for less money than Atlassian is asking for Advanced Roadmaps. 

[Dave]

Hi @jbeg 

I’m genuinely sorry to hear that you’re frustrated by the current planning experience. We are working hard to ensure that it will meet the needs of our customers and your feedback is exceptionally helpful in that regard. While I cannot guarantee that we’ll be addressing your specific needs we are currently looking at capacity planning needs in general.

I do think it’s worth addressing a few of your points directly though…

using 7 days as a baseline for every issue is just bad design

I can’t be sure but I think that you're referring to the initial size of an issue bar when you first drop it on the timeline. However, we don’t default to 7 days - we default to the size of the timeline unit, so for example if the unit is months then the default length will be a month, if the unit is a week it will be 7 days. This design was chosen so that the default length of an issue bar would always be of a sensible size relative to the timeline scale. It means that when you drop an issue bar on the timeline it is manageable at the scale you’re looking at.

Jira does not support working with multiple assignee on one task. This argument makes no sense regarding estimated and dates.

This is true but you’re only considering a single hierarchy level. I can create a story level issue, give it a size and then create multiple sub-tasks to complete that issue - each of which could be worked on by a different individual. This would mean that multiple people are working on a single story at the same time. It’s true that you can’t assign an individual issue to multiple users through the assignee field, but you can use the Team field provided by Advanced Roadmaps to effectively achieve this.

The old planning interface had an capacity view - this is completely missing

We completely acknowledge that not all of the capacity planning features available in the previous interface are available in the new interface (and we are currently looking at the capacity planning features that we want to reintroduce). However at this point it’s worth bringing some historical context into the conversation…

Advanced Roadmaps was previously known as Portfolio for Jira and the old interface (known as “Live Plans”) was not as successful as we'd have liked. It is true to say that some of our customers found it to be a very powerful and useful tool but in truth these were a minority and we were actually losing some customers as a result of the complexity of the interface and the lack of control that it gave users over the generation of their roadmap. We re-wrote the interface entirely for the Portfolio 3.0 release (on Server) with a goal of making the interface simpler and easier to understand and giving the user more control.

This rewrite proved so successful with server customers that it has been subsequently brought to our Cloud platform, rebranded as Advanced Roadmaps. We acknowledge that there are still feature gaps in Advanced Roadmaps and continue to work hard to close them - however, when you undertake a major rewriting of a product it is always likely that some features will not make the cut and unfortunately capacity planning was one of those areas where we did not initially deliver as many features as we’d have liked.

We do understand that the changes that we have made are not to everyone's liking (especially those that have been successful with the Live Plans interface), however had they not proven as successful as they were then we certainly wouldn't have taken the time to bring the planning interface to Cloud (where it has also been well received) - you'll have to take my word on it that the majority of the feedback we've received regarding the changes has been positive.

Advanced Roadmaps does offer capacity planning at a team level (which you access when you update the view to group issues by team or sprint) and many of the features that you’ve mentioned are actively being considered for future development…

• At the moment we aren’t showing individual capacity and aren’t allowing it to be set - this might change in the future, it’s something we’re looking at (but Agile best practices suggest that a team centric view is better than looking at individuals, there are also ethical considerations about how much individual monitoring should be provided in a tool that we are thinking about
• Part time work does not necessarily just mean part time at the company - it could be part time across multiple teams, Live Plans allowed for that in an obscure way and we’re also looking at ways to address this in a more intuitive fashion 
• As mentioned elsewhere, we don’t consider the length of time to be absolutely linked to the start and end dates - work is not done in a single uninterrupted block. However in the case where the estimate is longer than the allotted time this might be a candidate for a new warning and is something we'll consider
• At the moment there is no way to visualise an individual absence, but we are shortly going to be introducing the ability to adjust future sprint capacities so that you can account for absences manually

At the moment we’re still in the early stages of looking at the capacity planning features so I can’t say what we’ll end up delivering or when they will be available - however, it’s obviously a key part of a planning experience and something that we want to address.

I appreciate that this might not have been the answer you're looking for, but I just wanted to respond as honestly and openly as I could. 

Regards,

Dave

[jbeg]

Hi Dave,

thank you very much for the detailed response. 

It means that when you drop an issue bar on the timeline it is manageable at the scale you’re looking at.

I can understand the decision from a design point of view. Maybe it is just our use-case but a relation from the length of the bar to the issue estimate would be more useful in daily use.

This would mean that multiple people are working on a single story at the same time

Yes, but every assignee would have his own task or sub-task within the hierachy and therefore his own time estimate and relation to his individual capacity.

Advanced Roadmaps was previously known as Portfolio for Jira and the old interface (known as “Live Plans”) was not as successful as we'd have liked. [...] with a goal of making the interface simpler and easier to understand and giving the user more control

I can relate to that. The new interface is much more user friendly and provides a cleaner interface to the roadmap with more visibilty. The rework was needed and definitly a success in some ways.

there are also ethical considerations about how much individual monitoring should be provided in a tool that we are thinking about

Individual monitoring and capacity management are two different things. Anyway, is this not a decision that your customer should make how much monitoring is desireable? Even when only monitoring the team as a whole, the capacity is still based on all the individuals.

Part time work does not necessarily just mean part time at the company - it could be part time across multiple teams

yes - but would you not just adjust the capacity of the individual in the corresponding teams? I would have assumed that is why you can set the individual capacity of the team members in the first place.

As mentioned elsewhere, we don’t consider the length of time to be absolutely linked to the start and end dates - work is not done in a single uninterrupted block. However in the case where the estimate is longer than the allotted time this might be a candidate for a new warning and is something we'll consider

I agree mostly with this. The original estimate does not necessarily match the timeframe from target start to end (but it can never be shorter). But the estimate is nonetheless the baseline for all adjustments of the timeframe and this should be reflected in the planing (which it does - but only for auto-scheduling, not manually as already discussed).

A plannig experience without proper capacity management can not work (or I just dont know how). Even if we would switch from individual to team based capacity - I dont see how jira automatically adapts for team capacity if members are in multiple teams without manually changing their capacity as a team member.

If assignee X in Team A has a workload of 40hrs in Project A, I can assign more workload in the same timeframe to the same assignee in Team B and Project B without getting a warning. When creating teams, the team capacity should be a sum of the member capacity (which it is). When each assignee has a capacity of 40hrs a week and I put the assignee in two teams, the capacity of the assignee over both teams can not be 80hrs (but this is the default case, or am i wrong?)

Agile or not... the individual capacity is a ressource shared among all teams which the assignee is a member of. And this ressource must be visible to management at all times.

I know that there a shared teams which would possibly adapt for that scenario. But it is impossible for us to utilize shared teams because our team compositions are highly project specific. So from our point of view, even a team based approch would need the individual ressource as a baseline in order to work. I mean, even in an agile approach, the team capacity is simply based on the individual capacity. 

It looks to us, that atlassian ist mainly focussing on agile development (Its all about teams). I can understand why from your business point of view. But not everyone wants or even can work agile. Our team constellation is pretty unique and individual skillsets and furthermore our products dont allow for mainly agile development strategies. We have very good results with a classical waterfall approach and feel very comfortable with this. Even if we would adapt to agile practices where possible, most of my points regarding the capacity managment would still be valid.

kind regards,
jens

[Dave]

Hi Jens,

Thanks again for the response - it’s very helpful, I’m not sure we’ll be able to agree on all points but I hopefully it’s helpful for me to provide additional context and responses to your points.

I think the main thing worth noting is that we’re operating in a highly opinionated area. So for example you’ve said that you should estimate individual sub-tasks rather than just using the story size… I completely agree that you could do that, but not everyone will want to (nor should they be forced to). For example I wouldn’t do that - but I might break down a story into sub-tasks and assign them across multiple members of my team if the work could be done in parallel and it made sense to do so. I’m not saying that your approach is wrong, just that lots of people have different approaches and we have to be careful not to meet as many of customers needs as possible.

Your observation about Atlassian focusing on Agile development is relatively fair, and you’re absolutely right that many organisations still use Waterfall and do so successfully. We have many customers that use Advanced Roadmaps for waterfall development and we obviously want to keep them happy as well but it is generally hard to please all the people, all the time.

I agree that individual monitoring and capacity planning are two very different things, however they are related. Personally I have had a lot of success with taking individual capacity into consideration for future sprint planning - however, once again there is not necessarily a broad consensus on this across the industry. There is no one size fits all solution.

In terms of individual contribution, I think there is a delicate line to tread. The biggest risk with attributing either actual or assumed velocity on an individual level is that it invites competition amongst people within the team which is antithetical to collaboration. For example, why would I help with my teammates when management will ultimately look at the number of issues I delivered?

In an ideal world you would only use individual capacity as a force for good - to make sure that a team member is not overstretched, but if you are assigning work to an individual based on the capacity that a tool says they should be able to deliver then there is a risk that this could be used against them if they fail to deliver that work (even if for good reasons like unblocking and assisting other team members).

You are also absolutely right when you state that it is possible for a person to belong to multiple teams (or even to be assigned issues that aren’t present in a plan) and the capacity planning in Advanced Roadmaps does not yet account for that. We are aware of these problems and want to address them and much of this relies on us building a tighter integration with the core Jira experience. This is something we want to do (and the current situation is the result of Advanced Roadmaps originally being a 3rd party plugin) but these things take time.

It is possible to capacity plan at a team level with Advanced Roadmaps and is something that I have successfully been able to do. However, it really depends on the process that you are following. The cone of uncertainty tells us that the more distant the date the more unreliable the prediction will be - I have high confidence that I can tell you what will be done at the end of the next sprint, but low confidence that I can tell you what we’ll have delivered in 6 sprints time and I make sure to communicate this to my stakeholders.

To be clear I’m not questioning the process that you are following, but I am asking you to recognise that it is not necessarily the process that is shared across all teams. I am fortunate to be able to talk to lots of different customers and I am constantly surprised at the many different processes that are followed, the different ways in which people use Advanced Roadmaps and the different features they ask for us to prioritise and deliver.

We recognise that there are improvements that we need to make to Advanced Roadmaps and we are working very hard to address them in a way that meets as many of our customers needs as possible. This is why having conversations like this is incredibly valuable. My intention here is not to provide a rebuttal to your suggestions as many of them are valuable. We are gathering information from lots of sources and are trying to understand as many viewpoints as possible so that we can make informed decisions about the next steps to take.

Again, I really appreciate the time that you’ve taken to provide us with this feedback.

Regards,

Dave

[jbeg]

Hi Dave,

I will dive right in

Thanks again for the response - it’s very helpful, I’m not sure we’ll be able to agree on all points but I hopefully it’s helpful for me to provide additional context and responses to your points.

likewise! Our conversation raised one or two questions for our team to think about our feature planning approach. We do appreciate your extended answers very much.

In terms of individual contribution, I think there is a delicate line to tread. The biggest risk with attributing either actual or assumed velocity on an individual level is that it invites competition amongst people within the team which is antithetical to collaboration. For example, why would I help with my teammates when management will ultimately look at the number of issues I delivered?

This is an very interesting point of view. Our intention with individual capacity planning is not to encourage competition among the developers rather than protecting them from too much workload and unrealistic due dates from management. But of course, your point is very valid and could happen alongside our initial intention. This is a fair point for our internal discussion how to persue with this topic.

In an ideal world you would only use individual capacity as a force for good - to make sure that a team member is not overstretched, but if you are assigning work to an individual based on the capacity that a tool says they should be able to deliver then there is a risk that this could be used against them if they fail to deliver that work (even if for good reasons like unblocking and assisting other team members).

Not sure if this can be easily categorized as good or bad. Why is a metric bad that tells me that some assignees fail to deliver their work on time. I can imagine that the consequences are very dependend of the work culture and the company structure/hierachy.

It is possible to capacity plan at a team level with Advanced Roadmaps and is something that I have successfully been able to do. However, it really depends on the process that you are following. The cone of uncertainty tells us that the more distant the date the more unreliable the prediction will be - I have high confidence that I can tell you what will be done at the end of the next sprint, but low confidence that I can tell you what we’ll have delivered in 6 sprints time and I make sure to communicate this to my stakeholders

Yes it is possible, but with huge restrictions. You already mentioned that Adv. Roadmaps does not account of members belonging to multiple teams. For our individual needs it is not possible to have a few shared teams along all projetcs. Our team members have very individual skillsets and are specialized in certain areas over the years. It is just not possible for us to throw a shared "Software DEV Team" at all the tasks over the projects. Every project of ours needs a special team. We are not easily able to share the same team with a different projects. That is why we are looking for the individual capacity planning. Considering the due dates and the certainty of delivering on time your argument is completly right. That is a lesson we have to relearn more often than we like to ;)

We surely are going to monitor the development of Roadmaps in Jira. Maybe we will find a overlap in features and our needs in the future. 

Thank you for the detailed response. We are now going into christmas holiday and we wish you, your family and your team all the best. Stay healthy!

kind regards,

jens