This chapter covers the following topics:

INTRODUCTION

All businesses introduce changes. Small changes happen frequently as part of day-to-day business as usual. Major changes are more likely to be the subject of a change project. A change might be made to the way in which a task is conducted or might involve the development of a new product. However, whether small or major, process or product, organisations need to prioritise their changes. This may be an obvious statement, but too often prioritisation gets overlooked, particularly when we are in pursuit of higher-level goals. To be truly agile in business and on projects, we have to prioritise – otherwise we risk delivering late, if at all.

Business analysts need to understand and facilitate prioritisation to ensure that businesses are focusing on achieving the most important goals first. After all, there is always more work to be done than there is time and money for. Prioritisation is key to getting this balance right. This chapter discusses the importance of prioritisation to business analysts and agile change projects, and the different techniques that can be applied. Additionally, the significance of particular prioritisation levels are discussed, together with the issues that can ensue if prioritisation is not carried out effectively.

THE IMPORTANCE OF PRIORITISATION

All businesses recognise the need for prioritisation. What is less obvious is how we go about prioritising, and how understanding prioritisation is more than just identifying that one change is more important than another change. Prioritisation can tell us which changes we need urgently, which ones could be delayed and which we might think about never introducing. Prioritisation can also tell us which changes should not be considered, but can be ‘parked’ for consideration at a later date. Sometimes, prioritisation can indicate which changes are really just vague ideas that we probably don’t need at all.

Given these different categories, prioritisation can tell us where to invest money and when to work on a new initiative. It can also be very helpful in preventing ‘headless chicken’ syndrome, where people rush around trying to do every task that has arrived in their in-tray. If we understand prioritisation we can be really focused, recognising the key goals we need to achieve and the elements that can be paused, delayed or dropped.

Business today often seems like a frantic rush to get too much done in too little time. In the software development world, prioritisation has become second nature. As soon as we start defining requirements or developing the backlog of user stories, we know that entries have to be prioritised. We also know that business customers will request changes or new features that may not actually be required, or not by everyone anyway, or might not even be feasible. So, we use prioritisation techniques to make sense of the battery of ideas, features, goals and enhancements that regularly head in our direction.

However, in the business world prioritisation is less formalised and techniques not as well developed. So, as business analysts, we need to ensure that the importance of prioritisation, and the relevant techniques for prioritising, are used beyond the software development arena. Using an effective prioritisation technique is essential if an organisation is to adopt the agile philosophy and principles and gain any benefit from them. This will enable the organisation to focus the effort where the most benefit will accrue. It will ensure that skills are directed where they are most needed. And, perhaps most importantly, it will deliver the business goals that are really critical to the organisation’s success. The agile business analyst should be able to support and, where necessary, direct, the prioritisation effort, in order to help organisations spend investment funds wisely and deploy other resources effectively.

PRIORITISING REQUIREMENTS

Prioritisation is the responsibility of the business stakeholders. However, whichever technique is used, prioritisation involves a degree of subjective decision-making so the stakeholders usually need some guidance and support when prioritising. Business analysts are typically the most appropriate people to offer this support because they have an understanding of the business domain and, therefore, are well positioned to challenge and question the allocated priority levels. They also understand how to analyse the impact of implementing, or not implementing, different proposals and requirements. For this reason, business analysts should be knowledgeable about the prioritisation techniques that may be applied and the contexts within which they work best. This section looks at the techniques that are used during change projects; they apply to software or product development and can also be used to prioritise business or process changes.

Prioritisation techniques

A standard for prioritising can be as simple as levels 1, 2 or 3, with level 1 being the highest priority and level 3 being the lowest. A prioritisation technique using this approach might define the levels as follows:

Variants of this approach can also be used, for example:

All of these prioritisation approaches are straightforward to understand and can be easy to use as long as the differences between each of the levels can be clarified. They help us to identify where to focus our efforts first and with greatest volume. The Kano approach is another technique that uses a similar basis for categorisation, applying three categories:

Use of the Kano approach causes analysts to ask questions such as:

Other techniques are more analytical and can be complex to implement. For example:

Each of the factors is considered independently, using an agreed scoring mechanism. Typically, several people are involved in applying the following process:

The scores for all jobs are then used to create an ordered list. The low scores represent the smallest jobs that deliver the highest value and should be done first.

 

Figure 9.1 Calculation for WSJF

Prioritisation and timing

