We have any way to hide the subtasks in Timeline view or show as nested (tree) with parent tasks?
Any way to order or manage the view in any way?
Really no options for this view exist, I think that this is an important view for this template and this view is not usable
Hi @osjimenez There doesn't appear to be...currently.
I agree, your suggestions would be really beneficial and some way of filtering/arranging the Timeline would make the world of difference to this view (which is loaded with potential).
TBH I don't know. but based on how new JWM is (and the timeline/roadmap view in Jira is generally), I doubt it.
Question: You are on cloud, yeah? Cloud premium comes with Advanced Roadmaps, where this functionality exists. Would you consider Cloud premium as an option?
@Curt Holley Correct, I'm using the cloud platform. I'm still kicking the tyres on the whole Jira environment and trying to see if it is going to be a good fit.
I really want to like the platform, but I'm struggling to accept the use of terminology that continually references the dev ops way of working. Coming from a non dev ops background, I find it challenging to getting used to some of the references.
The ability to sort rows/columns seems like basic functionality that shouldn't warrant having to upgrade to the premium edition. I believe this capability is coming in the next few weeks, so I'm looking forward to seeing it implemented.
To cover your needs you can try and use some of the apps which can be found on the Marketplace, which adds the ability to create your own WBS of your tasks as well as a timeline view- for example BigGantt (simple yet powerful Gantt chart), or BigPicture (Gantt + variety of other powerful modules like Board/Resources etc), products developed by SoftwarePlant (the company I am also a part of).
With this, you can easily create the hierarchy of your tasks from single/multiple Jira projects, and also decide how the tasks should be nested:
Hope this helps!
I believe that it all gets down to the Atlassian billing mechanism since we use it as well. I have found the following information on the Atlassian Marketplace - hope you will find it useful:
Apps are billed based on the number of users in your Atlassian product. For Jira 7.0 or later, the app tier should match the maximum tier of the licensed Jira products on your instance. For example, if you're running Jira Software (500 users) and Jira Service Management (25 agents) on the same instance, you should purchase the 500-user tier for apps. For versions of Jira prior to 7.0, the app tier should match the licensed user tier for Jira. Even if fewer users want to use the app than your Jira license, the two licenses should match exactly. Note: While this app has features specific to Jira Service Management, the app is technically available across the whole Jira instance. Therefore the above guidelines for the license tier still apply.
Oh, the irony. For a platform that is meant to be built on bleeding edge agility, the Atlassian pricing model is so inflexible for many customers. It needs to be more flexible. To use your example, why would I want to pay for 500 users when I might only want/need 20 users to have access.
I appreciate most of the products might have access to use the app but if you don't need that cross-product access and only need a subset of users to have access then the pricing model needs to be able to accommodate that requirement. It's okay for large businesses to make the simple decision to purchase these platforms based on the number of users in the company whether they'll use it not but many small to medium sized business don't have that luxury.
The other option then, as was mentioned, is to separate the instances. Not much of an agile platform then is it. What's the point, it feels like the customer has to try and wrestle with the idea that its all or nothing.
I'm excited to see where Atlassian take the platform but if they don't make the pricing model more flexible, myself and others (I suspect) will simply move to other vendors where the pricing model makes sense.