Isolating and Prioritising Features

by ts8richardson

Another aspect of feedback this week was to consider looking into the methods for Agile development, and specifically how features can be prioritised based on User Stories. This isn’t something I know much about, so I’ve looked into both Agile Development and the many methods for prioritising development.

Agile Development

Agile development is about:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

One of the key ideas in Agile development is changing requirements and needs and responding on short time scales. It is also about continually developing and improving software.

Agile Alliance :: The Agile Manifesto [WWW Document], n.d. URL (accessed 3.24.13).

Most versions of agile development have a prioritisation phase that delineates which features or aspects of development will be included, and then a development phase, in which developers commit to developing the prioritised features. This allows for a constant evolving and changing product.
One such method is the Scrum method, where teams have a prior meeting to determine priorities, then follow this with a Development Sprint. Another method is Feature Driven Development,  which begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. The features are small, “useful in the eyes of the client” results. Unlike other agile methods, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.
A third method, Dynamic Systems Development, operates as follows:

Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules:

M – Must have requirements
S – Should have if at all possible
C – Could have but not critical
W – Won’t have this time, but potentially later

All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule.

Agile Methodology – Agile Methodologies for Software Development [WWW Document], n.d. URL (accessed 3.24.13).

Prioritising Development

I’ve come across a number of techniques for prioritising development, and Berander and Andrews (2005) offer the best summary for the range of techniques, their uses and benefits/ drawbacks. A summary of their paper follows:

When prioritising, it’s important to understand what factors you are using to generate priorities  There are six main areas to consider: Importance, penalty, cost, time, risk and volatility


1. Analytical Hierarchy Process (AHP)

AHP is conducted by comparing all possible pairs of hierarchically classified requirements, in order to determine which has higher priority, and to what extent (usually on a scale from one to nine where one represents equal importance and nine represents absolutely more important).

2. Cumulative Voting, the 100-Dollar Test 

The 100-dollar test is a very straightforward prioritization technique where the
stakeholders are given 100 imaginary units (money, hours, etc.) to distribute between the requirements. The result of the prioritization is presented on a ratio

3. Numerical Assignment (Grouping) 

Numerical assignment is the most common prioritization technique. The approach is based
on grouping requirements into different priority groups (e.g. critical, standard, optional).

4. Ranking

As in numerical assignment, ranking is based on an ordinal scale but the requirements are ranked without ties in rank. This means that the most important requirement is ranked 1 and the least important is ranked n (for n requirements).

5.  Top-Ten Requirements

In the top-ten requirements approach, the stakeholders pick their top-ten requirements (from a larger set) without assigning an internal order between the requirements. This makes the approach especially suitable for multiple stakeholders of equal importance.

The following table outlines the scale, granularity and sophistication of each technique:

Prioritise techniques

Berander, P., Andrews, A., 2005. Requirements Prioritization, in: Aurum, A., Wohlin, A. (Eds.), Engineering and Managing Software Requirements. Springer Verlag.

If we are to use an Agile approach, using a simplified version of AHP might be a good strategy for us.

Stuart (2008) uses an adapted model, which produces prioritised requirements by a 2×2 scale as shown below:


Stuart, J., 2008. Early Requirements Prioritization Technique: Best Practices White Paper. Construx Software.