Can user stories be prioritized using labels applied by the customer?

Question

So we have a disagreement between our customer and the development team, these are some facts:

• We are a software development company (I have a team of 3 devs and 1 QA)
• Our customer is a startup, that is growing fast, and already making some money
• We haven't successfully adapted to a workflow, yet

When we began the CTO choose pivotal tracker as our scrum board software, which works fine, however they are constantly adding labels to prioritize the items which I think doesn't make sense under the SCRUM approach where you have a sorting or order in the backlog (and in the current, per pivotal's feature) where, if you need certain story to be addressed or worked on then you need to make sure that is estimated, well defined and you just move it in the backlog to the top, developers then pick up these stories on a LIFO basis.

My motivation to tell the customer that they should not prioritize stories is simple: it is useless. These priorities change all the time, sometimes on every sprint, so the only sane way to keep up would be for them to be re-prioritizing all other stories, not only the new ones which they want to be worked on first, maybe some of the older stories that last week were priority 1 are now priority 2, or even less, plus the constant and ever-changing requirements make this harder, so why bother?

On my opinion this goes against the idea of the backlog and planning of the sprint, but I'm still a rookie on SCRUM so I'm wondering is this kind of prioritization a common practice in the real world?

Answer 1

TL; DR

Your underlying question appears to be whether the customer, rather than the Product Owner, should be allowed to prioritize the Product Backlog. You are also questioning whether label-based sorting is useful in any way.

In short, only the Product Owner (PO) may prioritize the Product Backlog, although s/he is expected to do so with the support and input of stakeholders that the PO represents.

Bucket-sorting or labeling can be a useful technique, but is not a substitute for a strictly-ordered Product Backlog. If labeling stories helps your stakeholders group stories or provides useful input for Backlog Refinement there is no reason not to do so, but labels are not a valid substitute for ordered Product Backlog Items (PBIs).

How to Properly Manage a Product Backlog

In Scrum, the Product Owner is a singular person. It must not be a group, a Borg collective, or anything other than one person fulfilling the responsibilities of the role. Like Highlander, "there can be only one!"

Also in Scrum, the Product Backlog is strictly ordinal. While using labels to sort stories into buckets or categories might be a useful feature to assist during Backlog Refinement, the Product Backlog must be sorted into an ordered list. There can never be two items marked #1 (or number #999 for that matter) in Scrum; the Product Owner must ensure that priorities are clearly defined and strictly sequential, even if means flipping a coin to decide between two important features.

Only the Product Owner may add, remove, or re-order items on the Product Backlog. While others (such as your customer) might suggest or recommend items or priorities, only the PO can actually place them into the backlog or adjust their priorities.

As a final word of caution, while the Product Backlog can be modified at any time by the Product Owner, these changes never affect work-in-progress for the current sprint. These changes are always for future sprints. If there is work that truly takes precedence over the work already accepted into the Sprint Backlog, then the Product Owner must call for an Early Termination of the current sprint and a return to Sprint Planning. This ensures that:

1. No one "moves the cheese" during the current sprint.
2. If it's truly necessary to move the cheese, then this becomes a visible cost to the project.
3. Stakeholders are given the tools they need to change direction when necessary, but are also clearly provided with appropriate inflection points for doing so without incurring additional project overhead.
4. The formal ceremonies involved in Early Termination and a return to Sprint Planning reduce unnecessary change while still providing a viable framework within Scrum for managing exceptional circumstances.

Answer 2

In Scrum it is the Product Owners responsibility to keep the Product Back log Prioritised and up to date. Some teams who have adopted Scrum have a Product Backlog Grooming (or refinement) session which might be once per sprint where the Scrum Master, Product Owner and some of the team (OR ALL) will get together to Estimate (put story points against stories in the backlog) - add new Stories and prioritise. Keeping the Product Backlog clean / sane / up to date is work, and is needed to be done.

You have to remember that one of the key aspects of Agile and Scrum is to be able to adapt to change, there might be new requirements that come in that need to be added to the Product Backlog and there needs to be time set aside to be able to organise the Product Backlog.

Take a look at this - https://www.scrumalliance.org/why-scrum/scrum-guide it gives a good overview of Scrum - especially

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Answer 3

I'm surprised no one has mentioned this yet, but you might also want to consider kanban, which tends to work well when priorities change so often that it becomes prohibitive for regular sprints.