Prioritizing the Backlog

Agile teams rely on a prioritized backlog 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 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, 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 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 (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 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 and opportunity costs

Feedback

Need more help? The CA Agile Central Community is your one-stop shop for self-service and support. To submit feedback or cases to CA Agile Central Support, find answers, and collaborate with others, please join us in the CA Agile Central Community.