Guest post by Ed Brown  The problem: Agile developers want user stories; product managers want to bring back stories from the market about users. What we REALLY need is to understand user goals. Is there a difference? Let’s see.

User stories are one of the most misunderstood and misapplied artifacts of Agile development. As often happens when implementing any type of change, many of the good practices get thrown out along with the bad. For example, with RUP, requirements analysts strived to first gain agreement on the problem (or opportunity) before moving towards solutioning. I think it was Craig Larman who said, “Build the right thing, build the thing right.” While there is no reason that this principle cannot be applied in “Agile” development, too often I see a rush towards solutioning.

I believe that user stories are partly to blame because at first glance they look like requirements. And, it is very easy for a team to sit in a room and crank out a bunch of these user stories when under the gun to generate work for the next sprint.

For example, take the following user story: As a first-time book buyer, I want to find theperfect mystery novel by reading staff reviews so Iwon’t waste my money reading bad books. What is wrong with this user story? Maybe nothing; maybe everything. Are customers asking for staff recommendations? Or did the product team decide staff recommendations were cool and then write the user story from that premise? Even if customers are asking for staff recommendations, does that mean that we should just go ahead and build it? The ultimate goal of the customer in this story seems to be to find the perfect mystery novel without wasting time and money on bad books. Even if we know this, which is more important to the customer, saving time or saving money? And would providing staff reviews actually help customers achieve that goal?

While this subject could take up an entire book, I have distilled into the following example my thoughts on how to refine a story about a user into one or more requirements.

First, get to the user goal

STORY ABOUT A USER: When driving along unfamiliar roads, I often catch a glimpse of an interesting-looking shop or restaurant. Unfortunately, I am usually either on my way to an appointment or it is unsafe to pull over. And if I do stop, sometimes the place is closed! It would be great if I had some way of remembering the name of the place or the location so I could research it and return if I want to.

USER STORY: As a driver who frequently travels in unfamiliar areas, I want the ability for my GPS to record my current location so that I can remember interesting places. (Not terrible. But is this an illustrative example or a requirement?)

REQUEST: I wish I could remember my car’s current location when I am driving along an unfamiliar route so if I see someplace interesting while I am driving, I can easily locate it later. (Better: implementation-free.)

USER GOAL: I would like to be able to return to interesting-looking shops, restaurants or locations that I encounter while driving in unfamiliar areas. (Best: distilled to the ultimate user goal)

Taking it further

After validating that there is a large enough group of users with the same goal-and the willingness to pay for a solution—you can start riding around with a sample population, developing personas and using other techniques to uncover user needs and behaviors.

IDEAL FUTURE SCENARIO: (A future-based story used to envision ONE possible way that we could fulfill the targeted user’s goals.) I am driving on my way to visit my friend Ed and I see an interesting-looking antique shop that I would like to check out. Unfortunately, I don’t have the time to stop because I told my friend that I would be there at 2:00 sharp and I am running late—as usual. It would be great if I could just hit a button as I pass the antique shop and the GPS would record either the closest street address or the nearest intersection. Later—when I am not driving—I would like to retrieve that information, give it a meaningful name and save it in My Favorites.

CURRENT REALITY: I am driving on my way to visit my friend Ed and I see an interesting-looking antique shop that I would like to check out….

CURRENT WORKAROUNDS:

1)    If possible, pull over and write down the name and address of the store.

2)    Attempt to write down the name of the store while driving.

3)    Attempt to remember the name of the store and when reaching a safe point during the route, attempt to locate via Points of Interest functionality on GPS.

4)    If I successfully remembered all or part of the name, do a search on the Internet later to obtain the address, and then input the address into the GPS.

5)    If time allows, delay driving to my destination and drive to the store, realizing that the store may not be open.

REQUIREMENTS:

1)    Since the user will be driving while initiating this functionality, it is imperative not to break the driver’s concentration since this could lead to an accident.

2)    Since the user will most likely spot the desired location as he is either quickly approaching it or has just passed it, the functionality must be able to determine and record the car’s current location within 3-5 seconds.

3)    …

OPEN ISSUES:

1)    Should the functionality support driving along the highway or only on regular streets? Sometimes, you can spot a mall or other point of interest from a highway.

2)    ….

Conclusion

Goals are your first description of stakeholder intentions: your first insight into their requirements. Goals must be analyzed and refined into realistic and measurable targets if you are to have any hope of “building the right thing.”

Therefore, whatever “format” you use to convey the “requirements” to the project team (in my opinion) is a matter of preference. What truly matters is that you convey a clear understanding of: (1) who will be using the product; (2) what the users are looking to accomplish with your product; (3) what context the product will be operating in.

==

Edward Brown has been a requirements analyst since childhood but has only been getting paid for it since 1999. Edward is currently a Technical Product Manager at the Premier healthcare alliance headquartered in Charlotte. He has also worked as a software developer, Microsoft applications trainer, business systems analyst, and translator (Edward is fluent in Japanese). Edward maintains a profile with more historical professional details on LinkedIn at www.linkedin.com/pub/edward-brown/13/817/172

photo credit: Stephan Geyer via photopincc

photo credit: Madison Guy via photopincc