Innovation Arena

Prioritization – where are we today?

Prioritization of requirements is an essential activity in all types of development.
The objectives of requirements prioritization are to

• Develop the most important requirements first.
• Manage the effort in development in a way to optimize return on investment.

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 ^{[1] , [2]} and ^[5]. 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, ^[2] 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:

1. Effort required for prioritization: The team has to set criteria values every iteration, with the impact of high effort spent in prioritization resulting in decreasing efficiency.
2. Team mindset: Agile teams do not use very formal prioritisation techniques as specified in ^[2]. The product owner typically prioritizes business value and risk derived from direct communication with the stakeholders.

The need to regularly re-calculate the priority of requirements is clearly stated as important. Changing prioritization of requirements is discussed in ^[2] 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 ^[7]”. 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 ^[3]: 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 ^[3] 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 ^[3]: “…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.

Prioritization in agile environments – the vision

State of the art prioritization is obviously a challenge in agile environments. The precise summary of previous work and research is that:

• Classical techniques are relevant and successful ^[1], ^[2] and ^[5].
• The required effort to execute classical techniques does not allow for their application in agile environments due to the short iterations ^[5].
• Agile value and cost based techniques as proposed for agile development tend to fail in practice ^[3].

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:

1. The technique is lightweight: the ratio of effort for prioritization activities and overall project effort is equal or less than classical life-cycle models.
2. The technique respects the relevant criteria as given in ^[3], either explicit or implicit: value and cost based criteria as well as business value, risk, size and complexity
3. The technique is accepted in teams with an agile mindset.

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.

Core values of Innovation Arena

The core values of Innovation Arena are:

• Requirements maturity level, agreed by stakeholders.
• Visualization of requirements
• Collaboration and iterative life cycle

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 maturity level, agreed by stakeholders

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 ^[8]. 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:

• Stakeholder: Any individual that has interest in the business value and / or quality attributes of the subject under development. These are primarily users of the system under development as well as the customer, but as well individuals that have interest such as enterprise architects, or representatives from operations or support.
• Agile team: The team that owns all skills to develop the system and that is responsible to develop the system in the definition following Scrum.
• Team: Stakeholder plus agile team(s) plus optional additional individuals that are involved in the overall development. These additional individuals are for example product manager, business analysts, subject matter experts or other roles and responsibilities that exist in larger organizations.
• Team member: A member of the team as defined above.

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.

Visualization of requirements

The agile community agrees that transparency is a core value of agility ^[12]. 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:

• Text: The specification of an epic including the rationale and business value for the user or stakeholder.
• A persona that specifies the user of an epic
• One or a set of storyboards that demonstrate the most important scenarios and will be used to derive user stories.
• A set of wireframes that demonstrate the first ideas of a human computer interface.

A different combination could be

• Text: The specification of an epic including the rational and business value for the user or stakeholder.
• A Business Model Generation Canvas ^[9]: A technique used to define a business case. An epic represents a kind of mini-business-case delivering business value.
• One or a set of storyboards that demonstrate most important scenarios that will be used to derive user stories.

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:

• Visualization is comparable in representation, .i.e. the requirements are represented similarly so that an individual is able to compare the attributes of a requirement such as size, complexity, business value and maturity.
• Visualization really can be visualized, i.e. the items can be arranged side by side so that stakeholders and team can pass by (physical or virtual) and compare requirements (themes, epics, features, …) or whatever the subject of comparison is.

This technique follows the idea behind user story cards on a pin-board and the CCC principle of card, conversation, confirmation ^[10]. All mature agile teams apply this technique in comparison of items; this is normal backlog refinement ^[11].

Collaboration and iterative life-cycle

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:

