modify the date of "issue added to sprint"

[POIRIER]

Hello,

I would like to be able to change the "issue added to sprint" date.

I often create the sprints after they are started (I know that it's not the correct agile process but sometimes I can't do anyway else).

For example, I often do the following process:

- create some tickets

- estimate them

- log work (giving a date in the past)

- create sprint (start date in the past, end date in the future)

- add tickets to the sprint

- start sprint

=> The reports are unusable (burndown, burnup and sprint reports) because the date the tickets are added to the sprint are after the date they were estimated. Estimation is then not taken in account. Neither the time spent.

Is there a way to change this date?

Best regards,

Grégory

[Andy Heinzer]

This kind of modification is not something I would expect you to be able to make in the Jira UI, short of removing the issue from the sprint and adding it back again.

But you might want to take a look at this related community thread: https://community.atlassian.com/t5/Answers-Developer-Questions/SQL-When-was-issue-added-to-sprint/qaq-p/520487

In it Jamie provides a SQL lookup command to find issues added to a sprint after a certain date.  I tweaked that post to make this work in my own current postgresql database:

select ci.newstring, cg.created, ci.field, ji.issuenum, ji.project  
from changeitem ci join changegroup cg on ci.groupid = cg.id 
join jiraissue ji on cg.issueid = ji.id 
where field = 'Sprint' and cg.created > '2017-07-05'

In turn this should be able to tell you all the issuenum + project of the issues added to a sprint after a specificied date.  I suppose it might be possible to make changes to the changeitem table in Jira directly, but this would be completely unsupported to do and I can't really guarantee that it won't break something else.  So while I think this is generally bad idea, if you're still wanting to do this, I'd recommend that you create a backup of you database first, stop Jira, and then make changes to the SQL directly.  

It would probably be best to try this in a staging server before attempting any of these kinds of direct SQL changes to a production environment.