Helping the Customer Stick to the Purpose of a User Story

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.