A great bar-raiser for a user story as a product manager, is to leverage a well-known industry mnemonic, called INVEST. Any user story that fails to meet that criteria should definitely be a candidate for a re-write. So what is INVEST?
“The INVEST acronym applies to having superior quality in the actual product backlog and serves as a way to check ourselves and not to produce defects or waste in the process flow.”
Excerpt From: J. Ashley Hunt. “PMI-ACP Project Management Institute Agile Certified Practitioner Exam Study Guide.” Apple Books.
Or rather, independent of all others. Software engineers will recognize this as decoupling as a self-entity, ensuring that the user story does not overlap with any other user story, and thus is independent enough that it can be implemented in any order.
This infers that each user story is nible enough that it is the outcome of collaboration between the product owner and scrum team. In other words, a well-written user story describes the what of the feature, but now the how, leaving the details for the engineering team to develop. This fits in well with the structure of user stories, which are in turn composed of tasks.
Self evident but stories should result in an outcome that is valuable to the customer (and not the developer).
This is especially an issue when splitting stories. Think of a whole story as a multi-layer cake, e.g., a network layer, a persistence layer, a logic layer, and a presentation layer. When we split a story, we’re serving up only part of that cake. We want to give the customer the essence of the whole cake, and the best way is to slice vertically through the layers. Developers often have an inclination to work on only one layer at a time (and get it “right”); but a full database layer (for example) has little value to the customer if there’s no presentation layer. (XP-123)
A user story also needs to be clear and composed enough that during sprint planning, it can be estimated. This requires the right fidelity of information, user acceptance criteria for the scrum team to digest in a single sprint. Any bigger and its too complicated and may have to be split.
Following on from the previous point, good stories are small, and sprint-sized. Keep the description and user acceptance criteria succinct.
Alistair Cockburn described the cards as tokens promising a future conversation. Remember, the details can be elaborated through conversations with the customer.
Finally, the user story needs to be testable, and demonstrate-able. If it is not verifiable by both the scrum team first, and during sprint review, demonstrated to the product owner, then the defition of the story and its acceptance criteria will need to be re-thought. In fact, leveraging the test-driven development philospohy, write the tests first to ensure you can test the proposed solution, confirm with the product owner, and build for that.