Helping the Customer Stick to the Purpose of a User Story

[article]

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.

User Comments

1 comment
Ginny D's picture

There is a well-established technique that BAs use called "the 5 whys".    (http://en.wikipedia.org/wiki/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

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!