While planning for a sprint, our developers planned for X number of issues. End of the sprint only Y get delivered (X>Y). Now the rest of the issues are to be re-scheduled to the next sprint or to be moved to unscheduled.
Is there a way that we can find how many issues were re-scheduled in a sprint? This gives us an idea on the accuracy of the original estimates and helps plan better in future.
I tried with fixVersion was "version1", but it seems this is not supported as of now. There are open issues on this -
https://jira.atlassian.com/browse/JRA-5536
https://jira.atlassian.com/browse/JRA-24650
Any other way/workaround to get this kind of a report in Jira Studio?
Hi Nikhil,
While I think I will also be looking forward to the JQL 'WAS' function, a near-term workaround might be to take an export on day 1 of the sprint. Consider this the baseline snapshot of your commitment. On the last day of the sprint, you might compare it to your final state as a reference of your original intentions versus what you actually delivered.
If you are concerned about your team moving issues from sprint to sprint, you might consider creating an issue security scheme that defines permissions for editing that field more tightly.
I also did a quick search on potential plug-in solutions and didn't find anything that looked like it would provide a promising view.
--Beth
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Nikhil,
When you release a version (sprint) via the Planning Board you have the option to move issues on to the next sprint. When you do this the current version is recorded in the 'GreenHopper Released Version History'.
Search change history (JQL 'WAS' function) will be availble for the Fix Version field in a future release of JIRA. It is targeted for JIRA 5.0 which will be included in a future release of JIRA Studio.
Thank you,
Nicholas Muldoon
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Nicholas! Did you mean Release Board by "GreenHopper Released Version History"?
But since, there is no lock a well on the sprint, team members can freely move issues in and out even before the release of the sprint. I wanted to track how many issues did we commit on the sprint start and how many did we deliver.
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.