Handling Dependent Tasks across Sprints
"How can we handle tasks which are related to each other but belong to different Sprints? 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 a few Sprints we add a Weapon Upgrade system which may come 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 can we handle this kind of situation?"
The above scenario is a common one, and it applies virtually to any kind of complex development. A good way to approach this kind of dependency is to think in terms of acceptance tests. You might set up three categories of acceptance tests – they are essentially the same, but they apply to different development stages.
Level 1: Immediate acceptance tests
Immediate acceptance tests apply to any new functionality that should be implemented in a given Sprint. The acceptance tests for your initial game Weapon System would fall into this category. A typical acceptance test for „Load pistol“ could be „load 10 bullets into the empty pistol magazine and the magazine should be full“. This is by far the easiest approach, since each test is directly connected to a user story or specific functionality.
Level 2: Regression tests
Regression testing should be easy, if you implement the acceptance tests on Level 1 to be executed automatically. The regression tests are applied to each product increment – the potentially shippable integrated and tested code at the end of each Sprint“. They are typically used to capture unexpected behaviors. So, „load 10 bullets into the empty pistol magazine and the magazine should be full“ should still work, even if you have implemented a weapon jam in Sprint 4. The jam should not impact the magazine capacity of the weapon. If it does, you might have caught a regression defect. Or found an unexpected feature ;)
Level 3: Interdependent acceptance tests
This is by far the most complicated category. Level 1 captures immediate functional changes, Level 2 captures undesired defects, but Level 3 is supposed to deal with functional changes that have an impact on other functional changes. Several teams have worked with dependency matrices to cover the functional areas and their influence on others. In your example, the Weapon System Upgrade does effect the existing Weapon System code, as you would expect it. The new acceptance tests are added to the given set of acceptance and regression tests. „load 10 bullets into the pistol magazine and the magazine should be full“ becomes „upgrade the pistol magazine and the capacity should be 20“ and „load 10 bullets into the empty pistol magazine and the magazine should have a remaining capacity of 10“. This procedure might result in a pretty big number of acceptance tests per new functionality. You can handle the test cases better, if you add several new stories that describe the modified functionality – „Upgrade pistol magazine“, „Load upgraded pistol magazine“ could be such a story pair.
The dependency matrix helps to keep track of potentially affected areas. The combination of the acceptance testing and dependency matrix provides clarity and manageability.
About the author
Andreas Schliep is a founding member and executive partner of DasScrumTeam. He is a Scrum coach and trainer. He studied at the technical university of Bremerhaven, and worked as a software developer, project manager, team lead and group lead. Andreas has worked with Scrum since 2003. He became a full-time Scrummer in 2006.
Since then, he has helped to introduce and improve Scrum and agile practices in numerous companies all over the world. His favorite topics are quality management and scaling.
- Experienced ScrumMaster, Product Owner, Coach and Trainer
- Introduced Scrum at WEB.DE
- Coaching of internationally distributed teams
- Transition from RUP to Scrum at UOL Brazil
- Scrum Trainings and Coaching in Germany, Switzerland and Austria