PRINCE2 Agile 2016
Previous Section   Next Section

25.5 Requirements prioritization

Requirements prioritization is an essential part of using PRINCE2 in an agile environment and is at the heart of how it works. Continual prioritization of what is being delivered and the work being done enables deadlines to be hit and the quality level to be protected.

25.5.1 Approaches to prioritization

With respect to product delivery, there are two approaches to prioritization that are frequently used when working in an agile way:

  • MoSCoW
  • ordering (1, 2, 3 ... n).

It is important to use the correct approach in the correct situation because these do not work in the same way.

MoSCoW typically works at higher levels and over longer timescales where requirements may be grouped by function and dependencies exist between these functions.

Ordering primarily works at a lower level (or task level) where certain technical activities are taking place.

The choice of approach will be dictated by the level of uncertainty of the work being undertaken. Generally speaking MoSCoW would be the default approach, as it specifically addresses situations where work is time-bound and finite such as when working on a project, or in a timebox.

25.5.2 Definition of MoSCoW

This acronym is used to categorize items such as requirements or tasks into one of the four following levels of how they relate to a deadline (see Table 25.3):

  • must have
  • should have
  • could have
  • won’t have for now.
Priority with respect to the timebox* Description

Must have

Must be satisfied because without it, either the output from the timebox will not work or it is not worth delivering the output

Should have

Should be satisfied because it is highly desirable or very important, but it is not a must have

Could have

Could be satisfied because it is still desirable or important, but not as much as a should have

Won’t have for now

Won’t be satisfied before the deadline

*Where the timebox could relate to a project, a stage, a release or a low-level timebox (e.g. a sprint).

Table 25.3 MoSCoW priorities

25.5.3 What happens if they are all ‘musts’?

It is a very natural and common concern that, when prioritizing using MoSCoW, everything will turn out to be a ‘must’. Typically, this is rarely true.

Tip

MoSCoW always relates to a deadline.

25.5.4 Is the requirement essential?

One technique for checking if a requirement really is a ‘must’ is to ask the question: ‘Would you put the product into operational use without this?’ In other words, is the output from the project still viable in accordance with the rationale and justification for the project, without satisfying this requirement? For example:

  • Would you sell a car without wheels or an engine?
  • Would you sell a car without satellite navigation?
  • Would you sell a car without electric windows?

Although the example is a simplistic analogy, it highlights that some features of a car are essential and others are not. Also, those features that are not essential may have satisfactory alternatives such as a manual winder for the windows.

Further to this, the analogy also highlights the need to understand the overall objective for the project (as defined in the project product description), as the MoSCoW priorities would be different if the objective was to produce a luxury car as opposed to a budget car.

25.5.5 Can the requirement be decomposed?

Another technique which can be used to reduce the amount of effort needed for the ‘musts’ is to break the requirement down into more detail. It is normal for a high-level requirement that has been prioritized as a ‘must’ to be broken down into sub-requirements that comprise several musts, shoulds and coulds, thereby creating contingency in the form of shoulds and coulds.

Take, for example, the search function of a customer relationship management system that must be able to search for customer details. The sub-requirements or musts, shoulds and coulds of such a function include:

  • must be able to search by customer name
  • could be able to search on parts of the customer name
  • must be able to search by customer account number
  • should be able to search by address
  • could be able to search by date of birth.

Tip

If you ever need a quick demonstration of prioritization with MoSCoW, a simple ballpoint pen can be a useful prop (see Figure 25.2). It can also be used to illustrate decomposition and how a ‘must’ can exist within a ‘could’.

Figure 25.2 ‘MoSCoWing’ a pen

Figure 25.2 ‘MoSCoWing’ a pen

25.5.6 Ordering

There are situations when the best way to prioritize is to use a simple list where the most important item is at the top and the least important is at the bottom. This could be achieved using a basic scoring system from 1 to 5 for each item in the list, and then ordering all the 5s relative to one another and then so on with the 4s and 3s etc. This approach to prioritization is most appropriate when there is little dependency among the items on the list (i.e. they are broadly independent of one another) and the items on the list do not naturally group together so that they can be worked on at the same time.

Kanban and Scrum tend to use ordering rather than MoSCoW. However, this approach may not work as well as MoSCoW if a list of requirements has natural groupings and/or dependencies, as the following example shows.

25.5.6.1 Example

You are building a luxury house that must be finished by a certain date. You cannot lower the level of quality and you cannot use additional resources to get it finished on time.

