Handling Dependent Tasks across Sprints
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.
How we can handle this kind of situation.
Sounds like you kind of already know.
> 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:
https://www.scrum.org/Forums/aft/383#1977
> How we can handle this kind of situation.
You appear to be describing a situation in which value is discovered iteratively and delivered incrementally. Where exactly do you see a problem?