While it is essential to know the level of importance of a requirement if we are using an agile approach, there is a problem with many techniques in that they offer a level of priority but this is not linked to time criticality – for example, do we need this feature yesterday, straightaway, can we wait a few months or do we think about it next year. Some techniques also offer categories that are not sufficiently granular and are open to interpretation.

A technique that is popular amongst agile practitioners is the MSCW framework or MoSCoW, as it is typically known. This technique, coupled with the iterative development and incremental delivery of features, is extremely powerful and has much to offer the agile organisation and business analysts.

The agile ethos of on-time, on-budget delivery often means that some of the features originally envisaged for inclusion in a product may have to be left out initially. This is a fundamental principle of the agile philosophy and one that is highly relevant to all types of new initiative, whether involving an IT system, process redesign or product development. It is extremely unusual to be able to incorporate everything that has been requested, as sufficient time and budget are rarely available; to manage this we need to ensure two things:

What an agile approach ensures is that we consider the first ‘release’ to be just that – the first release. We know that there will be refinements and additions coming along afterwards. This is highly liberating, as it means that we don’t have to nail down every last item before providing something to the stakeholders who need it. However, effective prioritisation ensures that what is delivered is sufficient and doesn’t mean a product that is unusable – who would want a car without wheels? No one! However, a car only available in a basic model might suit many people.

The other advantage of an agile approach is that it enables us to develop solutions iteratively. This means that we can develop some elements of the IT system or business product during a focused time period (known as an iteration) and then enhance or extend these via further iterations until we achieve something that we are ready to release to the stakeholder community. An initial version of a system or product might be released as a result of just one iteration; alternatively, several iterations may be needed to develop the first release of the product or system.

MoSCoW

The key to ensuring that the most important features and goals are delivered first is to clearly prioritise them, and the MoSCoW framework provides an excellent basis for doing this.

The MoSCoW approach has become a de facto standard prioritisation system for requirements, especially on projects that are developed and delivered in an iterative and incremental way. MoSCoW helps to clarify different priorities by using the following prioritisation categories:

■ they relate to an overall business strategy but are recognised as being part of a second or later phase for the strategy implementation;

■ they are not needed at this point, for example, they relate to a forthcoming legal or policy change;

■ they are possible enhancements to the product or system that would increase the complexity if implemented at this stage.

Figure 9.2 shows a representation of a list of requirements, work items or features that have been prioritised using the MoSCoW technique.

The MoSCoW rules provide the basis on which decisions are made about which features a product or solution development team will concentrate on at various points:

 

Figure 9.2 Prioritised list of requirements or work items using MoSCoW

The four MoSCoW categories are relevant where several increments are to be delivered and this is the case whether an agile development approach is used or not. However, where a project is using a linear approach, such as a standard ‘waterfall’ life cycle, which will involve one delivery of the solution, MoSCoW is not as appropriate as other techniques. In this situation it is preferable to use a framework with levels of priority that do not imply timing.

While MoSCoW has been used extensively in software development, it is an excellent prioritisation technique for any set of required features or changes. For example, the development of a new insurance product might involve a set of prioritised features that are introduced as follows:

Table 9.1 provides a list of the more popular prioritisation techniques available and provides advantages and disadvantages for each.

 

Table 9.1 Prioritisation techniques

APPLYING PRIORITISATION

A well-formed prioritisation approach such as MoSCoW is invaluable when planning a release, and the development iterations required to achieve this, as it provides a means of both identifying the essential features to include and building in contingency. Using software development as an example, we might identify a batch of requirements or backlog entries that are to be worked upon during an iteration, and these might have the following priorities:

So, how does using a prioritisation technique such as MoSCoW help during the application of agile business analysis to support the project? First, it enables the team to be aware of the immediate needs where non-delivery is not an option. Second, it allows the allocation of features that are essential and will be advantageous to the project if they are delivered during this iteration but, if delays or problems occur, could be deferred. Third, it provides a means of considering the additional, ‘wish list’ features so that they could be included if there is time and effort available. Where these are small additions to higher priority features, including them can require little additional work (although they can succeed in gaining additional appreciation from the stakeholders). Sometimes, the work to include the higher priority items takes less time than anticipated so the ‘could have’ items ensure that there is no wasted effort during the iterations; other times, progress is slower than predicted and these items can be dropped without need to discuss with stakeholders or worry about the impact on the overall product. Provided there is agreement amongst the business and technical members, the team has the authority to reduce the scope and remove ‘should have’ or ‘could have’ requirements from the work of the iteration. This does not apply where a change of priority is proposed with regard to a ‘must have’ requirement; this has to be referred to the business sponsor, and possibly a wider group of business stakeholders.

Figure 9.3 shows a release schedule with the potential priorities included.

 

Figure 9.3 Release schedule showing MoSCoW priorities

When deciding which ‘should have’ or ‘could have’ requirements are to be dropped from the work of an iteration, it is useful to review against the following criteria:

Effective prioritisation helps to ensure that time and effort is not wasted during an iteration and provides a means of embedding contingency. As a result, the agile business analyst needs to be aware of the potential impact and application of prioritisation during iterations and the benefits this can deliver when managing the requirements document or backlog.

PRIORITISATION DECOMPOSITION

Requirements are identified at various levels of detail from a high-level strategic viewpoint through to a more detailed, deployable level. Therefore, it follows that high-level requirements can often be decomposed into lower-level requirements. For example, a general business requirement might state the need to reflect the corporate marketing policy in every aspect of a business change. This might be decomposed into lower level, non-functional requirements that are concerned with usability and navigation, and functional requirements concerning information provision and format.

It is also the case that the overall goal to be achieved by a requirement may be decomposed and there may be different priorities assigned to each decomposed requirement or goal. Goal decomposition is discussed in Chapter 8. An example decomposition with differing priorities is shown in Figure 9.4.

 

Figure 9.4 Decomposed requirements/goals with priority levels

An example might be as follows:

PRIORITISATION ISSUES

Prioritisation is not a straightforward process. It requires a great deal of thought and needs to be firmly embedded within the business context, with a focus on understanding what the business needs are and where the most business value might be derived. As a result, there are some issues that are regularly encountered during the prioritisation process.

Everything is a must

The major problem encountered with prioritisation is that while we know what to do once the requirements have been allocated a level of priority, the process to do this can be difficult and require a great deal of thought. The customer has to have an understanding of the prioritisation approach and the relevance of each of the priority levels. The business analyst is well placed to support and facilitate the prioritisation process, helping the customer to understand the value or impact of a requirement and the dependencies between them, and therefore helping to decide on the relative priority of each.

The starting point is to consider the business value that will accrue from the delivery of a requirement or achievement of a defined goal and, correspondingly, the degree of importance it would be allocated by the customer. However, this often results in the majority of requirements being in the ‘high’, ‘mandatory’ or ‘must have’ category; this is typically the initial position taken by the business managers and staff when they are asked for the level of prioritisation to be allocated to requirements. Unfortunately, it is extremely unlikely that there is sufficient budget or time to meet all of the requirements in one fell swoop; this is rarely achievable. However, it is also the case that if this were true, the flexibility derived from a prioritisation technique such as MoSCoW is completely lost. Without lower priority requirements, there is no opportunity to focus on early delivery of a more limited solution that includes only the key requirements. Equally, the possibility of reducing the scope of the solution, possibly in order to bring the project back onto time and budget, is removed.

Therefore, it is important to prioritise requirements and understand which ones fall within the minimum set for the initial product delivered, and which can be deferred or left out altogether. Given that human nature tends to favour the highest level of priority, the following steps can be useful in sorting the absolutely vital requirements from those of lesser importance:

■ level 1, followed by level 2, followed by level 3, and so on;

■ ‘must haves’, followed by ‘should haves’, followed by ‘could haves’, followed by ‘want to have but not yet’ requirements.

However, a more rigorous approach is to set the priority for each requirement as ‘nice to have’ or ‘want to have but won’t have this time’ and then require a good justification to move the requirement into a higher level of priority.

These step-by-step approaches are very helpful when conducting agile business analysis. They enable us to focus the discussion by asking questions that consider prioritisation from a different angle. Rather than asking, ‘What level of priority or importance should be allocated?’, we begin by asking ‘Which of these requirements can be deferred for a while?’; or ‘Which of these requirements might be left out altogether?’; or even, ‘Which of these items is more important than the others?’ and then progress through the lower priority levels towards the essential features. Suggested questions to ask during the prioritisation process are shown in Figure 9.5 below.

 

Figure 9.5 Questions used during prioritisation

Too early or too late prioritisation

Prioritisation is often conducted at an unnecessarily late stage. Sometimes, we wait until we have fully understood the business requirements, and obtained significant detail on them, but in this situation we may have wasted time investigating and defining requirements that will later be removed or deferred. To combat this, it is beneficial to prioritise early and concentrate on the aspects of highest importance first. If a high-level business requirement is not of top priority, there is little to be gained from investigating the detail at an early stage; this can be deferred until the specific area is being considered for delivery.

