To successfully define a release plan (or iteration plan), the list of stories must be rank-ordered sequentially so that the team understands the priority order in which to complete the work.  As you might expect, the items higher on the list are the ones that are most valuable to the product owner and are needed to make the product usable and/or marketable.

There is no one set way or strategy to prioritize a backlog.  It depends on several factors such as the product, technical aspects, preferences, or driving profit. To get started, the product owner and team should consider the following when making decisions on priority:

• Value – Benefit to the organization
• Risk – Amount of risk mitigated once completed (i.e. new technology, integration points)
• Knowledge – Will the team’s collective intelligence benefit by completing early?
• Cost/Benefit – How much to develop and support vs. the return?
• Low Hanging Fruit – Easy-to-implement features that provide significant value

With regards to risk, as an example, some features involve designs, architectures, frameworks, or algorithms that are new to the team or require additional research. Even if such features do not deliver the highest business value, it may make sense to bump their priority up enough to tackle them in earlier iterations. If a high-risk feature is addressed early in the project, and for some reason proves unworkable, the team still has time to react and compensate. This minimizes the overall risk to the project. It is up to the development team to work closely with the customer to help identify these types of issues, risks, and dependencies. It is ultimately up to the customer to prioritize features, but this critical process should not occur in a vacuum. The best teams work together to both deliver value and reduce risk throughout the life of a project.

Another technique used to help prioritize is called MoSCoW:

• Must Have – these features are critical to the success of the product/project and it cannot go live without them
• Should Have – these features are important, but not required, and can be delivered in a subsequent iteration or release
• Could Have – these features are beneficial and often considered ‘nice to have’
• Would Like (or Won’t Have, but Would Like) – these features are the least important, and are often dropped from the initial release or incorporated as low hanging fruit if very easy to implement

When utilizing the MoSCoW technique, it is often advisable to have a mix of priorities throughout the backlog, or adjust prioritization to allow some of the smaller “could haves” and “would likes” to be included for the team to take on to fill up the iteration.

It is critical to remember that prioritizing the backlog is not a one-time deal.  The backlog needs to continually be “groomed” as new features are identified, broken down into smaller features, split, removed and changed.  The product owner and team should review and adjust priorities based on feedback received, knowledge gained and changes to the business.  Having a prioritized backlog also helps when making decisions on what to drop from a release, in the event the team does not complete the features as fast as planned or if scope increases over the course of time.