A uniting thread through the variety of different agile methods is the fact that they all employ work prioritisation schemes. While the terminology varies--Scrum for instance has a “product backlog”, FDD a “feature list” and DSDM a “prioritised requirements list”--the concept is the same. The project works through a prioritised list of items that have discernable business value.

Prioritisation is required because it enables the flexing of scope to meet budget or timeline objectives while retaining a useful set of functionality (Minimum Marketable Release).


 

Prioritisation also provides a framework for deciding if/when to incorporate changes. By asking the business to “Tell me what it is more important than?” and then inserting the new change into the prioritised work list at the appropriate point, it is possible to include changes.

 

It is worth explaining that while agile methods provide tremendous flexibility through the ability to accept late-breaking changes, they cannot bend the laws of time and space. So if your project time or budget was estimated to be fully consumed with the current scope, then adding a new change will inevitably force a lower priority feature below the “cutoff point” of what we expect to deliver. So, yes, we can accept late-breaking changes…but only at the expense of lower-priority work items.

A single prioritised work list also simplifies the view of remaining work. Rather than having separate “buckets” of work for change requests, defect fixes and new features, by combining them into a single prioritised list, people get a clear, complete view of all remaining work. Many teams miss this point to begin with and retain bug-fix and change budgets. This muddies velocity; a single prioritized list of work-to-be-done regardless of origin offers better transparency and trade-off control.

Behind Every Scheme is a Schemer
How we go about prioritisation (and the prioritisation schemes used) varies from method to method--and sometimes project to project--based on what works for the business. A simple scheme is to label items as “Priority 1”, “Priority 2”, “Priority 3”, etc. While straightforward, a problem with this is that there is a tendency for everything to become a “Priority 1”--or at least too many things are labeled “Priority 1” for the scheme to be effective. It is rare that a business representative asks for a new feature and says it should be a Priority 2 or 3, since they know that low-priority items risk missing the cut off. Likewise, “high”, “medium” and “low” prioritisations fall victim to the same fate. Without a shared, defendable reason for what defines “high”, we end up with too many and a lack of true priority.

DSDM popularized the MoSCoW prioritisation scheme, deriving its name from the first letters of its labels of “Must…”, “Should…”, “Could…”, “Would like to have, but not this time.” Under MoSCoW, we have some easier-to-defend categories. “Must-have” requirements or features are fundamental to the system; without them, the system does not work or has no value. “Should have’s” are important--by definition, we should have them for the system to work correctly; if they are not there, then the work-around will likely be costly or cumbersome. “Could have’s” are useful net additions that add tangible value, and “Would like’s” are the “also-ran” requests that are duly noted--but unlikely to make the cut.

An approach I have seen work well is giving sponsors Monopoly money equalling the project budget and asking them to distribute it amongst the system features. This is useful for gaining general priority on system components but can be taken too far if applied to question perceived low value-add activities like documentation, so keep it for the business features.

If you do not have any Monopoly money available, the 100-Point Method originally developed by Dean Leffingwell and Don Widrig for use cases can be used instead. It is a voting scheme where each stakeholder is given 100 points that he or she can use for voting in favor of the most important requirements. How they distribute the 100 points is up to them: 20 here, 10 there or even all 100 on a single requirement if that is their sole priority.

The Requirements Prioritisation Model created by Karl Wiegers is a more mathematically rigorous method of calculating priority. Every proposed feature is rated for benefit, penalty, cost and risk on a relative scale of 1 -9 (low to high). Customers rate the benefit score for having the feature and the penalty score for not having it. Developers rate the cost of producing the feature and the risk associated with producing it. After entering the numbers for all the features, the relative priority for each feature is calculated by considering the percentage of the weighted feature desirability to each feature. (For more details and link to an example, see Karl’s outline First Things First: Prioritizing Requirements; also, for more analysis on mathematical models on requirements prioritisation try this US-CERT paper.)

No Scheme as a Scheme
At the end of the day, it is the prioritisation of features and not the scheme we need to focus on. Sometimes refereeing the schemes themselves can detract too much time from meaningful discussions. For this reason, I am personally a fan of simply asking the business to list features in priority order. No category 1,2,3s; no high, medium, lows; no must haves, etc,--instead, just a simple list (whether this is in Excel or an agile requirements management tool). This removes the categories that people tend to fixate upon from the debate and leaves the discussion around priorities.

Conclusion
By all means get creative and try different schemes to engage the business in the prioritisation. There is no single best way to always prioritise; instead, try to diagnose issues arising in the prioritisation process, be it “lack of involvement” or “too many priority 1’s”, and then try approaches such as Monopoly money, MoSCoW or a pure list to assist if the problems cannot be resolved via dialogue. The goal is to understand where features lie in relation to others as opposed to assigning a category label. By maintaining a flexible list of prioritised requirements and having opportunities to revisit and reprioritise, we maintain the agility to deliver the highest value set of features within the available time and budget.

(I wrote this article originally for Gantthead.com and it appeared in April 2011 here)