Helping the Customer Stick to the Purpose of a User Story

I work as a tester on a development team for a financial services company. Our software manages all aspects of 401(k) retirement plans. Even though we've been practicing agile development for eight years, or maybe because of it, our customers sometimes fall into a trap. Rather than tell us the business problem they need to solve, they give us a user story with the technical implementation already all figured out. In a recent estimating meeting, our product owner read this story: "As a third-party administrator, I want to upload a loan, with my own loan term, interest rate, amount, and generate a corrective action to liquidate the funds and process the out check." OK, that's a lot of jargon, so here's a bit of background.

Employees of companies who sponsor 401(k) plans are allowed to defer some of their salary, tax-free, into their own personal retirement account. Some companies allow their employees to borrow funds back from those accounts, if they have a need such as medical or education expenses. They take out a loan with a term of some number of months, at an interest rate tied to the prime rate, and the interest and principal from each payment goes back into their accounts. We have a sophisticated user interface to allow participants to take out loans from their accounts. Some more explanation - some employers use a third-party administrator to oversee the 401(k) plans that they provide for their employees. This makes life easier for the employer, as the third-party administrator takes care of all the payrolls and legal mumbo-jumbo. The third-party administrator may also perform services for individual employees in the 401(k) plan.

When our PO explained this new user story, he said, "You know how third-party administrators can upload a file with money that needs to go back to participants who accidentally deferred too much of their salary into their account? Those generate a corrective action that liquidates funds, and cuts a check back to the participant. We need something just like that, only the check will be a loan."

Huh? We put a lot of work into creating an easy-to-use interface to request a loan, and the code to process that loan request. Now we should have a completely separate location for requesting loans? And what does this have to do with corrective actions? I asked, "What is the purpose of this story? What business problem is being solved?" The product owner explained, "The third-party administrators may have different loan terms and interest rates than our system uses, and allow more than one loan per employee. For example, they might allow an 80-month loan repayment term, which our system does not allow. Also, they might allow employees to have more than one loan at the same time, which we don't allow in our system. So, they can't just take out a loan for an employee through the normal user interface; it would fail the validations. Since they can't use the regular UI, we thought they could upload a file with all the information about the loan."

We sure don't want to create a second interface for requesting a loan. Now that we understood the business problem to be solved - allow loans that violate our own rules - we could find a better technical solution. We can update our existing loan request UI so that if a third-party administrator who has different loan rules logs into a participant account, they won't be subject to the normal validations, and they can take out a loan with their own conditions. This way, the loan request will be processed in the normal way, with the existing code, instead of having to also build special processing code.

The moral of this long and somewhat confusing tale? Make sure you understand the *purpose* of a user story or feature. Start with the "why." You can worry later about the "how." The customers get to decide on the business value to be delivered. They generally aren't qualified to dictate the technical implementation of that functionality. We, the technical team, get to decide the best way to deliver the desired feature through the software. Always ask about the business problem to be solved.

Sometimes, it's possible to implement a "solution" that doesn't really solve the problem. So, back to our estimating meeting. The problematic user story was rewritten to read, "As a third-party administrator with special loan rules, I want to be able request, on behalf of a 401(k) participant, a loan that is not subject to the normal system validations, so that the participant can receive the loan funds, and repay the loan." We think the best technical solution will be to suspend the normal validations if a third-party administrator with their own loan rules is requesting the loan for the participant. This way, once the loan is requested, the loan processes in the normal way, and we don't have to add special code for actually liquidating funds and cutting the check.

When you participate in estimating and planning meetings, remember to ask "Why?" first. The business stakeholders can answer the question "Why?", but they can and should not answer the question "How." It's best when the technical implementation is decided by the technical team.