Version start and end date?

Why can you only manage a version's start and end date and parent version in Agile > Classic Boards? Why can't these attributes in the Manage Versions section. When you look at burnup/burndown data by version, it is key that these dates are correct. However, it is not intuitive that you have to go to Classic Board > Planning to modify this information. These attributes should be in Manage Versions.

Are there any plans to assist with that, especially if Classic Board support is being deprecated (hopefully, all the gadgets will remain since those are the only ones available that support burnup, burndown, velocity, hours, etc by Version.

1 answer

1 accepted

The version start and end date are metadata properties stored by GreenHopper Classic that JIRA knows nothing about. As a result they don't show in Manage Versions. This is yet another reason why we have implemented sprints as a separate concept to versions in the new boards.

We don't intend to reimplement start and end dates for verisons in the new GreenHopper boards (but there is a possiblility they might get implemented in JIRA). We won't be deprecating classic mode until we have new gadgets that cover the new boards.

Thanks,
Shaun

HI Shaun,

However, if you deprecate start and end dates, there are then now alternatives for showing burndown or burnup for a version. Most, especially execs, don't care about a sprint. They want to know where you are with the next version as well as the general cost (story points). A sprint can be work on several versions as they can cross product, some are support issues vs capitalization versions Thus, these gadgets have been critical to showing this information. Start and end dates are essential for graphing and calculating this information, by version, correctly.

As long as any new gadgets provide these same options, then great! But, please don't keep focus only on sprint planning a reporting - that doesn't work when doing big picture risk and status.

It would also help, given the Atlassian is one company, if the products shared implementation of the same concepts. They work fine standalone; but, if they are together, such attributes can be shared to minimize the confusion. This is why you also get many questions about sprints being a part of a version which issues are associated to as the version is the released/deployed product, not the sprint.

The extra GH metadata such as start and end date and hierarchy was implemented before it was one company... it does seem to have taken a long time to align some of this stuff with core jira concepts.

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,242 views 14 19
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot