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.
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.
Hey Community mates! Claire here from the Software Product Marketing team. We all know software development changes rapidly, and it's often tough to keep up. But from our research, we've found the h...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG