Helping the Customer Stick to the Purpose of a User Story

Lisa Crispin writes that you need to 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. It's up to the technical team to decide the best way to deliver the desired feature through the software.

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.

User Comments

1 comment
Ginny D's picture

There is a well-established technique that BAs use called "the 5 whys".    (

Try using this technique - users trying to give solutions instead of telling you why they need something is not new!

October 10, 2013 - 12:02pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.