What is reason for prioritizing and ordering (ranking)

The Scrum Guide says that "Product Backlog items have the attributes of a description, order, estimate and value." Can you explain what you mean by prioritization?

Ian,

Thanks. In our organisation; we are introducing Agile scrum. Levels above are used to priority attribute. How can I relate/explain that priority is no longer used?

Also tools are centric around priority rather then ordering/estimate/value even though they are claiming scrum!?

In other words, I am looking for some practical tips/tricks to convince usage of ordering...

thanks in advance,

hans

Hi Johannes!

What is the difference between "ordering" and "prioritizing" at your company? Can you define each one of those terms for us so we can give you a more accurate answer?

"Ordering" and "Prioritizing" are same thing as per my knowledge.

Hi Johannes

As I understand it because of the wording you're using, your company is using Jira, which has a field called "priority" and seems to confuse you when it comes to backlog management in scrum.

Think of the order of the backlog as priority, but not having only 4 or 5 different priority options, but infinite. Priority implicates what kind of things should be done prior to others because it is more mportant. And according to the scrum guide the backlog should be ordered by the product owner in a way to get the most value out of the effort that goes into development - or as stated in the scrum guide, the product owner should be "ordering the items in the Product Backlog to best achieve goals and missions".

Maybe this explanation helps you on your convincing mission.

A Product Backlog Item can have many attributes, and not just those which are enumerated in the Scrum Guide. If a "priority" attribute adds value above and beyond the logical ordering of items, then the Product Owner is free to include it. If a "priority" attribute isn't useful then it is probably best not to include it, regardless of what tool vendors think you should be doing.

An example of when such an attribute might be useful is the provisioning of contingency in a Sprint. If the PO orders the Product Backlog so that high priority work is mixed with at least some lower priority items, then those lower priority PBIs may provide scope contingency during Sprint Planning. Not everything will be high priority and the lower priority items may be forsaken without compromising the Sprint Goal. The thoughtful provisioning of such contingency during refinement could make it easier for the Development Team to commit to a Sprint Goal framed around higher priority items.

Dear Ian,

I have 2 questions on your above explanation:

1. What is contingency in sprint?

2. Is my understanding correct: In addition to high priority PBIs chosen for a sprint, if we have some time left in a sprint which can be eventually used for some low priority PBIs (sort of filler), then while ordering, the low priority PBIs will come as higher order than other items? This is my interpretation of priority and order.

Contingency is in line with what we call Stretch goals, where you have some low priority PBIs available once sprint goal is achieved and there is reasonable time available with the team to take up these additional PBIs which were not part of the Sprint backlog initially. Basically it's additional work that can be achieved without endangering the sprint goal only after achieving the Sprint goal.