PRINCE2 Agile 2016
Previous Section   Next Section

9.4 Agile concepts and techniques

9.4.1 Defining value

Agile usually refers to ‘value’ whereas PRINCE2 usually refers to ‘benefits’. Although not precisely the same thing the terms are often interchangeable (see section 9.4.2). Agile and value

The very first principle of the Agile Manifesto refers to delivering value, but there is very little guidance in most agile sources on how to determine and define ‘value’. The reason for this is because it is usually difficult to define and often involves subjectivity.

Another reason why this situation exists is because the most common agile frameworks are focused at the delivery level under the assumption that the work in general has already been justified. In some agile environments, this assessment of value takes place at the lowest levels of detail, which is probably the hardest place to do this. Calculating value

Working out the value of carrying out a piece of work is easier at higher levels where some degree of aggregation has occurred. Forecasting the savings a particular project could make will normally be far easier than forecasting the savings that one particular requirement might achieve. This is why assigning relative values to a long list of detailed requirements or user stories will normally be quite subjective. A customer may find it easy to say that one user story is more important than another user story, but they may find it difficult to quantify what the value of each story actually is.

This may not always be the case, as there may be situations where the value measure being used can be derived quickly from historical data and can easily be validated by customer feedback. An example of this would be the desire to increase traffic to a website. In this scenario other websites could be analysed to see how beneficial certain features proved to be; then after implementing the feature, hard data would be available to measure the impact.

But even in the previous example measuring value may not be as straightforward as it looks. Should the customer be measuring the increase of visitors to a website or should they be measuring the increase in time spent on the website? Perhaps they should not be measuring either and they should be focusing on how much revenue the website is generating.

Measures drive behaviours; therefore it is important to use the correct measure of value. Measuring value

Measuring value can be quite difficult due to the fact there are so many things that may give value, such as increasing revenue, reducing costs, retaining customers, reducing risks, meeting regulatory targets, customer satisfaction, brand improvement and so on.

It is important to understand what kind of value is needed and to quantify it at the project level (i.e. in the business case). This will then help when assigning relative values at the delivery team level, because these people are working with the detail.

One thing that is more important than building the product right is to build the right product.

9.4.2 Defining benefits and value – an example

The following call centre scenario is intended to provide a guide to how benefits and value could be assessed at the beginning of a project and during it. The intention is to highlight how difficult this can be but at the same time illustrate its importance – and also demonstrate the way in which a project team working in an agile way can respond and adapt to the circumstances happening around them.

We need to close more customer incidents on the first call! We need a knowledge management (KM) system!

Change in an organization can start from anywhere. There may be a problem to solve or an opportunity to take. Although the idea can come from anywhere it needs to be authorized at the right level and in the right way (e.g. at a strategic level).

Once a project begins to come into existence, it is essential to define the ultimate benefit and value that will be delivered. Asking for a KM system is asking for what PRINCE2 refers to as an output. Assuming that the KM system will result in more calls/incidents being closed on the first call, this is what PRINCE2 refers to as an outcome. However, more important than both of these are the benefit and value that are ultimately delivered. PRINCE2 refers primarily to benefit, whereas agile refers more frequently to value: although they are similar they are not the same and this is explored in the rest of this chapter. Value is sometimes referred to as ‘net benefit’ as it represents the benefits after the expenditure has been factored in.


AXELOS’s Management of Value (MoV) says that value is subjective, with different people applying different criteria to assess whether they are getting good value. It is this subjectivity that makes it so essential to manage value deliberately, instead of leaving it as a by-product of any other management activity. Added value is provided by the delivery of enhanced, but useful, benefits and more effective use of resources. Not all perceived benefits are actually necessary. MoV provides a means of distinguishing between needs and wants. Likewise the supply of resources is often (indeed usually) limited. Effective expenditure is essential to make the most of what is available.

MoV recognizes that not all benefits are financial and that the differing priorities of key stakeholders need to be considered and reconciled. Expenditure must cover short- and long-term needs and recognize that resources are finite and must be conserved. Balancing and reconciling these conflicting demands, to maximize value, is one of the core principles of MoV. Points to consider when starting a project

