What happens when a task in a Done status transitions to a To Do status in a different sprint?

[Eric Bailey]

We are setting up our sprint boards to track development/QA tasks only.  Board flow in general is To Do -> In Progress -> Done.  The workflow statuses are grouped under each of these fields.  When a developer's work is complete, it moves to a status of "Ready to Schedule Deployment", where it is picked up by the deployment team to do their magic.  This includes deploying the change and monitoring the change for a specific amount of time.  WHEN they deploy is up to them most of the time, so the timeframe is unknown for planning.  After Monitoring, it moves to Needs Code Merge, where the developer will need to pick it up one final time, merge the branch and mark it as complete.  

We are experimenting with all of the Deployment tasks as being marked as Done, since the developer is complete with the task and can get credit for completion during the sprint.  However, when the development team changes the status to Needs Code Merge, it will reappear on the Backlog and can be pulled into a sprint to do the final steps before closing the task for good.

So, my question is how does this affect reporting such as velocity?  When it comes back into To Do, are the issue counts (we are not yet to Story Points) removed from the previous Sprint and added to the current sprint, or are they counted twice?

[Ravi Sagar _Sparxsys_]

Hi @Eric Bailey 

Well yes, because the task was never fully complete or reopened.

A simple solution would be to create two tasks, which has its own problems because it is more work but because the deployment tasks is done by someone else which in a way is dependent on the development task to finish. Make sure the tasks are linked to each other as well.

Ravi

[Eric Bailey]

"Yes" to which part of my question? 

Is it removed from velocity in Sprint 1 (where it was considered Done) and added to Sprint 2 (When it is back in To-Do)?

 OR 

Is it counted twice?

Some conversation on here indicated that previously closed sprints are more a snapshot in time of what the data WAS when the Sprint was closed, so wouldn't change if it becomes an active issue again.  Obviously, it would be counted in the current sprint.

[Eric Bailey]

Also, creating separate tasks is not really an option here, as the task would have to be transitioned all the way through to the later statuses in the corporate workflow.   

[Eric Bailey]

The other option proposed was to have parallel sprints such that each sprint stays open until everything ready to deploy is deployed/merged/closed.  This would look something like

Sprint 1 - Start Day 1 - Dev Stop Day 10 - Close 3 days later (but could be whenever)

Sprint 2 - Start Day 11 - Dev Stop Day 20 - Close 3 days later (but could be whenever)

This is NOT by preference.