Prioritisation Rules

In order to support agile development processes and rapidly changing requirements, a project team needs to be able to establish the priority of all its requirements. It also needs to be able to quantify the amount of risk associated with a requirement. When combined these two factors give a very easily implemented but precise mechanism for managing an ordered set of requirements.

MoSCoW Rules

The requirements of a project should first be prioritised using a scheme knows as the MoSCoW Rules. The o's are there for fun but they could stand for 'ontime' and 'on budget'. The MoSCoW rules provide the basis on which decisions are made about what the project team will do over the whole project, and during any timebox within the project.

Timeboxes are fixed, although the deliverables from the timebox may vary according to the amount of time left. Essential work must be done and only lesscritical work can be omitted. In order to facilitate this prioritisation MoSCoW rules are applied. A clear prioritisation is developed ensuring the essential work is completed within the given timeframe.

• Must Haves - fundamental to the projects success
• o
• Should Haves - important but the projects success does not rely on these
• Could Haves - can easily be left out without impacting on the project
• o
• Won't Have - this time round can be left out this time and done at a later date

All the priorities are reviewed throughout the project to ensure they are still valid. It is also essential that not everything within a project or a timebox is mandatory. It is the less critical elements that enable the teams to deliver on time, by omitting less critical requirements. If problems do arise. This ensures the project is delivered on time without loss in quality.

H/M/L Risk

Prioritisation is only part of the picture, given that all you are doing is signifying what is critical to the project, what is needed but not critical, and what can be left out, what is missing so far is a measurement of risk for a particular requirement. Risk can be measured in many different ways, but generally it can be applied to specific areas:-

Functional Risk defines the amount of risk on the implementation of the project if a particular requirement is not met. For example a MUST requirement stating that the system must have finely grained security, is functionally a high risk, if its not implemented early on in the development, the cost of implementing it later, after a high number of other MUSTs have been completed, would be significantly greater, and would possibly cause major problems to the overall design and implementation.

Business Risk defines the impact on the business if the particular requirement is not delivered. For example if the system cannot meet a specific performance requirement and process the daily set of transactions then the business would be at risk of loosing customers and money.

Score Cards

Taking a leaf from the Agile Development processes and the use of Stories and Story Cards. Each requirement is written down on a index card. Each requirement can then be placed in a stack or Must, Should, Could, Won't. The first 3 can then have functional and business ratings applied to them.

We next assign values to each of the ratings as follows

• Priority
  • Must 5
  • Should 3
  • Could 1
  • Won't 0
• Functional Risk
  • High 5
  • Medium 3
  • Low 1
• Business Risk
  • High 5
  • Medium 3
  • Low 1

What we can now produce is a total for each requirement which gives a range of from 3 for a Could/Low/Low to 15 for a Must/High/High. The benefit of this approach also means that the focus is not entirely 100% on business requirements, but means that high risk functional requirements also are addressed earlier in the project. Teams can then re-order their MoSCoW graded stacks into weighted scores and know that they are always delivering the most needed requirements.