Therefore, it is a more effective use of time, and is more in line with the agile philosophy, to prioritise the high-level business requirements or business use cases at an early stage, and then use these priorities as a basis for identifying where the early work needs to be done. This will help to identify the key business goals that need to be tackled first and the less urgent goals that can wait until a later stage. All of this is the pre-project work that is essential to defining a solution backlog and yet is often omitted from agile methods.

Working in this way will help the agile business analyst to adopt a levelled approach to the initial analysis and help the project team focus on where early value can be obtained. Prioritising at a business level and decomposing only those items of high priority, ensures that time is not wasted detailing requirements that are not to be a high priority, which would delay the delivery of the working solution. After all, it is the delivery of the working solution that is the measure of success and builds trust with the customer.

There is often an assumption made that all of the requirements identified initially should be defined to the same level of detail, but this is the antithesis of the agile philosophy. It is more efficient, and focuses effort on the more important areas, if the following approach is adopted:

This approach would result in higher priority requirements being defined in greater detail than others, and this focuses the effort where it is likely to derive the greatest benefit for the organisation. An additional benefit to this is that trust in the relationship with stakeholders is developed as they see that the work is progressing and that they are likely to receive some of their requirements early through the delivery of the working solution. This principle applies whether we are working on business improvement, product development or software development projects.

New requirements often emerge as existing requirements are defined in more detail and as the project progresses. These requirements need to be prioritised, typically using the MoSCoW framework, as they arise in order to establish when they need to be considered in detail.

Changes to priorities

As solutions develop, it is inevitable that there will be changes to requirements and goals. This is to be expected on an agile project and, as a result, it is also expected that the work will be prioritised and re-prioritised on an ongoing basis as the project progresses. This is highly productive and helps to ensure that:

Re-prioritisation should be limited to the period between iterations rather than occurring during an iteration, and if possible should be concerned with planning for the next release or increment. If we are using MoSCoW, once the initial set of ‘must have’ requirements (plus possibly some ‘should have’ and ‘could have’ requirements) has been delivered, the planning for the next increment should begin with a re-prioritisation of the requirements catalogue or backlog. At this point, it is likely that any ‘should have’ requirements will be allocated a ‘must have’ priority level. However, it is also important to review the requirements in the other priority categories:

All in all, it is possible for the priorities to change significantly as a result of re-prioritisation, bringing new requirements to the fore in order that they may be included in the next release of the product or system.

CONCLUSION

Prioritisation is a fundamental activity for scheduling the work of agile projects. It is also an important area for business analysts, as it enables clarity of understanding about where to focus immediate efforts and provides an excellent basis to support the customers in achieving their business goals. Without prioritisation, there may be a temptation to do too much at once and make hasty decisions. Resources may be spread too thinly and not used effectively. Ultimately, this can lead to a diminished clarity of purpose that may result in a failure to deliver anything of value.

Business analysts who have adopted the agile philosophy and mindset recognise the importance of facilitating the focused, early prioritisation of requirements and goals, and understanding the need for decomposition and prioritisation at different levels of definition. This enables them to work on delivering the features that achieve the most important goals as soon as possible. Using this approach, agile business analysis can ensure that there is improved support for organisations through the early delivery of solutions, which will help customers realise the business benefits as quickly as possible.

FURTHER READING

Agile Business Consortium (2016) The DSDM Agile Project Framework (2014 onwards). Agile Business Consortium. Available from: www.dsdm.org/resources/dsdm-handbooks/the-dsdm-Agile-project-framework-2014-onwards [20 December 2016].

Paul, D., Cadle, J. and Yeates, D. (2014) Business analysis: 3rd edition. Swindon: BCS.

Pohl, K. and Rupp, C. (2011) Requirements engineering fundamentals. San Rafael, CA: Rocky Nook.

Saaty, T. (1994) The analytic hierarchy process. Interfaces, 24 (6): 19–43.

Scaled Agile Inc. (2010–2016) WSJF (Weighted Shortest Job First) Abstract. Available from: http://scaledAgileframework.com/wsjf/ [20 December 2016].

Scaled Agile Inc. (2014–2016) SAFe 4.0 for Lean Software and System Engineering. Available from: www.scaledAgileframework.com/ [20 December 2016].