• The team creates a visualization for a requirement as soon as they recognise value in having a visualization. Not all requirements need visualization. For example the systems quality requirement “availability: 95%” is probably not a candidate for visualization. This requirement rather is represented by a quality requirement card on the project planning board. Good practice is to restrict visualization to important requirements.
• The team develops the requirement by adding information to the visualization and reflecting important changes to the backlog items, for example by creation of a spike user story to gain more information about a requirement. This is done regularly in backlog refinement sessions.
• The team also decides on the maturity level of the requirement. The maturity level is a visual indicator for the team to steer the focus of work. The maturity of a requirement has to go from star to road level as the requirement is discussed and understood and finally decomposed into user stories and tasks. As a general rule a team shall invest more effort into requirements that are near implementation (on tree level) than on anything vague in the future (star level); and shall invest more effort into a requirement for which the maturity level is not yet agreed, i.e. some stakeholders claim it is still on cloud level while others claim it is already on tree level.

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 ^[1] – but this is not a lightweight process. You can apply a more lightweight version of ^[1]. 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:

• Business Value (use planning poker to agree about the number)
• Suitable for visualization (business process, user interaction, story-telling item, statistics, …)
• Architectural impact (low, medium , high)
• Alignment with strategic development roadmap (low, medium , high)

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.

• Identify new epics if needed. The time horizon of a product roadmap depends on the product and its context and typically is between 3 months and a year. The product backlog shall not cover development activities that go beyond this time horizon.
• Identify the important epics applying the lightweight pre-prioritization procedure.
• Create visualizations and develop the epics as part of the normal backlog refinement activities. This is effort invested in requirements engineering and business analysis.
• Discuss and agree about the maturity level of each requirement (star, cloud, tree, road). Invest small effort in development of star and cloud level requirements and more effort into the development of tree and road level requirements. Create for example spike user stories to learn more about the epics and prioritize these spike prototypes on top of the product backlog.
• Run an Innovation Arena workshop for a set of requirements on the same maturity level. The result influences the order of the epics in the backlog. Tree level epics shall are above star level epics in the product backlog

A proposal for an Innovation Arena workshop agenda

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.

Invite attendees and prepare the workshop setup

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.

• Invite the stakeholders that have interest in the epics represented. In an ideal world a stakeholder feels responsible for an epic and is willing to present the epic to the attendees of the workshop.
• Invited selected members of the management, i.e. sponsors or product managers. Invite from time to time managers not directly related with product development such as the head of marketing, operations or support. As long as you do not exhaust the members of the management, this is a chance to foster transparency within the organization and to do internal project marketing.
• Think about inviting partners, key customers and externals. Positive but critical individuals from outside your organization are even more unbiased and will challenge. Prerequisite is that these individuals are persons of special trust. For sure the team is able to identify individuals that qualify.

Prepare the invitation for the participants – as for any workshop that you prepare. The invitation shall include the following information:

• Date, time, length and location of the Innovation Arena.
• The agenda of the workshop: internal team members may already know this as part of the project ceremonies. (Project) external participants like members of management or key customers need more information to feel comfortable. This is part of expectation management.
• Motivation for the individual why to attend: What are the benefits for the individual? Take the chance and address the personal needs and interests of the potential participant.
• The benefit for the team and for the organization in large.
• The expected output.
• Confirm that no preparation is needed to attend.

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 the room

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:

• Space for about ten pin-boards
• Space for all the attendees to move freely between pin-boards and discuss
• One or two tables in the background to place moderation material, marker, sticky notes, ...

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.

Agenda

The proposed agenda for an Innovation Arena Workshop is as following:

Step	Time	Activity
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.
7	5:30 pm	Retrospective
8	5:45 pm	After session social event Serve something to the audience like pizza, cola, ...

Objectives and goals of the individual workshop steps

Step 2: The Get-Together

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.

Step 3: The epic pitching

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 ^[15]. 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.

Step 4: Rating of epics

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 ^[1] in agile environments, a different approach for using criteria has to be applied. The case study report ^[3] pointed out that prioritization in agile projects often does not fulfill expectations. In a very interesting talk ^[13] 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:

1. What is the importance to your business?
   a. Mark the most important
   b. Mark the least important
