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?

2 Answers 2


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.

  • I guess we could be having those conversations, but the odds that he's going to remember to set priority or remember why he set priority is pretty small - maybe that just means the backlog is too big. Jan 25, 2018 at 15:17
  • That is very possible. Part of the Product Owner's job is to understand what is in the backlog and make sure it is prioritized appropriately. If he is losing track of items and why they are there (for any reason), that is definitely a problem that should be corrected.
    – Daniel
    Jan 25, 2018 at 16:22

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.

  • +1 for this. How the Product Backlog is structured is for the PO to decide, provided that it’s ordinal. And Backlog Refinement is the place to talk about it with the PO; cluttering PBIs with information that should be a conversation is an agile anti-pattern.
    – Todd A. Jacobs
    Jan 26, 2018 at 19:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.