FinTech: How to transform traditional BRDs into Agile User Stories

By Sheyinka Harry

 

Banks and other organizations in the Financial Services Industry are spending billions of dollars on IT services every year. To be specific, data from the PWC Global FinTech Survey of 2016 revealed global spending of banks amounting to $215 billion in 2014. I’m sure you can understand why. Consumers depend on financial institutions to secure their wealth and to give them the best service their money can buy. But are these institutions really getting the best value for their big IT budget?  

Most organizations subscribe to a long and tedious “waterfall” methodology,  which consists of a very detailed definition of customer needs and expectations in Business Requirements Documents, before even beginning development. Consequently, projects are often completed late and over budget.

Thankfully, there is a more modern and effective five letter solution to this most tiresome process: A-G-I-L-E. Banks such as JPMorgan Chase and Capital One that have migrated to agile development tout the methodology for ensuring smoother processes,  quicker turnaround time on projects, greater flexibility, and increased efficiency in delivering quality experiences to consumers.  With all these benefits, the hesitancy of financial institutions to transition to the Agile methodology is simply baffling.  The most popular excuse? Processes are too complex to be broken down into smaller tasks, and the outcome is too unpredictable.

Disproving Fallacies

As someone with experience in the use of both methodologies, I can safely say this is an incorrect declaration of immunity. It is not that the process is too difficult. It is simply that there is great resistance within companies to change the corporate mindset from laying out all details, to just saying who wants what accomplished, how it will be done, and trusting it will get sorted out.

As succinctly stated by John Eaton in his article “The Fallacy of Converting Requirements into User Stories”, typical requirements are just too specific; They tell the user what they should do. A prime example of this can be seen in the following banking application requirement example:

This system shall provide certain searching and checking features for an account holder. The account holder can at any time and any number of times, log on and search for various details as the account’s balance, details of transactions, interest amounts, debits/credits, etc.The account holder shall have unique id and password for logging on to the account’s information.

This requirement focuses on the functionality of the system, by expressing what it “shall” do in as much detail as possible. User Stories, on the other hand, are high-level definitions of software capabilities and focus on the user experience. Stories relay to the developers what the end-user wants to accomplish, and sets the stage for team collaboration given their light nature.

The Transformation

When converting a typical requirement such as the one above, into an agile user story, a few things need to be added, based on best practices.

Step 1: IDENTIFY the 3 amigos:

A user story typically has three main components: a persona/the user, an action, and some promised value. This breakdown allows for easy digestion of the issue at hand. The user in our example would be the account holder as they are the ones interacting with the system. Next off, there are two distinct user actions that can be performed. These are logging on and searching. Finally, by combining the first two components and adding value propositions, the following independent user stories can be created:

1. As an account holder, I want to log on to my account so that I can view my account information
2. As an account holder, I want to search my account information so that I can know my account’s balance
3. As an account holder, I want to search my account information so that I can know my transaction details
4. As an account holder, I want to search my transaction details so that I can know all debits and credits for a particular day.

 

Step 2: VALIDATE with Acceptance Criteria

Now, it is all well and good that the three components have now been incorporated to create small, independent stories. But there is still a problem. These stories cannot be accepted as complete until certain conditions are met. These conditions, known as acceptance criteria, are needed to act as the basis against which the user story is to be validated and tested.

Taking a look at the first and last stories, acceptance criteria for these can be readily derived from the base requirement.

User Story 1:

Description

As an account holder, I want to log on to my account so that I can view my account information.

Acceptance Criteria

1. Verify that account profile is returned
2. Verify that user can log on multiple times

 

User Story 2:

Description

As an account holder, I want to search my transaction details so that I can know all debits and credits for a particular day.

Acceptance Criteria

1. Verify that full details on the transaction (Date, Transaction Description, Transaction amount) are returned
2. Verify that search can be done multiple times

 

Step 3: REMEMBER NFRs

It’s a common occurrence for acceptance criteria to made up solely of the functional requirements of the system. But the non-functional aspect of things need to be accounted for as well! System attributes such as performance, usability, scalability etc. are just as critical to the accurate development of an application feature. Looking at our base requirement, performance criteria can be added to our stories to account for responsiveness and speed of searches. Also, security criteria can be added to account for user validation. The new stories then become:

User Story 1:

Description

As an account holder, I want to log on to my account so that I can view my account information.

Acceptance Criteria

1. Verify that account profile is returned
2. Verify that user can enter username and password
3. Verify that user can log on multiple times
4. Verify that account is locked after three (3) failed login attempts. ← Security NFR
5. Verify that profile and account info is loaded in 10 seconds. ← Performance NFR

 

User Story 2:

Description

As an account holder, I want to search my transaction details so that I can know all debits and credits for a particular day.

Acceptance Criteria

1. Verify that full details on the transaction (Date, Transaction Description, Transaction amount) are returned
2. Verify that if a large set of results are returned, a paginated view is presented with page numbers and ‘Prev’, ‘Next’ links
3. Verify that all monetary amounts are accurate to two decimal places. ← Integrity NFR
4. Verify that transaction details are returned in 10 seconds. ←  Performance NFR

Perks of it all

The future of FinTech relies on teams to be nimble, ready to change with the market and with consumer needs. Lengthy and convoluted BRDs don’t allow for the desired level of flexibility. Small stories present make it easier to estimate time completion, helping to pave the way for small weekly releases, which get value into the hands of your customer much faster. Also, having requirements laid out in story format ensures that critical points aren’t missed. For these reasons, it is worth considering this transformation process the next time you are tasked with documenting requirements or creating user stories. It is not a perfect solution, but it will help in the transition from viewing application development as a series of items on a checklist, to viewing it as a way to help your team achieve real goals that offer real value.

---