I updated this post after I realized that it is more about prioritizing user stories than it is about writing them well.
In Scrum, a product owner writes user stories to capture requirements and prioritizes them in a product backlog as the upcoming work queue for developers. The main question on my mind is:
Who has the capabilities and competencies to write good user stories and prioritize them in a product backlog?
The INVEST criteria list quality measures (of sorts) that determine what a good user story is. It should be Independent, Negotiable, Valuable, Estimatable, Small, and Testable. While fundamentally correct, there is much more to say. For example, in a product backlog, user stories should use a consistent vocabulary, based on a shared domain model (or glossary, at a minimum).
However, the real story so-to-speak is in the sorting of user stories into a sensible order, also known as prioritizing stories in a product backlog. User stories need to be aligned with requests for bug fixes and refactorings. They need to be sorted with respect to each other to reflect technical and other dependencies. No point of implementing a logout feature before you even have a login feature or implementing a print-a-doc before you have some PDF conversion feature.
In my courses, non-technical people often fail at writing good user stories and prioritizing them right. The needed underlying understanding of the technology and state of the software is too complex to be grasped if all you have is a business background. From my experience, business people can therefore formulate high-level features (epics), but not user stories, nor can they put them into a sensible detailed order.
This vibes well with the actual behavior in my agile projects. Developers are already responsible for breaking down user stories into tasks, and no business person would interfere with that. It only makes sense to me that a technical persone, e.g. a classic software architect, takes over user story writing and prioritizing as well.
Leave a Reply