Embracing Bunker Busters

For various reasons, there are situations when there is no running away from a Bunker Buster. An agile team should therefore be watchful. Once the analyst finds a potential bunker buster, he/she will have only one parameter to tweak... The timing. Embracing a bunker buster is a a brave step, I would say. But then isn't, bravery only relative to the preparation??

Symptoms
Here are some tips out of my experience for identifying bunker busters. Note that these symptoms do not decide a bunker buster individually. Like gesture-clusters in body language, they work in combinations.

Vagueness
The first and most probable characteristic that you'll notice about a bunker buster is vagueness. This is not the same vagueness that you experience when you don't know the screen where particular information is captured. This is vagueness which has potential to change the way you have been thinking about the solution. Some fundamental assumptions about the way the user is going to use the application could be proven wrong at the and of your analysis. This brings us to the next characteristic, The Paradigm Shift...

Paradigm Shift
Over a period of time in a project, the team develops an idea of how a user is going to use the application. A bunker buster has the potential of changing this basic usage paradigm. Let's take an example here.

Imagine a phone book application. This application allows Adding, Editing, Viewing and Deleting phonebook entries. The team envisaged this application thus:
- The user will search or browse the phone book to find a particular entry.
- The user will then view the details of the selected entry.
- The user then has the option to Edit or Delete an entry
- The function for adding a new entry is available throughout.

Now after some time into the project, the business and the analysts realized that the users that search, browse or view entries are different from the users that add, edit or delete entries. The solution was to select a mode while entering the application. The user would be able to only add entries in the "Add" mode. While the "View" mode would let users only view an entry.

This is a paradigm shift. While most bunker busters we see in reality are not of this magnitude, I hope you get the idea.

Extra Long Analysis Phase
Both the above lead to an unusually long analysis phase for this particular story. Another fact that contributes to this is the fear that there might be exceptions. While the new usage paradigm makes sense from the usability point of view, there might be functionality which will make less / no sense if the user is going to use the application in a different way!


Approach
To get consensus of all the stakeholders on this new paradigm, to clear up confusions, to find and take care of exceptions (if any) and to present all this in the form of a small, independent, testable and valuable story is a mammoth task. To make this a tad easier, here's a list of things to take care of when dealing with a bunker buster. I have divided this by stake holder because the underlying gist is to communicate constantly with everybody.

Client
Communication with the client is always crucial. After sometime into a project analysts generally split into areas and so do the members of the client team. While handling a bunker buster however, constant communication with the complete client team is essential. I would include all business as well as technical users in this. End users, sponsors, client's system administrators, deployment team (in case you are building a product) and of course the complete client team that defines requirements. The shift in usage paradigm is a key decision on which you would need all kinds of input and a consensus from all the mentioned parties.

BAs
Other business analysts are the best people to talk to when it comes to finding exceptions. They will have complete knowledge of the respective areas that they are working on. Also, early communication of this kind will help them analyse the future functionality keeping the bunker buster in mind.

QAs
One thing that closely matches the way an application is going to be used is the functional test suite. Functional tests are the most valuable and the most fragile tests on a project. A bunker buster can render loads of them useless if they are not refactored to accommodate the new usage paradigm in time. Depending on the size of the functional test suite, the QAs will have to decide whether to refactor them or throw them away or leave them untouched. The QAs can leave the tests untouched if the application can provide useful hacks, like switching security off. Of course there are other functional tests that test security. Personally, I think this is the last resort. Functional tests should always be in sync with the way the application will be used.

Developers
Communication with developers is of vital importance because a bunker buster has potential to change the domain model in unexpected ways. Validating the feasibility of the change and it's estimation is absolutely crucial. While the bunker buster is in play, I would suggest even pairing with the developers. One area where it will most hurt is the amount of detail in the story itself. Due to the long phase of analysis, accommodating all the detail in the final story is all the more difficult. Remember that while you are busy preparing this story for play, there is functionality being added to the application. I think this is one more place where it would be much better to leave the story at a high-level, do a careful kickoff and if possible pair up with the developers.

Timing
As mentioned before, timing is possibly the only parameter that we can tweak as a team and taking full advantage of this fact is very important. Due to the consequences mentioned above, I think it is best to play a bunker buster at the very beginning of a release. That way the UAT for the previous release can go smoothly. The team also gets a logical break point to adopt this new way of thinking about the solution... Mentally(analysis) as well as physically (code and tests).

Scary as all this may sound, I guess successfully embracing changes like these is the ultimate value that an agile team delivers.

Avoiding Bunker Busters

"Prevention is better than cure" and one good way of handling Bunker Busters is to avoid them. Agile teams seem to be wary of handling anything by prevention, as it requires thinking ahead and taking care of things to come rather than things that are. While this makes perfect sense for Grenades and Shells, Bunker Busters have much more potential for damage and it is worthwhile trying to prevent them rather than handling them when they come.

There are areas in every application which can prove to be huge bunker busters if not handled in advance. Teams are even aware of there existence but still choose to handle them "when they come". One such area is "Application Security" and I have heard about (and experienced) this quite a lot so I think it makes a good, simple example.

Let's go back to the way we write stories. The story aims at stating a particular requirement in the form of an action, which a particular role wants to perform to achieve a specific, measurable, achievable, realistic and time-bound goal. The generally accepted form of such a story is a single sentence as follows:
As a <role>
I would like to <action>
So that <immediate goal>

A Grenade in this form would look like:

As an administrator,
I would like to add a new book to the library,
So that the book can be borrowed by the borrowers.

Now this is a good story because it can be easily implemented to achieve the following:

• A form which only the administrator can access [role]
• Logic to validate & persist the information entered into the form [action]
• tests to check if the book can be borrowed by the borrowers (which is another role BTW). [goal]

The "So that" clause here does two things. It sets the testability of the story as well as clearly mentions the dependancy.

Leveraging all clauses of the story in this way (and firstly writing stories in this way) can go a long way in favour of the project.

The same story would become a Shell, like this:

As an administrator,
I would like to restrict other borrowers from adding a new book to the library,
So that I can control the books added the library.

(this will be played in addition to the first story, because we decided to do security later)
Sounds worse, does it?? But it can get even worse like this:

As an administrator,
I would like to restrict borrowers from adding new books to the library, editing book information, deleting books from the library, viewing x,y and z reports and configuring x, y and z,
So that I have full control of the admin functionality of the application.

(this story will be played after the stories for all the above functionality have been played...)
This is a bunker buster; and the worse part is that this could be avoided.

(Note: the second and third stories aim at delivering the same functionality, although the reader might think that these are stories will let the administrator "configure" access restriction to the mentioned parts of the application.)

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