Is it useful to require a priority justification in scrum user stories?

Question

Not to get too meta, but I was just about to write up a story to add "require priority justification when changed" to our company's Scrum software. And I was thinking, as a Scrummaster, that's not one of the two things that we need spelled out to get things done (i.e. the user story and acceptance criteria). But I'd like to add it to some stories so that the PO can know why I think it might be a higher priority even though I'm not the one doing the final prioritization.

So, is it useful information in Scrum for the person writing the story to say why they think they need it sooner than later or does this information just get lost in the weeds usually?

Answer 1

The answer to your question lies in the "3 C's of User Stories". The first C of the user story is the card (the thing you're writing) which acts as a sort of reminder and a placeholder for the second C, the conversation. Many of the people who introduced and popularized user stories have called out that the reason they used index cards was because there was specifically not enough space to write everything needed on the card and it forced you to have the conversation.

So, to your questions specifically, the "so that" part of the canonical user story on the card may hint at the need, but a bulk of the explanation for why it should be prioritized comes in the conversation with the product owner.

Answer 2

Let's consult The Scrum Guide.

The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog.

The desire to "require priority justification when changed" violates the Scrum framework.

Let's also look at the principles from the Manifesto for Agile Software Development.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Though specifying development team it would also apply to

I'd like to add it to some stories so that the PO can know why I think it might be a higher priority

Recording the why of changing the order (not priority) might be something that the Product Owner would want to track, but should probably not be a requirement.

Also note that, although commonly used, user story is not an aspect of the Scrum framework.