Grenades, Shells & Bunker Busters

As agile business analysts, we try to keep our stories small, independent, testable and valueable. Once in a while, though, we come face to face with a Bunker Buster and everything starts looking scary.

Impact

Every story is likely to impact a certain portion of the developed application. Measuring this impact and using it to "time" a story well, is something commonly ignored by business analysts. This doesn't mean that the analyst or the team doesn't know the impact of a story but this measure is not used in planning exercises effectively.

We can almost categorize stories to get a quick idea of the impact that they have on an application. In my experience, there are three such categories

Hand Grenades - Stories that add functionality
This means these stories add completely new functionality. These stories impact a very small part of the application that has already been developed.


Shells - Stories that enhance functionality
There are stories that form latter parts of a series which enhance already developed functionality. These stories bring in minor refactorings and hence their impact is rarely beyond the code written to deliver that particular functionality.

Bunker Busters - Stories that enhance the application
These are the stories that aim at enhancing the "complete" application. A common example of this species is application security. Inevitably, there are areas of the application that only privileged users can access. These kind of stories bring in major refactorings and hence have an impact on a considerably larger proportion of the code already written.

Handling Bunker Busters
In a ideal world, a business analyst will deal with Hand Grenades and Shells. But things are not that simple all the time and we need to handle a Bunker Buster once in a while. There are 2 approaches towards handling these stories.

Avoiding
The first approach is to simply avoid a Bunker Buster by reducing it into several Hand Grenades or Shell stories. Carrying the example of security forward, we will think about the security involved, everytime we add or enhance functionality and thus split security across several Hand Grenade and Shell stories

Advantages:

• Less / No impact on existing code
• Tests (especially functional ones) remain healthy and effective
• Stories become really independent and valuable
• Planning becomes simple

Disadvantages:

• Requires upfront thinking and design
• Inclusion in all stories

There are areas like security, common to most projects we do, which can be handled using this approach looking at the trade off between upfront design and ease of implementation.

Embracing
The second approach is to play a single (generally huge) story which impacts a whole lot of developed functionality. In many cases this option is inevitable because the required functionality was never thought of.

Splitting this story doesn't make too much sense because the result tends to be half-baked functionality which poses even more problems. Timing this kind of a story is something that the team needs to be careful about. This story is likely to impact a large proportion of code as well as tests besides bringing in all the disadvantages of large stories with it.

Considering these impacts, the team may decide to :

play these stories as soon as discovered and refactor code and tests as required
OR
play these stories at the fag end of the project by leaving existing test untouched and testing this functionality seperately.

For more on Bunker Busters, stay tuned...