Initial situation – requirements funnel in agile run & change settings
The possible approaches to requirements prioritization that we suggest in this article are based on the typical process a requirement undergoes – from the idea to the release of a feature. We call this process the requirements funnel.
Due to the current relevance of prioritizing requirements for the development of IT in agile or hybrid (combination of traditional and agile methods) project approaches, we focus on agile approaches and use the respective terminology. We have assumed that our readers are familiar with the basic terms.
A requirement passes three filters within the requirements funnel:
- In the first step the quality filter ensures that all requirements are identified in the feature backlog using clear guidelines for scope and content while taking into account topic-related and functional dependencies.
- In the second step, the product owner (as an individual or as a committee) decides on the implementation importance of the features (prioritization filter) and transfers them to the implementation backlog for further processing.
- Finally, there is a capacity filter to weigh the implementation importance against the available development resources. Requirements to be implemented in the next sprint cycle are transferred to the sprint backlog through this filter.
This article focuses on the prioritization filter.
BankingHub-Newsletter
Analyses, articles and interviews about trends & innovation in banking delivered right to your inbox every 2-3 weeks
Prioritization approaches for the implementation backlog
In general, the applicability of the approaches presented depends on existing organizational structures and the prevailing corporate culture.
A defined roles and responsibilities matrix as well as an agreed list of criteria as a basis (e.g. acceptance criteria, brief description, dependencies, etc.) support the transparency and acceptance of prioritization decisions.
In all approaches, an independent, unbiased product owner (hereafter PO) role (as an individual or as a committee) determines the prioritization of the implementation backlog. Thus, there is a clear assignment of roles and decision-making power for agile approaches.
Based on zeb’s experience, five prioritization approaches can be observed in practice:
Please click on the following sections to expand them.
The first prioritization approach is based on the most popular and common methodology in the market – the selection of implementation features by the PO. In this approach, the PO assigns a priority to the features in the feature backlog, which can be based on preliminary discussions with stakeholders or departments in the implementation backlog.
This methodology offers the advantage that the PO acts as a single point of contact. Thus, the efficiency and speed required for prioritization are easier to achieve. In addition, the PO has a comprehensive overview of all features and is thus in an ideal position to select and prioritize topics in line with the company’s goals.
However, one disadvantage is that the PO must have or develop an understanding of all departments and requirements. In addition, decisions made by the PO are final and, in terms of established role authority, must be accepted by all parties, which increases the risk of intervention by the requesting entities. In addition, decisions made by the PO are final and, in accordance with the established role authority, must be accepted by all parties. This however increases the risk of intervention by the requesting entities. In addition, this method entails the risk of a possible preference for individual features according to the PO’s agenda, which is not in the holistic interest of all requesting entities.
Another prioritization approach is the prioritization committee. The committee is made up of various representatives of the departments requesting the requirements and acts as a unified PO. It discusses matters as a group and votes by consensus on the priority of features for the implementation backlog.
The consensus method is a key advantage of this approach – all requesting entities are given the opportunity to explain their reasoning. Another advantage is that all stakeholders have a uniform level of knowledge about development activities and third parties can be consulted as experts in the committee (e.g. for detailed decisions).
One particular disadvantage of this method is that stronger parties in the prioritization committee can more frequently push their requirements through. In addition, a lot of planning and people are involved in preparing and conducting committee meetings. Furthermore, this approach provides the basis for the possible trend of features with lower priorities and little political attention being repeatedly deferred. Ultimately, this method is relatively technocratic and cumbersome, as all decisions require the involvement of the committee.
In this prioritization approach, consistent shares of the implementation backlog are available to each requesting entity, although the shares may vary between the requesting entities. The requesting entities individually prioritize the features to be implemented. The PO then decides which of the submitted features will be included in the next sprint backlog – based on a rough estimate of the implementation effort and taking into account the shares of the implementation backlog.
The backlog split has a major advantage: requesting entities can always count on the same development resources and thus have a high degree of planning reliability. The development resources are fairly allocated, as the allocation is based on previously agreed ratios that are constant across sprints.
The disadvantage of this approach is that a prioritization in the context of the overall company is no longer possible due to the implicit weighting of the requiring entities. Making changes to the allocated shares of development resources / of the implementation backlog is a big effort. In general, this approach offers less flexibility than alternative approaches. In addition, the fact that features which exceed the allocated resources have to be split over several sprints has a negative impact. Besides, feature requests from third parties (without assigned development shares) are difficult to take into account. In cases of potential idle time, further allocation processes for free development capacities are required.
In this prioritization approach, requesting entities have a supply of prioritization tokens available, which they can assign independently to their respective requirements in the feature backlog. When transferred to the implementation backlog, features are ranked according to the number of assigned prioritization tokens. Based on a rough estimate of the development effort, the responsible PO fills the implementation backlog according to the prioritization in such a way that a high utilization of the development capacities is ensured. The token supply of each requesting entity is determined according to different factors or agreed distribution ratios (e.g. tokens in each sprint, non-implemented tokens from previous sprints, development capacity funding, etc.).
This approach clearly offers the advantage of comprehensible and transparent allocation of prioritization power. At the same time, requesting entities with comparatively low prioritization power can always assign very high priority to a specific request by accumulating their tokens.
Disadvantages include the need for strong governance and extensive tool support to avoid bureaucratic overheads. It is also difficult to consider feature requests from third parties without an assigned token supply. Furthermore, the prioritization is primarily aligned with the individual interests of the requesting entities, which means that the overarching and strategic objectives of the company are only given secondary consideration in the prioritization.
A final possible prioritization approach is the round-robin principle. In this process, the responsibility and management of the implementation backlog changes from sprint to sprint between the requesting entities. Each requesting entity can set an implementation focus in the sprint assigned to them according to their own wishes and priorities. The respective requesting entity then assumes the role of the PO for the next sprint. The PO is free to consider implementation inquiries from other requesting entities.
This prioritization approach offers the advantage of planning reliability. Requesting entities always know when the development resources are available to them. This approach ensures clear responsibilities for each pass through the requirements funnel and reduces potential overheads for the sprint backlog prioritization. In addition, requesting entities have the option of specific releases after each sprint.
However, this approach has the disadvantage that all requesting entities are equal regarding the use of development resources. However, it is difficult to involve stakeholders with sporadic implementation needs. Also worth highlighting is the potentially long waiting time for each requesting entity to implement their own features. Therefore, this approach is primarily suitable for a small number of requesting entities (maximum of four).
Interacting with development in agile run
The process models presented focus on requirements prioritization while taking development resources into account.
The key result of all five prioritization approaches presented here is an implementation backlog with a feature prioritization that is supported by all requesting entities.
In addition to these features, issues raised in testing and system errors from live operations are incorporated into the implementation backlog.
Based on experience from past sprints, capacity planning performed for the upcoming sprint and the definition of done (DoD), the implementation team finally selects the prioritized features to be implemented and current system errors to be fixed for the sprint.
In addition, it may be useful to reserve some development capacity for high-priority ad hoc issues.
Selecting the appropriate prioritization approach
The selection of the appropriate prioritization approach depends on several factors:
Another factor to consider when defining the prioritization approach is funding for development resources. For instance, the shares in the backlog split or the token distribution ratio can be based on the funding shares.
If the development is centrally financed, the traditional product owner or a prioritization committee are suitable. Other financing models are also possible (e.g. individual pricing of single features) and must be developed on an institution-specific basis.
A dedicated analysis of the current situation, taking into account, among other things, the skills and willingness of the workforce, must be considered when a prioritization approach is to be introduced or further developed.
zeb can provide support based on long-standing experience from previous projects: from the analysis of the current organizational structure and culture with regard to the suitability of the different prioritization approaches to the individual development and configuration of respective approaches and the introduction of the prioritization process and accompanying governance.
Which agile approach are you currently using or would you like to use in your environment?
Which agile approach are you currently using or would you like to use in your environment?
