Improving Sprint Reports

Jesse Gray July 5, 2023

I'm seeing some issues in our Sprint reports in that it is very easy to forget to manually correct the Sprint `startDate` and have all of your scope changes from planning make it into your Sprint Reports. 

 

A practical (and real) example of how this can play out in a negative way for our teams is:
  • Have a Sprint that is set to start 9am Friday
  • Host your actual planning at 10am
  • Move a bunch of tickets in and out of the Sprint
  • Start the actual Sprint at the conclusion of your planning session, let’s say 11am
  • Leave the Start date set at 9am in Jira
  • Everything you moved in / out during your planning session is now scope changes, and inappropriately effects outcomes and metrics. 

 

I think this could be resolved simply in the API by allowing programatic access to the datetime the Sprint actually started, much like we see with `endDate` (manual) and `completeDate` (system). 

 

  • startDate - Manually Input Sprint Start Date
  • ??? - Actual Sprint Start Time (log of the datetime you hit the start button)
  • endDate - Manually Input Sprint End Date
  • completeDate - Actual Sprint End Time (log of the datetime you hit the end button)

If we accounted for ??? above, then all reports could default to system times, with the option to override to manual times. 

 

How else could we solve for this?  I know the problem, but maybe there's already a solve for it that does not involve Atlassian devs. 

 

Sprint API docs:
https://developer.atlassian.com/cloud/jira/software/rest/api-group-sprint/#api-rest-agile-1-0-sprint-sprintid-issue-get

 

 

0 answers

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events