Handling Dependent Tasks across Sprints

Last post 11:59 am December 30, 2014
by Ian Mitchell
2 replies
Author
Messages
10:48 am December 25, 2014

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.

07:27 pm December 29, 2014

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

11:59 am December 30, 2014

> 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?