The best prioritization approach to use in this situation is MoSCoW, as you would plan a series of high-level deliverables based around activities that can be grouped together and dependencies that need to be met. For example:

  • Clear the site, lay the foundations and install services (e.g. electricity and water).
  • Build the main house (so that you can live somewhere).
  • Build the garage.
  • Create the garden (after most of the construction vehicles have left).

You may feel that the most important part of the whole project is the roof on the main house, but you would not start with this. You may also feel that the garden is more important to you than the garage, but you would deliver this after the garage because the process of building the garage may ruin the garden. When using MoSCoW, you do not necessarily deliver all of the ‘musts’ first. In fact, this will rarely happen when there are many features that are dependent on each other.

If your plan for the garden involves creating several features, such as a pond, a patio, planting trees, creating flowerbeds, building a greenhouse, creating a sandpit and installing a bird table – then this part of the project may lend itself more to ordering than MoSCoW because the features are reasonably independent of each other and do not naturally group together. You would then complete as many of these as you could before the deadline.

25.5.7 What can be prioritized?

When using agile, prioritization is used constantly and in many forms. The most obvious area where prioritization happens is with respect to the requirements of the project, and this covers those that are both functional and non-functional. Using a camera as an example, its functional and non-functional requirements could include that:

  • It must take a photograph (functional).
  • Its shutter must work in cold temperatures (non-functional).

Many other areas could be prioritized, such as the tasks that need to be completed to satisfy a requirement. One especially useful area that could be prioritized is the quality criteria relating to a particular requirement or product description. Following on from the example above, the shutter:

  • must work at –5°C
  • should work at –20°C
  • could work at –35°C.

Quality review activities could also be prioritized in order to target testing and checking more effectively, as it is rare that there is enough time to check everything.

It is important that the correct prioritization approach is used in the appropriate circumstance. This is affected by the level of the requirements and their dependency on one another.

25.5.8 Handling change with prioritization

Change is inevitable on any project and PRINCE2 Agile refers to two types of change: detail and baseline (see also Chapter 14, Change theme).

25.5.8.1 Detail change

If the customer changes their mind on a requirement or comes up with a new requirement but this does not affect the project product description, then this would be seen as creating a more accurate final product and therefore would be seen as something positive.

25.5.8.2 Baseline change

If on the other hand a change to a requirement, or a new requirement, means that there needs to be a change to a product description, then this would be seen as a change to the baseline of the project. The rationale and justification for the project would therefore need to be revisited.

A problem often cited on projects is that of ‘scope creep’. PRINCE2 does not see refining the detailed requirements as they evolve as scope creep, whereas if there are changes to the higher-level requirements then this needs the appropriate level of governance. The tolerances used to define requirements can help with this along with defining the quality criteria more as a spectrum, rather than a binary condition.

25.5.9 Dynamic change with prioritization

PRINCE2 Agile is structured around flexing what is delivered as outlined in Chapter 6. As a result, change can be handled very dynamically, if the change is of the detailed type outlined previously. When change of this type occurs there are two questions that need to be answered with respect to prioritization:

  • What is the priority of the new requirement?
  • Which requirement, or requirements, will be de-scoped to make way for the new requirement? This is sometimes referred to as ‘trading’, or ‘swapping’, requirements.

Although answering these questions may involve discussions with various stakeholders including representatives of the supplier side, ultimately it needs to be driven from the customer side.

Hints that may prove useful:

  • See the list of requirements as dynamic – embrace change at the detailed level.
  • Remember ‘Archimedes’ law of displacement’ – it also applies to new requirements or tasks: if new ones are coming in then some of the existing ones need to make way. This will be carried out by removing requirements or tasks that are of a similar level of effort.
  • One of the first reactions to a delay, or an issue, of a project manager using agile in a PRINCE2 environment should be to think ‘I need the customer to de-scope something or at least flex the quality criteria on something.’
  • Are the tolerance levels flexible enough to allow for a reasonable amount of de-scoping or flexing of the quality criteria, or are they too narrow and causing off-specs and requests for change?
Image 25.1 List your priorities

Image 25.1 List your priorities

25.5.10 The reason for prioritization

Prioritizing requirements or user stories is a regular and fundamental activity when using agile, but the reasons for this are sometimes overlooked. If you are prioritizing and in effect ‘maximizing the amount of work you are not doing’, then you will be able to hit deadlines, protect the quality of the products being delivered and respond to changes in order to provide a more accurate final product.

Previous Section   Next Section

Collapse