Prioritization V/s Ranking

Prioritization is how your backlog is separated into high and lower value items with respect to overall stakeholder, strategic or business value. Ranking helps determine when an item will be pulled into the queue and considers such development factors as cost, complexity and Risk in addition to priority.

Prioritization and ranking are the primary tools used to determine when the items get in the development queue. These are business decisions usually made by product owners.

Using a combination of prioritization and MoSCoW (DSDM)

One of the most popular methods of prioritizing agile project requirements is the "Moscow "approach. This stands for 'Must, Should, Could, Won't'. The only problem with this method is that everything is usually a must, which doesn't allow proper agile release planning, because the requirements aren't necessarily put in order of priority.

MUST (M) - Defines a requirement that has to be satisfied for the final solution to be acceptable, e.g. The HR system “must” store employee leave history.

SHOULD (S) - This is a high-priority requirement that should be included if possible, within the delivery time frame. Workarounds may be available for such requirements and they are not usually considered as time-critical or must-haves.

Example : The HR system “should” allow printing of leave letters.

COULD (C) - This is a desirable or nice-to-have requirement (time and resources permitting), but the solution will still be accepted if the functionality is not included. E.g. The HR system “could” send out notifications on pending leave dates.

WON’T or WOULD (W) - This represents a requirement that stakeholders want to have, but have agreed will not be implemented in the current version of the system.

That is, they have decided it will be postponed till the next round of developments. E.g. The HR system “won’t” support remote access but may do so in the next release. This technique is best used when

Assemble all stakeholders – each stakeholder is responsible for assigning priorities to the requirements that fall under their purview. All Requirements are listed on a chart and prioritised by assigning categories to each (M, S, C or W). If there are multiple stakeholders with different opinions on what category to assign to a requirement, voting can be used to reach consensus. The requirements are reviewed throughout the project as stakeholder needs may evolve with time.