To correctly initiate a project, it is important to understand why it is taking place and what the best course of action is:

  • Why is it assumed that a KM system will close more calls on the first call?
  • What is the significance of closing an incident on the first call? Why is that different from closing an incident in two calls?

Spending time to work out exactly what the problem (or opportunity) is and how to solve it is essential to getting a project off to a good start.

The reason for wanting a KM system could be that:

  • If more information from around the company is made available, the information would be available to help close more calls on the first call.

The reason for wanting to close calls on the first call could be that:

  • Existing measurements and metrics within the organization show that to re-visit an incident takes 25 per cent more time in total because subsequent calls need to cover the same information again (e.g. customer details and security). This in turn is leading to the need to hire many temporary workers over and above the existing company headcount, and temporary personnel are relatively expensive. Clarifying the output, outcome and benefit (or value)

Investigating the thinking behind the desire for a KM system can drive out the real reasoning behind it. Continually asking ‘why?’ can help to determine the answer, and may result in a well-defined statement such as:

We want a KM system (output) so that we can close 80 per cent of all incident calls on the first call (outcome) in order to reduce the workload in the call centre by 10 per cent so that we will not need to hire as many temporary workers, and this will save us £200 000 per year (benefit).

Importantly, the outcome and benefits are now measurable. However, it is important to measure the current situation as well so that progress can be monitored (e.g. the percentage of calls closed on the first call is currently standing at 63 per cent). What if things change?

Assuming that the project has gone ahead, working in an agile way would focus on getting feedback as early as possible by the early delivery of features that should be of benefit and value.

If the new KM system was a 12-month project it may be appropriate to deliver certain important and useful features in the early months that are intended to help close calls on the first call. This then gives a chance to measure how effective they are.

After 6 months, if the percentage of closed calls on the first call has improved to 70 per cent (from 63 per cent) then this would probably be seen as a good sign. However, this is still an outcome. Has the expected benefit been achieved in saving the expense of the temporary workers? It may be the case that there is no reduction in the temporary personnel. A project that is benefit- or value-focused will react to this, whereas a project that is output-focused will continue to build the KM system (as this is what it has been asked to do).

As a surprise, what if the customer satisfaction ratings for the call centre have gone up recently by 4 per cent due to the increase in calls closed on the first call? Perhaps the happier customers (due to calls being closed on the first call) are resulting in more calls to the sales teams, which in turn is resulting in more calls to the call centre! Which is why the number of temporary workers has not reduced.

Seeing that the KM system may be delivering benefit and value, but not quite in the way it was anticipated, can allow the project management team and the delivery teams to adjust how they work and what they work on.

It may be that certain premium customers are so impressed with the improved incident resolution time that they are buying other products and they do so in large volumes. Therefore, if the call centre focused more on closing premium customers’ calls on the first call, this would deliver more benefits and value than with the original outcome, yet still deliver a KM system (the output).

Revising the earlier request may therefore be:

We want a KM system (output) so that we can close 90 per cent of all incident calls from premium customers on the first call (outcome) in order to increase their customer satisfaction ratings by 3 per cent so that we get an increase in sales of new products of £300 000 per year (benefit). The need to focus on benefits and value

To deliver as much benefit and value as possible it is important to be able to measure and track them. It is also important to be able to adjust the work taking place to maximize this. As feedback is received it will affect the priority of the requirements. This may generate new requirements that are essential (e.g. we need to know if a call is from a premium customer). This is why the business case needs to be flexible so that the benefits can be achieved by adjusting the originally defined outcomes and outputs, and therefore the setting of the appropriate tolerances (e.g. for scope, quality criteria and benefits) becomes important. How collaboration helps

If the feedback being received by the early delivery of features is not quite what was expected, it is desirable if this is handled collaboratively by everyone on the project from the project board to the delivery teams – by the customer and the supplier. Agile teams respond to change. To react well to changes in circumstances means that anyone representing the customer needs to seize the opportunity to adjust the course of the project by working out what is happening and why, and then reprioritize accordingly. Equally, anyone from the supplier side needs to make clear what is possible (e.g. ‘Have you thought of this?’, ‘We could do it that way.’) More benefit and value are likely to be delivered if the team collaboratively focuses on benefits and value in preference to focusing on just the output. This is why the contractual side of the relationship needs to support this as much as possible.

Previous Section   Next Section