Who Writes and Prioritizes User Stories?

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.

Posted on

Comments

  1. marstein Avatar

    Knowledge of the business is what the product owner brings to the table. While awareness of the underlying technology is important without the business requirements an architect could well run up the wrong hill. In addition it would be wise to have someone from QA and possibly ops at the table to write stories. I heard user stories described as ‘requirements in context’. Providing the context is hard and requires quite a lot of knowledge.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share the Joy

Share on LinkedIn

Share by email

Share on Twitter / X

Share on WhatsApp

Featured Startups

QDAcity makes qualitative research and qualitative data analysis fun and easy.
EDITIVE makes inter- and intra-company document collaboration more effective.

Featured Projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use