2. How do you rate your satisfaction with the existing?
   a. Low
   b. Medium
   c. High
3. Is this the right direction to go?

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

• Criterion 1a: Each participant places one single dot to one epic only
• Criterion 1b: Each participant places one single dot to one epic only
• Criterion 2: Each participant places one dot on one of the options 2a, 2b or 2c. It is allowed to skip epics, i.e. a participant may set a dot for criterion 2, but does not have to.
• Criterion 3: Each participant gets half the number of dots as epics are proposed for rating (round up in case of uneven number of epics). A participant distributes the dots freely amongst the epics. It is valid to place all or none of the dots on one specific epic.

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?
		Low	Medium	High

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.

Step 6: Presentation of results

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.

Step 7: Retrospective

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.

Step 8: After Session Social Event

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.

Reflect Innovation Arena results in Product Backlog

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.

Summary

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 ^[14] 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.

References

• [1] Karl E. Wiegers; “First Things First: Prioritizing Requirements”; http://www.processimpact.com/articles/prioritizing.html; originally published in Software Development, September 1999
• [2] Rick Botta (BAE Systems), A. Terry Bahill, PE (University of Arizona); “A Prioritization Process”; Engineering Management Journal Vol. 19 No. 4 December 2007
• [3] Zornitza Racheva, Maya Daneva, Klaas Sikkel, Roel Wieringa (University of Twente Enschede Netherlands), Andrea Herrmann (University Braunschweig); “Do We Know Enough about Requirements Prioritization in Agile Projects: Insights from a Case Study”; 18th IEEE International Requirements Engineering Conference (RE) 2010; ISBN 978-1-4244-8022-7
• [4] Z. Racheva., M. Daneva, A. Herrmann, R. Wieringa, “A conceptual model and process for client-driven agile requirements prioritization”, in the Proc. f 4th International Conference on Research challenges in Information Science, Nice, France, May 2010, IEEE
• [5] Muhammad Ramzan, M. Arfan Jaffar and Arshad Ali Shahid; “Value Based Intelligent Requirement Prioritization (Virp): Expert Driven Fuzzy Logic Based Prioritization Technique”; International Journal of Innovative Computing, Information and Control ICIC International, Volume 7, Number 3, March 2011
• [6] Neil Maiden, Suzanne Robertson* & Alexis Gizikis; „Provoking Creativity: Imagine What Your Requirements Could be Like“; IEEE Software Magazine, Volume:21 , Issue: 5; ISSN 0740-7459, Oct 2004
• [7] Gilb, Tom, and Mark W. Maier, “Managing Priorities: a Key to Systematic Decision-making,” Proceedings of 15th Annual; International Symposium of INCOSE, Rochester, NY, (July 2005).
• [8] Markus Flückiger, Pete Jones; Blog about “Stars To Road”, http://starstoroad.com/blog/
• [9] Alexander Osterwalder, Yves Pigneur; Business Model Generation: A Handbook for Visionaries, Game Changers, and Challangers, Wihley Aug 2010, ISBN 978-0-470-87641-1
• [10] Three C’s; Ron Jeffries; Aug 30, 2001; card, conversation, confirmation; see: http://xprogramming.com/articles/expcardconversationconfirmation/
• [11] Download area of the official Scrum Guide on scrum.org ; https://www.scrum.org/Scrum-Guide;
• [12] The Agile Manifesto; http://agilemanifesto.org/; 2001
• [13] Talk and slides: Kontinuierliches Feedback, www.teamsystempro.ch and www.scrum.org; Neno Loje: Excellence in Software Engineering Conference ESE 2012, Zürich
• [14] The Scaled Agile Framework SAFe; www.scaledagileframework.com; delivered by the Scaled Agile, Inc; 5480 Valmont Rd., Suite 100, Boulder, CO 80301 USA
• [15] ISO/IEC 25010:2011; Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models; International Organization for Standardization