How to back-track stories/tasks in different sprints

[Mayur Gaikwad_Tech PMO]

Hello,

For one of my projects, I'm planning to run parallel sprints wherein in one sprint I want to ensure development activity is done whereas in another sprint i want to take these developed tasks and close testing. 

How can i back track which tasks got moved form one sprint to another and also if I want to see which all sprints the tasks have traversed, how can i get that info?

[Alexis Evans]

In Jira, if you scroll down and look under Activity where the comments are on any given Jira issue, you can switch to the History tab and that shows the history of all of the changes to field values, including assignee, status, and sprint, among other things. So, if you're moving an issue between sprints, that will be tracked there.

[Yuliia_Borivets__SaaSJet_]

Hi @Mayur Gaikwad_Tech PMO 

If you want to see a general picture of how issues are moving between sprints, you can try Issue History for Jira. My team developed this add-on as a diary of all past activities, including sprint changes. You can play with data and include any field you want in the report.

Example:

[EEverett]

"For one of my projects, I'm planning to run parallel sprints wherein in one sprint I want to ensure development activity is done whereas in another sprint i want to take these developed tasks and close testing"

Given your use of the word "parallel", is it correct to assume that Development will continue in the next Sprint, while testing of the 'previous' Sprint is done (presumably by another Test Team)?

From the Scrum Guide: "Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month." Calendar month in this context means the Sprint. You should strive to complete all Development tasks (code writing AND testing (plus any other activities needed)), so that the Sprint Goal is accomplished, meets the Definition of Done, and is a Potentially Shippable Increment (PSI).

It is difficult (i.e. nearly impossible) to achieve predictability if the 'Dev' Team has zero clue about how many defects may be injected into their 'parallel' Sprint by 'parallel' testing.

Teams need to learn to complete (meaning Done) their work within the Sprint.