The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to firstname.lastname@example.org from the e-mail address which you have registered with.
Prioritization of requirements is an essential activity. Most important requirements shall be developed first, optimizing the return on investment. The weak point is how to decide about “most important”. This article proposes a collaborative prioritization approach for epics and themes based on agile methods and techniques that are already well established in agile environments. This prioritization technique is a natural fit and completion in agile environments used on road mapping and release planning level.
Prioritization of requirements is an essential activity in all types of development.
The objectives of requirements prioritization are to
The weak point in these two statements is “most important”. Many criteria influence what “most important” is. These criteria depend on project context and might change over time. Even the set of criteria may change over time, depending on the context.
This is a well-known and deeply discussed topic in requirements engineering; see  ,  and . Different approaches and proposals exist that specify “most important” and offer techniques on how to handle “most important” such that they are quantified and measurable.
For example,  proposes a set of twelve criteria that influence the priority of requirements engineering. An algorithm is given that allows calculating a normalized priority for requirements based on these criteria. This approach is elaborated and quantified. The drawback of this approach is the effort required to agree on and set all values of the twelve criteria. Yet whenever re-prioritization is required the step to agree about the values has to be re-executed as well. Applying this algorithm in an agile project with an iteration length between two and four weeks might be challenging for two main reasons:
The need to regularly re-calculate the priority of requirements is clearly stated as important. Changing prioritization of requirements is discussed in  pointing out that “Priorities will change as you talk with your customer and gain a better understanding of your customer’s needs, … as the system matures as its architecture develops, and as uncertainty is resolved; therefore, the priorities of all features should change with time ”. So a regular re-prioritization is a must to steer the future course of development. Formal techniques based on criteria set are applicable when re-prioritization is done to well defined milestones, i.e. typically in waterfall-like life-cycle models. In iterative and agile life cycle models formal techniques are a challenge for the reasons mentioned above: the effort in execution and acceptance by the team.
So, do agile teams excel with prioritization? In agile environments the product owner takes this responsibility. Agile prioritization of backlog items typically uses a very restricted set of value and cost based criteria : Customer perceived business value, risk, size and complexity. There is no explicit algorithm applied, instead the priority is discussed during backlog refinement activities by the product owner, customers and users. Strategies in agile prioritization follow the “quick win” (high value) and “low hanging fruit” (low effort) principle  on a “common sense” basis. The results are manifested in the order in which requirements are arranged in the backlog. This agile approach is said to be successful. Yet in an exploratory case study with eight organizations, the authors come to a different conclusion : “…three explicit and fundamental assumptions of agile requirement prioritization approaches, as described in the agile literature on best practices, do not hold in all agile project contexts in our study. Those are: (i) the driving role of the client in the value creation process, (ii) the predominant position of business value as a main prioritization criterion, and (iii) the role of the prioritization process for project goal achievement”. Based on this case study it can be said that agile principles of prioritization are relevant but unluckily the application of these principles in reality is lacking.
State of the art prioritization is obviously a challenge in agile environments. The precise summary of previous work and research is that:
To address these challenges, the requirements for a successful agile prioritization technique must be understood. Derived from previous work and research, this article specifies a base set of fundamental requirements for a successful agile prioritization technique:
This article proposes a more elaborated prioritization approach than the common-sense based discussion on priorities between product owner and stakeholders. This prioritization approach uses elements of methods that are already established and applied in agile environments. It also combines elements from agile and lean plus elements coming from areas of innovation, creativity and lean start-up. Agile teams accept the new elements, if these naturally fit into the already applied backlog refinement techniques in elicitation, developing and prioritizing of requirements towards an INVEST user story.
The creators of this prioritization approach named this combination of agile elements Innovation Arena. The approach is the result of practical experience over many years in agile projects within different contextual scenarios and domains, and in projects of different size and type. The approach itself is in no ways a formal and fixed method or technique that is ready for use “out-of-the-box”. Instead the elements of the approach need to be adopted and optimized within the target context and organization; or even substituted by elements of the target organization with a better fit but of equal semantic value. Essential is the base concept of the combination of the Innovation Arena elements.
The core values of Innovation Arena are:
Except the first, all core values of Innovation Arena are explicit agile core values. The first core value of Innovation Arena still aligns albeit implicitly to good agile practices following the concepts of requirements development from themes over epics down to user stories and tasks.
Requirements develop over time. Starting from a vague idea of a stakeholder, a requirement develops to a set of more concrete features to user stories and tasks that finally end up in a piece of – based on acceptance criteria – tested software. Abstraction levels used for requirements in agile projects are typically: Themes, epics, user stories and tasks. These abstraction levels use size and complexity as differentiation criteria. A user story is smaller and less complex than an epic; an epic being smaller and less complex than a theme.
What these abstraction levels do not respect is the maturity of a requirement; the intention and how well understood and agreed the requirement is by all – stakeholders and team. The only point in time where a maturity definition is explicitly addressed and recommended in the agile community is the “definition of ready” for user stories.
We recommend a more finely grained “definition of ready” in agile environments as defined in . This maturity model for requirements defines the maturity levels star, cloud, tree and road as following:
|Star||The requirement is a first sparkling glitter. There is no chance to say if the requirement could be developed into something concrete; or we do not have any feedback if anybody has interest in that requirement.|
|Cloud||We see contures and shapes. We are able to at least communicate a vision for that requirement; the most important features of that requirement; who the personas are that might have interest in that requirement; a first assumption about the feasablity of this requirement.|
|Tree||The requirement is fairly concrete. We clearly see business value for stakeholders and users when implementing this requirement. There are still issues and risks before we are able to mark the minimal viable set of users stories with “ready for development”. We can say we see already the apples hanging in the tree, but still they do not fall off.|
|Road||The requirement is on the road. We are able to invest and we will invest to develop the required user stories that will realise the requirement.|
These maturity levels are negotiated with team and stakeholders at the beginning of a project. Each team specifies its very own agreed definition of these maturity levels. The maturity level of “road” typically is identical to the “definition of ready” of user stories. The “tree” level is assigned to epics at a point in time when we can identify the most important user stories of this epic required to develop the least viable implementation of the requirement. The “cloud” level is assigned to epics or themes when accepted as important, the business value (rational) is visible and feasibility is clarified to the extent of an acceptable risk – whatever acceptable might be in the concrete context.
At this point a definition of terms in the context of this article is needed for stakeholder, user, customer and team. In the context of this article we use the terms as following:
Without proven evidence, yet based on the experience from a set of projects within different domains and teams, these iconic maturity definitions are agreed upon and applied very fast. None of the observed teams explicitly documented a definition of the maturity levels in written form. After introducing the maturity levels very briefly and explaining the idea behind them, all the teams agreed upon the definition what star, cloud, tree and road levels represent, which makes direct communication easier when they start to use them in their daily work. Each team had a slightly different definition of what a single level really represents in their concrete context, but the levels then are used consistently throughout the course of the project.
It is important that each theme, epic or user story is assigned an agreed maturity level. To be more precise: only in the case that stakeholders agree (expressing that they see value in the development and the risk of development below the agreed quorum) and the agile team agrees (expressing that the requirement is understood as required and feasibility is assured) about a level, is the level assigned to a requirement. If there is no agreement between stakeholders and agile team or in the team at all, there is need for additional development work on that requirement. This follows the same rules as story point assignment to backlog items in agile estimation. If there is a substantial divergence in story points in the estimation of a backlog item, an additional conversation is required to clarify different understanding.
The agile community agrees that transparency is a core value of agility . One very successful approach to foster transparency is visualization. Many agile teams already use visualization to specify requirements. Personas, storyboards, customer journeys or other visualization techniques visualize requirements more transparently and understandably than text documents. Innovation Arena uses this mechanism.
The Innovation Arena approach works best if a team identifies and develops a specific “language” for visualizing requirements, especially at the epic level. A visualization language is an agreed set of techniques and formats that are best suited for the project’s context and the team to visualize requirements. This could be, for example, a combination of:
A different combination could be
A recommendation of Innovation Arena is that an agile team uses an agreed format for this visualization language. As a first choice we recommend the use of a physical pin-board, but a flip or even a virtual pin-board work just as well. A physical pin-board has the benefits of fast rework, being mobile, representing a physical location and a central focus point for communication and conversation. The recommendation of a physical pin-board for sure requires co-location. Video conference or virtual pin-boards are means in a distributed environment.
The important factors to select visualization formats are:
This technique follows the idea behind user story cards on a pin-board and the CCC principle of card, conversation, confirmation . All mature agile teams apply this technique in comparison of items; this is normal backlog refinement .
Collaboration is also a core value of agility. Collaboration fosters shared and implicit knowledge; it fosters communication, negotiation and agreement in many aspects. In agile environments with its iterative character, ceremonies are an explicit means to foster collaboration. In Scrum for example, the events of daily standup, sprint planning, review and retrospective are the implementations of ceremonies. Ceremonies also benefit the team as they get used to a certain ceremony rhythm. For example, if a review meeting takes place every second week on Thursday afternoon every team member blocks this date in the schedule and prepares for the next meeting.
We recommend including backlog refinement activities related to the visualized requirements on the pin-boards into the set of ceremonies as well. These activities are typically more mid-term related, i.e. working on the roadmap of development with a time horizon following the next sprint (iteration) up to the next six to twelve sprints.
Observations from projects show that teams use valuable visualizations of requirements on epic (feature) level. i.e. on the level above user stories. These visualizations are used to derive user stories. These epics are typically not added on the top level of a backlog yet are refined and decomposed in the course of development into user stories.
The benefit of this visualization is that a team still has a representation of an epic when it is already decomposed into smaller parts within the backlog. This representation is used to steer development of the related user stories, to derive acceptance criteria for functionality and quality attributes; and for agreement about the comfort level to which an epic is developed, thus avoiding gold-plating of requirements.
In the development of requirements from themes to epics to user stories the teams work with visual representation as follows:
We recommend creating visualizations for important requirements only. Unluckily importance again is a kind of priority of a requirement. So the team has to agree about a lightweight pre-prioritization process. The team might use an explicit technique like  – but this is not a lightweight process. You can apply a more lightweight version of . The identification of a set of criteria with predefined values for every single criterion and a formula that calculates a (to be discussed) priority indicator is a more lightweight process. We recommend the usage of a project and environment specific checklist to identify criteria. This checklist represents the relevant criteria to discuss and fosters the team discussion to come to a decision if a specific requirement is important, i.e. if there is a value in creating visualization for this requirement. An exemplary checklist would be:
According to this list we would recommend a visualization for a requirement with high relative business value, that represents a user interaction and is strongly aligned with the strategic development roadmap. We recommend leading this discussion when a requirement changes maturity level into a specific and agreed status. For example as soon as the team agrees that the maturity of an epic changes from cloud to tree, the team takes the decision whether a visualization shall be created of not.
A next step of team maturity might be that a team defines a “definition of ready” for an epic on maturity level “tree”. Taking the decision about visualization then is an entry in this “tree maturity level definition of ready”. With this step we know at least which epics are important. In the best case there is only one, typically however there is a set of epics that are equally important. In this case the team driven by stakeholder and product owner interest have to decide on a more elaborated priority of the requirements.
Based on the previous work invested in the development of requirements engineering the team has a sound base to take the priority decision. Visualization of epics supports the agreed maturity level and the identification of the important set of epics that need to be prioritized more precisely. To take this decision as an explicit step, we developed the workshop format we call Innovation Arena workshop.
The following list summarizes backlog refinement activities that address product roadmap development and are pre-requisites to run an Innovation Arena workshop based on epics. These activities are run regularly, better continuously built in, as techniques used for backlog refinement of upcoming product development.
Ideally the Innovation Arena workshop is part of the ceremonies of an agile team just as the planning, review and retrospective are, but not on a sprint basis. More generally said the cadence of running an Innovation Arena workshop depends on the volatility of the epics and the speed of development. If a team has already established an internal release cycle comprising of several Sprints, we recommend for example running one Innovation Arena workshop per internal release cycle as part of the normal backlog refinement sessions. A team welcomes an Innovation Arena workshop as an alternative format of backlog refinement.
To execute an Innovation Arena run in your company, the team selects the requirements under discussion and invites attendees. Based on the previous work of pre-selection, visualization and definition of maturity levels a selection might be: Take all epics at the maturity level of “tree” that have a visual representation. The ideal number of epics shall be between 5 to 15 items.
The workshop format recommends the engagement of a moderator to guide the discussion through objectives and time boxes. We recommend a neutral moderator taking this responsibility. The moderator invites for participation in the Innovation Arena workshop. It is important that the product owner, the team, stakeholders and additional selected participants take part in this decision about priority.
Prepare the invitation for the participants – as for any workshop that you prepare. The invitation shall include the following information:
We strongly recommend avoiding any required reading or preparation in advance. Individuals shall attend with explicitly no need for preparation. Innovation Arena ideally becomes a “used to” ceremony of the team and an appreciated opportunity for external participation.
Prepare a room so that all participants and the material fit into the room and there is still extra space to move. As a rule of thumb use the following criteria to identify a room:
In good time, well before starting the workshop, approach the key drivers behind an epic to ensure that they are interested in presenting the value of the epic during the Innovation Arena workshop. Motivate the key driver as their chance to pitch their epic using the pin-board visualization in front of the participants.
Place sticky notes in different colors (useful are yellow, green and light red ones) on the tables together with markers and sticky points (in least in three colors red, green, blue) needed for the rating process.
Now your room is prepared and the Innovation Arena is ready to start.
The proposed agenda for an Innovation Arena Workshop is as following:
|1||2:00 pm||As moderator: prepare the room, place the ideas on the pin-boards|
|2||3:10 pm||The Get-Together
The participants are entering the room
The moderator (product owner/manager) introduces workshop objectives and agenda.
|3||3:10 pm||The epic pitching
With all participants present, the key drivers of the epics pitch their epic within two to three minutes (strictly time-boxed to three minutes).
|4||4:00 pm||Rating of epics
All participants discuss, communicate and rate the epics using well know criteria.
|5||5:00 pm||A short break to discuss and add additional feedback|
|6||5:15 pm||Presentation of results
The ranking of the epics is presented to the audience.
The feedback is given back to participants.
|8||5:45 pm||After session social event
Serve something to the audience like pizza, cola, ...
The moderator explains the objectives and the workshop steps. It is important to highlight the collaborative nature of the workshop where the participants have the chance to give feedback.
The moderator specifically explains how to use the prioritization criteria, how the rating is executed by the participants and how the results will be determined.
Once the Innovation Arena is part of the recurring ceremonies, the introduction by the moderator will be very brief.
The key driver of an epic uses the visualization to present the epic. He presents the why and how of the epic to the participants to explain business value and objectives that shall be met by this epic; including quality attributes or the comfort level of implementation expected by users. The comfort level is an interesting attribute of a requirement, often a combination of the quality attributes of usability and flexibility in use . A clear understanding whether a requirement will be implemented gold-plated or in a basic form only has direct impact on the effort required for implementation.
The pitch is strictly time-boxed; we recommend 5 minutes per item. The presentation of all epics shall not exceed 60 minutes, with 45 minutes as the better option. After 45 minutes interest and concentration of participants goes down dramatically resulting in non-balanced ratings.
The rating of epics is the time for asking questions, collaboration and communication. We recommend that the key driver of an epic acts as first contact to lead the communication in front of the epic visualization. This is the point where visualizations on physical pin-boards really do deliver value. In distributed environments with virtual visualizations this step has to be designed specifically according to the constraints of being distributed using video conferencing and other supporting techniques.
The goal of this step is to allow all the participants to have the opportunity to ask questions and to get answers; and to give feedback in a form that is visible to all other participants. On a physical pin-board posting sticky notes in different colors are the best means. To foster this opportunity for communication and feedback, one hour is scheduled for this step in the Innovation Arena workshop.
The rating criteria used in an Innovation Arena workshop are very important. As it is impossible to use an elaborated set of criteria like in  in agile environments, a different approach for using criteria has to be applied. The case study report  pointed out that prioritization in agile projects often does not fulfill expectations. In a very interesting talk  Neno Loje presented a smart lightweight set of criteria that focus and guide the rating done by the participants in requirements workshops on epic level. These criteria implicitly consider the important attributes of value and cost attributes. These criteria are:
The strict constraint to mark only the most, respectively the least important epic addresses emotional behavior of human beings. In case a person has the choice to pick three out of ten items and then rank these three items in order of importance, the person feels a conflict about the ranking of the three items selected. In case a person is allowed to pick only one single thing, the majority of individuals take a clear decision what really is the most desired thing. This is the principle behind the first question. Every participant is pleased to mark the most important and the least important – but only one single epic.
The second question addresses the individual’s emotions attached with a specific epic. As the first question addresses the objective factor of business values, this question respects the emotions of the individual. As all participants state their emotions attached with the epics under discussion, we receive a fair result as to which requirements excel because of emotional attachment.
The third question is related to the strategic direction of the organization. Attendees shall give their feedback to what extent the epic as aligned with the organization’s strategy.
The ranking is executed by a dot-rating procedure as following
As such, it is best to prepare a ranking table for each epic (physically or virtual) as in Table.
|Importance to your business||Satisfaction with existing||Is this the right direction to go?|
|Most important||Least important||Does the existing functionality meet your needs?|
Best practice in ranking is that participants receive dots in different colors (1a: green, 1b: red, 2: yellow, 3: blue). Before sticking the dots onto the ranking table, the participants mark their dots with the proposed epic. This averts the effect that the first participant sticking dots influences the other participants in their ranking.
The result is that all epics are ranked based on the three criteria. The absolute ranking is expressed by a formula that weights the dots for each criterion. This formula is individual for the problem space and context. The team has to decide about the ranking formula before the ranking is executed by the participants. The formula determines the ranking in a formal way.
When all participants have ranked the epics, a break is welcome. This is the point for additional communication and exchange. This communication takes place before results are presented so is unbiased from results. On the other hand, this break is required for the moderator to calculate the ranking based in the dots on the ranking table.
After the break the results are presented as is. Short feedback from the participants is welcome. Feedback shall focus on obvious inconsistencies within the ranking. The participants finally have to confirm the ranking result, although a single participant may not agree about the ranking.
To get the confirmation, the moderator shall explicitly pose the question for confirmation. If a single participant does not confirm, it is important to document this and to address this non-confirmation with the participant as follow-up to this meeting.
The workshop is closed with a retrospective. The retrospective shall concentrate on workshop preparation, epic selection, workshop proceedings, workshop steps and the cadence of the workshop in the flow of development. The retrospective shall not touch the rating result or content of epics.
We recommend a small and informal social event as to close the Innovation Arena workshop. This is the reason the agenda starts at 2pm. The social event is an important slack time to discuss the workshop proceedings as a whole and specific epics in detail. It is the opportunity to communicate with participants who did not confirm the elaborated priority of epics and to select opinions of participants that could help to improve the overall process.
It is the responsibility of the product owner or product manager to reflect the results of the Innovation Arena workshop back into the product backlog. As the Innovation Arena workshop represents a backlog refinement activity, the results of this activity reflects the team’s collaborative work.
This article discusses Innovation Arena as an agile approach to prioritization. In fact Innovation Arena goes beyond prioritization as it combines a set of techniques already used and accepted by agile teams such as working with epics; using visualizations in a card, communication, confirmation style, ceremonies in iterative life cycles, backlog refinement activities and others. Using all these agile techniques for prioritization is an added beneficial aspect.
Innovation Arena focuses on the prioritization of themes and epics, the more coarse grained set of requirements. An explicit discussion about the priority regularly executed with the whole team fosters shared knowledge and understanding. The Innovation Arena workshop, built in as part of the ceremonies, reviews and reinforces the understanding of priorities and the road-mapping of future development. This shared understanding will steer future development when deriving or decomposing epics and themes into user stories. Team members will reflect this shared understanding implicit in the prioritization of user stories in “normal” backlog refinement activities or sprint planning sessions.
In this way, Innovation Arena addresses the fundamental requirements for collaborative prioritization as specified in the beginning of this article: 1. lightweight; 2. using relevant prioritization criteria and 3. well accepted by agile teams.
Innovation Arena is also compatible with existing frameworks and blueprints of how to scale agility in large organization. For example Innovation Arena would fit into the scaled agile framework SAFe  as an alternative to weighted shortest job first (WSJF) prioritization technique and as part of the SAFe release train workshop.
From the perception of the authors, from agile projects in different domains and contexts, Innovation Arena shows benefit in agile environments, although the author has no scientific evidence to prove this perception. The specific techniques and ceremonies to establish Innovation Arena have to be adapted to the needs of teams and the context of development. There are scenarios where Innovation Arena will show benefits and there are scenarios where Innovation Arena will not work. Innovation Arena is no silver bullet to resolve agile road-mapping and prioritization – following the agile mindset that silver bullets do not exist to address challenges in complex emergent systems.