Between the Manifesto for Agile Software Development and the Principles behind the Agile Manifesto, it is pretty clear that Agile is about satisfying the customer by providing timely, valuable software that serves the customer’s competitive advantage. To do this, we need to have a really clear idea of what kinds of problems the customer is trying to solve. Once we understand the problem right, we can identify one or more potential solutions. It’s the RIGHT solution that the customer values.

At its simplest, the chain of events is simple:

1. Customer identifies a problem.
2. Team devises a solution to address the problem.
3. Team builds the solution and solves the problem.
4. Customer is HAPPY!

The concept of a “User Story” (created circa 1997 by Kent Beck) and a format for writing them (created in 2002 by Rachel Davies) supports the idea of not only capturing the customer’s problem, but also doing so from the customer’s perspective.

“As a {role}, I want to {action} so that {justification or value}.”

So why do so many Product Owners and Scrum teams skip step 2 (“Team devises a solution to address the problem”) and go right to step 3? Let me tell you a short story…

It’s about a team building a new student management system for a university. The registrar, speaking with the Product Owner, explains a particularly difficult problem:

“You see,” the registrar says, “professors are SO frustrated with students texting and taking phone calls during their classes. More and more instructors are demanding that students either turn their phones off or, even better, to not bring them to class at all. This can cause a real problem for us when a family member calls with an emergency. They’ve been trying unsuccessfully to get in contact with the student. They want us to find the student for them and get them on the phone!”

“I see,” says the Product Owner, “Does this happen a lot?”

(Side note to all you Product Owners: Note the question, “Does this happen a lot?” Customers have lots of problems they want solved, but if a problem occurs rarely, a programming solution might be more expensive than the actual problem. Back to our story…)

“No,” says the registrar, “but even when it only happens once, if we can’t find the student or don’t try, the fallout in the press is absolutely horrible.”

“Got it,” the Product Owner says reassuringly, “tell me more.”

“There’s not a lot more to add,” says the registrar, “except that you don’t want to be on the phone trying to find the student, putting the family member on hold, asking for additional information when they are really upset or, worse, not being able to find the student at all.”

“Pretty bad?” the Product Owner asks.

“Sometimes the family member is so upset,” the registrar replies, “that they can’t even remember the student’s name. Asking for something like a birthdate can be useless!”

“OK,” says the Product Owner, “I’ll put that on the Product Backlog.”

Here’s the critical part of the story. The Product Owner takes everything they just learned and writes this:

“Story 1: As a registrar, I need to be able to search for students so that I can find them when someone needs to reach them.”

But wait…that isn’t actually what the registrar said at all, is it?

The registrar wants to be able to find a student in the event of a family emergency. Nowhere in their discussion with the Product Owner did they say, “I want to search for students.”

This is a case of the Product Owner writing a user story that is actually a solution (search for students) not a description of the problem (find a student when an emergency occurs).

So, when the software is eventually delivered with the Story 1 capability and that first dreaded emergency call comes in, imagine what happens:

1. The registrar has to somehow finish whatever they were doing when the call was answered,
2. then they have to start the “Search for Student” feature,
3. then they have to enter identifying information for the student,
4. assuming they find the right student, they have to open the student’s class schedule and identify where the student,
5. then they have to figure out how to connect the frantic family member to the student.

Does this sound like how you would want to handle an emergency?

What if instead, the user story was written like this:

“Story 2: As a registrar, I need to be able to instantly connect an emergency caller with the student so that the family member and student can discuss the family emergency.”

Let’s say that the team worked on Story 2 instead of Story 1. Perhaps now, when the software is delivered with the “Emergency Caller” story, this happens:

1. The registrar hits a pre-defined key sequence like “Control-Shift-E” which works anywhere in the product, no matter what the user is doing.
2. A pop-up window appears in the middle of the screen into which the registrar types whatever information they can get from the frantic caller: name, birthdate, major, etc.
3. The registrar submits the information and the product then tries multiple searches to find the right student.
4. If the right student is found, the class schedule is checked and, if the student is in a class, location information and contact information for the classroom and the instructor is provided. If the student isn’t in a class, it informs the registrar immediately that a location can’t be clearly determined. If the right student can’t be found, the registrar has the option to provide additional information to limit the search (or scroll through a short list of matches to visually find the right student).

This solution is not only easier to use, but it gets right to the point. If it can tell you where the student is, it does. This, after all, is what the registrar was really asking for.

So, not this:

“Story 1: As a registrar, I need to be able to search for students so that I can find them when someone needs to reach them.”

But this:

“Story 2: As a registrar, I need to be able to instantly connect an emergency caller with the student so that the family member and student can discuss the family emergency.”

The difference is in how you write the user story. Story 1 includes a pre-determined solution (search for a student) which isn’t what the registrar wanted. Story 2 simply relates the problem as explained by the registrar.

Sure, the registrar will probably eventually need a “search for student”-type functionality, but we are less likely to write unnecessary functionality if we record the customer’s problems instead of jumping write to solutions.

This is a very common problem. You’ve probably seen it too. Stories are written with a solution already in mind. The real challenge, however, isn’t the solution, it’s properly understanding the problem. When writing user stories, worry about getting the problem right.

If you want to find the right solution, you have to start with the right problem.

As the quote goes, “If I had only one hour to save the world, I would spend 55 minutes defining the problem, and only five minutes finding the solution.”

(The preceding quote has been attributed to Albert Einstein, but there’s no actual written or recorded evidence that he actually said it. Click this link for more info on that.)

Don’t Miss Your Opportunity!

Don’t miss your opportunity to become the user story maestro your team needs—register for our “Amazing Stories! 1” today! Amazing Stories 1 is your essential guide to writing effective user stories. This is your golden ticket to mastering the art of writing compelling and effective user stories that drive your Agile projects to unparalleled success!