Agile developers want user stories; product managers want to bring back stories from the market about users.
What we really need, however, is to understand user goals.
User stories are one of the most misunderstood and misapplied artifacts when implementing Agile development. At first glance, they look like requirements—and it can be very easy for a team to sit in a room and crank out a bunch of them when under the gun to generate work for the next sprint.
The user story format is: As a <type of user>, I want to <something> because <benefit>. Let’s look at an example: “As a first-time book buyer, I want to find the perfect mystery novel by reading staff reviews so I won’t waste my money buying 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 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. But which is more important to the customer, saving time or saving money? And would providing staff reviews actually help customers achieve that goal?
You need to start with a story about a user and what their actual problem is. From there you can refine the story into the user’s goal—and ultimately the requirements you’re looking for.
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 on my way to an appointment, it is unsafe to pull over or the place is closed. It would be great if I had some way to remember the name of the place or its location so I could research it and return if I want.
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. It’s not a terrible description, 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. That way if I see someplace interesting, I can easily locate it later. That’s a better description and is 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. That is the best, distilled to the ultimate user goal.
The Who, What and What
Goals are your first description of stakeholder intentions and 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.
Whatever format you use to convey the “requirements” to the project team 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 goals of each stakeholder group are and (3) what context the product will be operated in.
Let’s dig a little deeper into each of these three areas.
Who will be using your product? It seems pretty straightforward, right? But keep in mind that all users are stakeholders, but not all stakeholders are users. (In the broadest sense, a stakeholder can be anyone who has influence on your project or product.) When we think of stakeholders, the following two come to mind immediately: the person who will actually be using the product and the person who is funding your project. But wait! What about the person who is actually purchasing the end product? Sometimes they are the same as the end user, often they are not.
The classic example is dog food: While the dog is certainly the user of the product, you can’t forget that the owner is the one making the purchase decision—and the stakeholder that you have to influence initially. In software purchases, it is often the same: The people who will be making the purchasing decision may ultimately never directly use your product, so you must understand what affects their decisions as they evaluate and compare products.
Best practice. Don’t rely solely on information from the project sponsors and other managers to understand “the requirements.” Meet with the people who will be “in the trenches” using the product. Get them to tell you stories. To better understand goals, ask questions like “how does the company measure your performance?” and “what would you need to accomplish to have a great day, week, month?”
What are the goals of each stakeholder group? Think about the last time you entered in a timesheet for work. Did you get excited about the endless array of options to capture each hour of work that you performed? Did you agonize over how to record each hour of work, so that you can be sure that your organizational budget will be as accurate as possible? If you answered yes to either of these questions, you are probably a project manager.
Unfortunately, when someone went about designing the timesheet software, they probably didn’t take into account the goals of the other stakeholder groups like the software developers, business analysts and testers. Their goal was most likely to be able to input time as quickly and easily as possible and get back to doing what gets evaluated—a classic case of conflicting stakeholder goals.
Best practice. Create a stakeholder/goal matrix and surface conflicting goals among internal stakeholders. This is most easily accomplished in a facilitated workshop where disagreements will surely emerge that can be learned from.
What context will the product be operated in? Specifically, once we know what we are designing, what conditions of the physical environment do we need to take into account? For my scenario of wanting to be able to remember interesting places, we probably would need to understand the laws for operating a device while driving, the amount of noise in the car (for speech recognition to work), the speed we anticipate the car to be moving at when the driver notices someplace of interest, etc. And we should factor these into the product.
Best practice. Rather than analyzing the operating context at only a static point in time, try to envision how your product will be used throughout its life cycle. Develop prototypes and have team members or potential users role-play scenarios. Get out of your office and observe people in their work environment, while they are doing the tasks that fulfill their goals. Be observant. Ask about sticky notes and files of papers that seem out of place.
Take 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. That information can help you evolve additional requirements.
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.
Here are my current workarounds:
- If possible, pull over and write down the name and address of the store.
- Attempt to write down the name of the store while driving.
- Attempt to remember the name of the store and when reaching a safe point during the route, try to locate via Points of Interest functionality on GPS.
- If I successfully remembered all or part of the name, search the Internet later to obtain the address, then input the address into the GPS.
- If time allows, delay driving to my destination and drive to the store, realizing that the store might not be open.
These are the requirements:
- 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.
- 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.
- Other requirements that surface
Future scenario. This is 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 Ed that I would be there at precisely 2 p.m. sharp. It would be great if I could just hit a button as I pass the antique shop and the GPS would record the closest street address or nearest intersection. I would like to be able to retrieve that information later and save it in My Favorites.
That brings me to the most important best practice of all: Empty your cup. There is a famous story about a university professor who kept talking about Zen to a Zen master, while the master poured tea until it overflowed. “You are like the cup,” the master said to the professor. “You are full to overflowing with opinions and ideas and grand theories. If you are to find what you seek, you must first empty yourself.”
And like that professor, you must rid yourself of preconceived ideas and prejudices if you want to truly understand user goals.
