How we can handle tasks which are related to each other but belong to different Sprint.
Example :- For an example of a game. Suppose we planned to design a Weapon System in Sprint 2. Like Weapon index, bullet and other weapons settings.
After few Sprints we add a Weapon Upgrade system which may comes in Sprint 6. Now when we implement this update system , we need to make changes to weapon system as well. And so we need to code and test the Weapon system again in Sprint 6.
> we need to make changes to weapon system as well. And so we need to code and test the Weapon system again in Sprint 6.
When the team plans the sprint in Sprint Planning, they will come up with a plan to deploy the new functionality they are looking to deliver in accordance to the definition of done. If testing existing functionality to ensure that it is not broken by the new features added is important and part of the DoD, then it should be included in the sprint backlog.
You can also find some helpful answers in this thread asking about how to handle situations where future stories affect existing functionality: