Agile teams rely on a prioritized backlog

A collection of prioritized requests for work to be done.

to guide their work. The most important work is at the top of the list, available for the team to start as soon as they are ready. Less important work is ranked lower, and is elaborated only when it moves near the top of the list. As new work comes in that needs to be done, the product owner

The user responsible for accepting a work item.

adds it to the backlog in the appropriate position so that the team always knows what work to start next.

When to prioritize

• Rank the backlog continuously
• Once you have committed to an iteration plan

  A plan to achieve a specified level of functionality and meet additional specific criteria with a particular iteration of a system.

  , you should not change the rank of those committed items
• All other items can be re-ranked whenever you learn new information, usually in the form of feedback or information gathered from the team or stakeholders

Techniques for prioritization

• The product owner

  A role on an agile delivery team that is responsible for collecting and ranking business requirements on the product backlog. A product owner does not manage a delivery team, but communicates what must be built in the next release or iteration. In exchange for the team's commitment to finish the top-most ranked work in an iteration, the product owner agrees to protect the team from any changes in requirements during the iteration.

  must rank the backlog, deciding which story is first, which is second, which is third, and so on
• Initially prioritize backlog items using a bucket scheme such as MoSCoW

  An acronym used to prioritize work, or aspects of a particular feature. Stands for must have, should have, can have, and won't have. May be used to define the acceptance criteria of a user story.

  (must have, should have, could have, won't have)
• Subsequently, you can individually rank each item in the backlog, so that the team can always start the prioritized stories
• If a story contains various components that can be prioritized differently, consider breaking it down into multiple child stories

Consider the following when prioritizing:

• The value of the feature

  An improvement or capability of value to a stakeholder that can be developed in a PSI or release timebox (usually 10-12 weeks).

  for the masses
• The value of the feature to a few of the elite
• Story cost
• Estimated time to implement
• The impact it has on other stories
• Risk

  The level of impact on the successful outcome of a work item.

  and opportunity costs