When I work with teams on writing User Stories, the question always comes up: “What are User Stories and how are they different from requirements?”
The User Story is a format to write work items in a Product Backlog and it is used to shift the dynamic between Product Owner and Developers. User Stories help a Scrum Team to become more collaborative, to foster innovation, and to deliver better solutions.
Things get weird when User Stories are written like:
AS a Product Owner, I WANT to create xyz, SO THAT my customers can do abc
What’s wrong with this story? The Product Owner is not the user! The Product Owner is not the one getting the benefit from the story. They are just requesting the work.
Or consider this:
AS a Developer, I WANT to improve xyz feature, SO THAT my customers can use it
What’s wrong with this? The Developers are those doing the work, not the end-users (unless the work is done specifically for the Developers, like installing a new development tool for them to work better).
How to improve then?
Well, first, always write the User Story from the end-user’s point of view. Not from who’s requesting the work, not from who’s doing the work. From the end-user who will use the end-result of the work once completed.
Consider also that User Stories are not the only way that you can write work items in the Product Backlog. Consider in fact the System Story and Job Story formats.
The System Story format is useful for any internal work, bug solving, and performance enhancement work. The work is straightforward, so why try to articulate it using the User Story format? Use the System Story instead.
The Job Story is another format that is useful to represent the customer’s needs and create context about a scenario. The Job Story fits nicely to represent work items using Job-To-Be-Done. This makes it clear what job the end-user expects the system to perform to solve their needs.
