5.2 Prioritisation, Commitment and Backlog

In the current highly competitive marketplace, business service and solution development is a major factor in the competition. Most organisations continually receive development requests to update and improve the business technology estate or to implement new capabilities and technologies that are key to supporting the company vision and strategies for success.

Regarding this, a common challenge faced by business technology functions is to find the right way to orchestrate and prioritise the continuous flow of requests with a minimal viable governance. The objective is to speed up the time-to-market without losing sight of the requests that are lower down the priority order.

Development request evaluation

The prioritisation and commitment processenables development flow decision making for development initiatives. At the same time the portfolio steering process and necessary stakeholders focus on initiatives that cannot be decided in the development flow.

Figure 5.2.1 Prioritisation and commitment process

As explained in chapter  2.6., Development Portfolio, the demand and development portfolio management provides a set of rules and guidelines to help in identifying if the request is a fit for development flow decision or must go through a deeper level of examination and approval.

The following evaluation criteria determine whether DEV flow approval can be used:

1. Sponsor: Is the request sponsored by a business or a value stream owner?
2. Financing: Does the owner have a financing/budget for the development?
3. Resources: Does the owner have a dedicated development team available to deliver the request?
4. Architecture: Is the request compliant with enterprise architecture guidelines?
5. Security: Is the request compliant with security policies and guidelines?
6. Vendors: Are you working with approved partners/vendors?
7. Processes: Is the project following the standard development processes in place?

If the answer to all of these seven criteria is affirmative, the requests can be approved with the development flow decision and the development team will add the request to its backlog and take care of further development of the request.

Evaluation may also include further hierarchy steps. For example, if the first evaluation round does not provide positive answer it can be escalated upwards in the hierarchy until it bypasses or reaches the portfolio level. Typically, the lowest level self-evaluation is done by a service manager or a product owner and can be further escalated to a service owner or a value stream owner before going to the portfolio level.

Portfolio-level management of development requests

When a request does not pass the evaluation criteria and cannot be approved by the development flow, portfolio steering is required to:

• Evaluate the request feasibility and risks
• Define a priority for the request
• Arbitrate request’s priority against others
• Help in getting funding and required resources.

Once the portfolio steering group agrees and is confident with all aspects of the request, it is ready to proceed to development phase where a development request will be produced using either sequential or incremental development procedures:

• Sequential development expects a traditional project plan including a set of requirements, description of the different phases, roles and responsibilities
• Incremental development expects a set of epics, features and stories to be added to a backlog.

Development request prioritisation

Before committing to the development, each development request must be prioritised according to different considerations and development method.

Sequential development prioritisation

For sequential development, shared resources are allocated to the development for a planned period. Prioritisation of sequential development is a complex exercise that requires carefully balancing the following three considerations:

• Business value and impact: Considering the business impact of the project on the strategic objectives, opportunities of new revenue generation, market competitive advantage, etc. A common method for calculating business value is Net Present Value (NPV) which is based on future cashflows (in and out) and the associated risk
• Cost of delay: A way of sharing and understanding the impact of time against forecasted outcomes. It provides the means to calculate and compare the cost of not completing a request by choosing to postpone it. A common method for maximising the value delivered in a defined period with limited capacity is the Cost of Delay Divided by Duration (CD3 score)
• Risks reduction and compliance to regulations: Considering risk for the organisation to not proceed with the development. This consideration is impacted by the end-of-lifecycle status of the current solutions or other deadlines in support, compliance or technical environment. A common method for risk analysis is a 5×5 risk matrix having probability and impact as the two dimensions with scale from rare and very low to highly probable and very high impact.

The above considerations are driven by the Development Management Office and provided by the project owner. The portfolio steering provides its own judgement to ensure that all initiatives are prioritised equally.

Incremental development prioritisation

In incremental development, a team dedicated to a specific business purpose manages a backlog of requests. The team needs to manage the new requests coming in and prioritise its backlog while continuously delivering new service releases.

During a specific workshop (e.g. PI planning session in SAFe) the team, including the stakeholders, works to break down each request into large increments and spends time breaking down each increment into smaller pieces of development (features, stories) that will be realised incrementally. Still working with the stakeholders, the team then evaluates the different pieces of development and prioritises them based on:

• Feasibility including technical consideration to estimate duration of each feature based on a discussion between the technical team members and the technical partners
• Desirability consisting of analysis of the end user needs and priority based on a discussion between products owners, UX designers and strategists
• Viability formed by analysis of the different constraints that apply to the project itself such as finances, time, regulations and dependencies

The result of this work is a prioritised backlog of tasks for each request. Requests are then compared between each other to select the most viable one to develop first. The criteria for selection is often based on the Cost of Delay Divided by Duration (CD3) of each request or Weighted Shortest Job First (WJSF in SAFe).

Changes

Some requests received by service teams refer to minor changes on some existent capabilities, products or services and thus represent only a few hours’ or days’ worth of effort. These changes are usually decided by the development flow and follow a specific steering governance and prioritisation decisions by the Change Advisory Board (CAB).

A service change management process is used to manage the implementation and release of the changes. It employs standard methods and procedures to make an assessment between the need for change versus the impact of change. The objective is to prevent all unintended consequences to service quality.

The changes are usually classified as normal, standard or urgent.

• Normal infrequent changes to a service or infrastructure requiring a risk assessment by the Change Advisory Board (CAB)
• Standard changes are routine tasks pre-authorised by the service management function that uses approved and established procedure to provide a specific change requirement
• Emergency changes must be introduced as soon as possible, usually in order to correct an error within a defined environment. There is a substantial risk involved and therefore, it must be approved by the Emergency Change Advisory Board (ECAB).