Prioritising features

Feature prioritisation decides what goes into a release first and what waits when not everything fits. It is two jobs, not one: ranking the candidates, then selecting the subset that the release’s capacity can hold [1].

1. What it is

Release planning behaves like packing a knapsack. Each feature has a value and a cost, the release has a fixed capacity, and the aim is the most valuable set that fits. The analogy breaks in one place: features depend on each other, and knapsack items do not.

Three families of technique each handle part of the problem:

  • Categories, such as MoSCoW, sort a long backlog quickly and build contingency into the plan.
  • Ratios, such as cost–value with the Analytic Hierarchy Process (AHP), show how unequal the features really are.
  • Models, such as EVOLVE and the Incremental Funding Method (IFM), add dependencies, weighted stakeholders, urgency and money, and propose several plans for a person to choose from.

2. Categories: MoSCoW

DSDM defines four categories [2]. The Must Haves are “the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver”. The test is consequence, not importance: “If there is some way around it, even if it is a manual and painful workaround, then it is a Should Have or a Could Have requirement.” A Should Have is important but not vital; a Could Have is “the main pool of contingency”; a Won’t Have is agreed not to be delivered this time. DSDM keeps Must effort at “no more than 60%” and Could effort “around 20%”, and gives no figure for the Shoulds. Why 60% works is on Buffered MoSCoW.

DSDM's balance of priorities for a project, increment or timebox: Must Haves typically no more than 60% of the effort, Could Haves around 20%, Should Haves with no figure, and Won't Haves out of scope for this timeframe

DSDM Consortium 2014, Fig. 10a.

Example. For Quill, a fictional word processor, saving a document is a Must: nobody would ship a word processor that cannot save. Autosave is a Should, because saving by hand is a painful workaround. A grammar checker is a Could. Autosave may depend on saving, but no Must may depend on autosave: “A Must Have cannot depend on the delivery of anything other than a Must Have”.

3. Ratios: cost–value

Karlsson and Ryan have customers compare features in pairs by value and engineers compare them in pairs by cost. AHP turns the answers into shares of the whole, and a diagram shows which features give high, medium or low value for their cost [3]. People cannot say what a feature is worth, but they can say which of two is worth more.

On an Ericsson radio project, 14 requirements took 91 comparisons per criterion and about an hour. With three of them dropped, “the software system’s value for its customers would be 94 percent of the possible maximum, while the cost would be reduced to 78 percent of the cost for implementing all requirements.”

Karlsson and Ryan's cost-value diagram for 14 requirements: two lines at value-to-cost ratios of 2 and 0.5 split high, medium and low value for cost, and the three dropped requirements, 10, 11 and 12, sit in the low band

Karlsson and Ryan 1997, Fig. 4; red labels ours.

The price is the comparisons: doubling the list quadruples the effort [4]. And by the authors’ own account the method “takes no account of interdependencies between requirements” [3].

4. Models: EVOLVE and IFM

EVOLVE weights the stakeholders, collects each one’s urgency and value ranks, respects effort and precedence constraints per increment, and returns several good plans: “The emphasis of decision support is on support, not on actually making the decision” [1]. IFM adds money and time: a car-reservation feature is worth $266K if started in the first period and $145K in the fifth [5]. When a feature ships is part of what it is worth.

5. Choosing a technique

Name the factors your situation needs first, then pick the cheapest technique that covers them [6]. Categorise a long backlog with MoSCoW. Keep pairwise ratios for the 10–20 high-level decisions that carry the money. A model earns its data cost only when many stakeholders disagree, dependencies are real and features run to dozens. Whatever the technique, the client decides on value and the developers advise on cost and risk [7]. A language-model prototype now produces an AHP ranking in seconds [8]; it removes the tedium, not the judgement.

How solid is this?

  • Where it comes from. DSDM is a certification handbook; its 60% and 20% are recommendations without evidence. Karlsson and Ryan report two small telecom cases with no control group.
  • What is thin. A review of 73 studies found 49 techniques, whose use in complex real settings “has not been reported yet” [4]. Of 24 release-planning models, four have reports of full-scale industrial use [6].
  • What is constructed. EVOLVE’s case and IFM’s figures are invented projects. The language-model result is an unrefereed preprint that never compares its ranking with a human one.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda [9] on software project management.

References

  1. D. Greer and G. Ruhe,
    “Software release planning: an evolutionary and iterative approach,” Information and Software Technology, vol. 46, no. 4, pp. 243–253, Mar. 2004, doi: 10.1016/j.infsof.2003.07.002.
  2. DSDM Consortium,
    The DSDM Agile Project Framework. Dynamic Systems Development Method Limited, 2014. [Online]. Available: https://www.agilebusiness.org/wp-content/uploads/2026/05/DSDM-Agile-Project-Framework-Handbook.pdf
  3. J. Karlsson and K. Ryan,
    “A Cost-Value Approach for Prioritizing Requirements,” IEEE Software, vol. 14, no. 5, pp. 67–74, 1997, doi: 10.1109/52.605933.
  4. P. Achimugu, A. Selamat, R. Ibrahim, and M. N. Mahrin,
    “A Systematic Literature Review of Software Requirements Prioritization Research,” Information and Software Technology, vol. 56, no. 6, pp. 568–585, 2014, doi: 10.1016/j.infsof.2014.02.001.
  5. M. Denne and J. Cleland-Huang,
    “The incremental funding method: data-driven software development,” IEEE Software, vol. 21, no. 3, pp. 39–47, May 2004, doi: 10.1109/MS.2004.1293071.
  6. M. Svahnberg, T. Gorschek, R. Feldt, R. Torkar, S. B. Saleem, and M. U. Shafique,
    “A Systematic Review on Strategic Release Planning Models,” Information and Software Technology, vol. 52, no. 3, pp. 237–248, 2010, doi: 10.1016/j.infsof.2009.11.006.
  7. Z. Racheva, M. Daneva, A. Herrmann, and R. J. Wieringa,
    “A Conceptual Model and Process for Client-Driven Agile Requirements Prioritization,” in Fourth International Conference on Research Challenges in Information Science (RCIS), IEEE, 2010, pp. 287–298. doi: 10.1109/RCIS.2010.5507388.
  8. M. A. Sami, Z. Rasheed, M. Waseem, Z. Zhang, T. Herda, and P. Abrahamsson,
    “Prioritizing Software Requirements Using Large Language Models.” 2024. [Online]. Available: https://arxiv.org/abs/2405.01564
  9. E. Miranda,
    “Managing Software Development.” 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.

This site uses Just the Docs, a documentation theme for Jekyll.