For agile teams, the biggest area of friction for agile teams is agreement on what constitutes a story. Product managers and product owners try to write market requirements in the form of a story when many developers really want product specifications.
It seems so simple. Product managers and product owner write user stories; developers break them into tasks and develop the feature. But the difficulty facing many agile teams today is what, exactly, is a user story?
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.
Related post: User stories vs user goals by Edward Brown.
[Need help applying this principle in your organization? Contact me.]
Pictures courtesy of pictofigo.
I had the pleasure of seeing my colleague Barbara Nelson at Silicon Valley ProductCamp last Saturday. Her session on “Done ain’t Launchable” was great. She quoted me, Saeed Khan, and The Big Bang Theory. What’s not to like? You can download her slides from Slideshare.
PS. I told Shaggy Dog Stories about product management. See if you can make sense of my slides. Download them here.
Tactical tools stored in a desk are worthless; they must be published internally to be effective. “Publish or perish” is as true for product leaders as it is for academics: if the company does not know what you do, then what you do is not important to the company.
