Handling Dependent Tasks across Sprints

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.