As a [role] I want [something] so that I can [benefit].
Most of us know the form a user story takes; it’s the content that is in question.
Before you read any further, find a story in your backlog. (I’ll wait). Okay, now look at that story: is it a statement of an issue that the client wants to address? Or is it a task that you want your team to perform?
In my workshops with product teams, I find using a good example from your product uncovers this dichotomy: The product manager tries to write requirements in form of a story while developers want specifications written in the user story format.
Let’s look at this example.
User story: As a reader, I want to highlight passages of text so that I can quickly find them again.
You’ve probably encountered this situation in your everyday reading. But uh oh; the user story in this example not only expresses the problem but also suggests a solution (“highlight passages.”) Is it the only solution? And is it the best solution?
So what is the problem?
When I’m reading, I often spot passages I know I’ll want to find again.
Industrial designers and User Experience (UX) experts explore the original story and investigate different methods to address the story. Maybe you should highlight the passage or maybe press a button and save the page in question for later review. Is the highlight just visual or is the highlighted passage also written to a file for later retrieval?
The industry plays fast and loose with this term but a product requirement is a statement of the problem to be solved. And a specification fully describes the solution and how it will be implemented. And most user stories are neither.
What’s usually missing is a feature definition, a design.
Maybe that’s why UX books and presentations are so popular with product managers. Because when they don’t have UX people, product managers and product owners try to fill the void.
Ideally, a customer expert should tell stories about users, a usability expert will convert these into user stories, and the product team can break those into tasks and deliverables. And this process is best done in a team setting so everyone benefits from the discussion.
Furthermore, many requirements and user stories are really bug fixes for a poor design.
Here’s one…
User story: As a bank customer, I want to retrieve my card before getting my cash so I don’t forget the card in the machine.
There was never a customer requirement to put the card in the machine, much less to lose it there. But for security reasons, the original design teams decided that a mag-strip on a cash card would be the easiest way to protect people’s money. And after a few hundred customers took their money and left their card, the banks realized they should spit the card out immediately after the sign-in process and dramatically reduced the number of abandoned cards.
Let’s look at another example. You’ve probably encountered this in your ebook reader. Some titles are not alphabetized correctly. Maybe it’s a flaw in the program or it’s a mistake made by the publisher. No matter, author Ernest Hemingway belongs in the H section and his novel The Old Man and the Sea belongs under O and not T.
As a Kindle user, I want all my books filed according to alphabetization standards.
Developers who write sort routines should know how to alphabetize — “A” and “The” are never considered when sorting book titles. But following these rules means extra work for the developer—it’s easier to sort them as dumb strings but a dumb sort is still wrong.
A designer may suggest a few approaches to this situation. First, make sure the sort routines follow the standard approach for alphabetization. Second, let the user edit the title and author information when it’s wrong, and third, revise the programs used by publishers to ensure that the book’s metadata is entered correctly in the first place. And (notice this), addressing this problem may affect three different products.
Should you have to write a requirement? A user story? Well, no, you shouldn’t have to but you will. It’s the same as finding typos. “As a user, I want you to spell your company name correctly so that I can not be annoyed with you.”
Maybe Jira has it right after all; call everything an issue and be done with it.
If you look at requests and see a common one—whether for a new capability or a revision to an old one—go ahead and write it down. Make sure your team understands the situation—tell ‘em a story. And it doesn’t have to be in user story format. Use this article to spark a discussion with your team.
Pictures courtesy of pictofigo.
I’m going to take a contrarian point of view here. (Maybe you will agree.)
For years I bought into the idea that I should write requirements (problem statements or user stories) rather than specifications. It just sounded right that as the expert on the market, I should concentrate on providing that intelligence to the development team, including the UX person, and let their creativity shine through in the solution.
Sounded good but I soon gave up.
Why? To start with, companies are reluctant to hire enough UX people. Worse, most UX people I’ve worked with are like engineers in that they also kind of want a concrete set of expectations rather than a vague “story” or “problem.” It’s just less work for them if you give them the answer.
Maybe I’ve become cynical. Maybe I’m just tired of writing problem statements and then having to feed the obvious answer to the designers and implementers after anyway. (Maybe I’m just a control freak.) But, to use your ATM example, I just don’t see UX designers eliminating the need to swipe your card to avoid the problem of losing the card. They just don’t have the scope to think about the problem at that level. (Perhaps Jony Ive of Apple has that kind of scope but not most UX designers.)
So my user stories happen at different levels. I first write an epic that explains the market problem at a high level (I want to authenticate securely) but then follow it up with stories that roll up to that epic (I want you to return my card to me right away so that I don’t forget it at the end of my transaction). Req-specs? Probably. But also effective.
I haven’t had the pleasure of working with good UX designers, so I end up explaining the smallest problems/specs as acceptance criteria or in wireframes.
I feel Steve’s description of story format is neglected here. “as a ___ i want to ____ so that ____.” is extremely powerful. In my opinion Behaviour Driven Development mentality is the foundation for delivering applications with great user experience.
All my stories follow Cucumber format, it’s a gem (no pun intended). check it out if you’re not familiar with it.
a wireframe and cucumber like description is all a story needs in terms of documentation, The rest can be discussed.
We don’t have a large team so it’s myself, the engineers and QA. I bring in the market knowledge and the user stories, I then work with the engineers to discuss the best way to technically solve the problem, then I finalize the document which would be more of a req./spec.
I collaborate with the team as a whole to ensure the problem is solved in the best way possible. As the product manager it ends up being my responsibility to ensure all requirements and specifications are documented.