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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.