The Agile Requirements Refinery: Applying SCRUM Principles to Software ProductManagement

Kevin Vlaanderen, Sjaak Brinkkemper, Slinger JansenDepartment of Information and Computer Sciences

Utrecht UniversityUtrecht, the Netherlands

(k.vlaanderen,s.brinkkemper,s.jansen)@cs.uu.nl

Erik JaspersPlanon B.V.

Nijmegen, the Netherlandserik.jaspers@planon.nl

Abstract—Although agile software development methodssuch as SCRUM and DSDM are gaining popularity, theconsequences of applying agile principles to software productmanagement have received little attention until now. In thispaper, this gap is filled by the introduction of a method forthe application of SCRUM principles to software product man-agement. For this purpose, the ’agile requirements refinery’ ispresented, an extension to the SCRUM process that enablesproduct managers to cope with large requirements in an agiledevelopment environment. A real-life case study is presented toillustrate how agile methods can be applied to software productmanagement. The experiences of the case study company areprovided as a set of lessons learned that will help others toapply agile principles to their software product managementprocess.

Keywords-Software Product Management; RequirementsManagement; Requirements Refinery

I. INTRODUCTION

One of the major innovations in software developmentmethodology of the last few years has been the introductionof agile principles. Since the creation of the Agile Mani-festo in 2001, including the years leading to its creation,several agile software development methods have come intopractice [1]. Examples of such methods are DSDM [2],Extreme Programming [3], Feature Driven Development [4]and SCRUM [5]. The strong points of such methods are thatby employing them, the development process becomes moreresponsive to a changing environment, working softwareis chosen over extensive documentation, individuals andinteractions are considered more important than tools andprocesses, and customer collaboration is valued more thancontract negotiation [6].

In the last few years, these agile methods have provento be successful in a large number of cases. Companiesthat have put the agile method SCRUM [5] into practicerange from small companies as described by Dingsøyr etal. [7] to large multinationals [8]. Research has shownthat the use of SCRUM within a company can lead tosignificant benefits [9], and that its use is not limited tolocal projects [10].

As a consequence, demand for the extension of agileprinciples to other domains has risen. One such domainis software product management. Software product man-agement (SPM) is the process of managing requirements,defining releases, and defining products in a context wheremany internal and external stakeholders are involved [11],[12]. The topic of SPM touches upon several other areas.In the related field of lifecycle management and releaseplanning, several approaches have been proposed regardingmarket-driven requirements engineering [13], requirementsinterdependencies [14] and evolutionary and iterative releaseplanning [15]. Another related field, requirements prioritiza-tion, has seen several publications in recent years, includingwork on requirements prioritizing for product software [16]and distributed prioritization [17].

Due to the complexity of software products, with a largevariety of stakeholders, long lists of requirements and arapidly changing environment, SPM is a complex task.However, relatively little scientific work has been performedin this area. An attempt to close this gap has been providedby Weerd et al. [11] in the form of a reference framework forSPM. Their work aims at providing a structure for the bodyof knowledge regarding SPM by identifying and definingthe key process areas as well as the inernal and externalstakeholders, and their relations.

Currently, little work exists regarding agile SPM. A casestudy describing the use of agile requirements engineering isdescribed by Pichler et al. [18]. However, the paper does notprovide details regarding the details of the agile requirementsengineering process. In order to fill this gap, we willdescribe in which way software product management can beperformed in a SCRUM development context. The researchdescribed in this paper proposes an agile SPM method basedon SCRUM, which improves the ability to handle large-scalerequirements in an agile environment. Furthermore, a casestudy was performed at a product software company locatedin the Netherlands that has worked with the agile SPMmethod for nearly two years. By showing their experiences,a set of useful lessons learned is provided that aids in theimplementation of SCRUM-inspired SPM alongside agile

Figure 1. Agile Software Product Management

software development at other companies.Section II continues with a description of the proposed

SCRUM-inspired agile software product management pro-cess. In section III, an outline of the case study approach isgiven, including the research triggers, questions and meth-ods, and a description of the validity threats. This is followedby an introduction of the product software company at whichthe proposed method has been used. In section IV, the resultsof the case study are shown in the form of an analysis of thetasks within the process. To conclude, section V contains adescription of the lessons learned regarding agile SPM andsection VII provides conclusions and suggestions for futureresearch.

II. AGILE SOFTWARE PRODUCT MANAGEMENT

This section describes a method for applying agile SPMin product software organizations that work according toagile software development practices. One should take intoaccount that the proposed method is based on the defaultSCRUM process [5], developed initially for the purpose of(software) product development. Section II-A gives a shortsummary of the SCRUM development method, followed bythe adaptations that have been applied to make the methodapplicable to SPM in section II-C.

A. SCRUM Development Method

The SCRUM development method was proposed in 1995by Ken Schwaber [5], at a time when it became clearto most professionals that the development of softwarewas not something that could be planned, estimated andcompleted successfully using the common ’heavy’ methods.The SCRUM method is based on the work of Pittman [19]and Booch [20], and adheres to the principles of agilesoftware development.

Central to SCRUM is the idea that many of the pro-cesses during development cannot be predicted. It thereforeaddresses software development in a flexible way. Theonly two parts that are fully defined during a softwaredevelopment project are the first and last phase (planningand closure). In between, the final product is developedby several teams in a series of flexible black boxes called’sprints’. No new requirements can be introduced duringthese sprints. This ensures that the final product is beingdeveloped successfully, even within a constantly changingenvironment. This environment, which includes factors suchas competition, time and financial pressure, maintains itsinfluence on development until the closure phase.

One of the central documents in the SCRUM method isthe product backlog (PB). The PB contains a prioritizedlist of all items relevant to a specific product. This list canconsist of bugs, customer requested enhancements, compet-itive product functionality, competitive edge functionalityand technology upgrades [5]. Each team that participatesin the software development process maintains its owndevelopment sprint backlog (DSB). All requirements thatare assigned to the development team are put on their DSB.Every requirement is decomposed into several tasks, whichare then assigned to specific team-members.

B. Agile SPM

The agile SPM process and SCRUM are similar in theaspects that they both work in sprints, and both developersand product managers perform tasks according to a productbacklog and a sprint backlog. The difference is that at theend of a sprint developers produce a working version of thesoftware, whereas the product managers produce a productbacklog that feeds directly into the SCRUM developmentprocess.

Agile SPM enables a software vendor to flexibly definerequirements according to a pre-defined procedure. The pre-defined procedure forces a software vendor to explicitlymanage the lifecycle of a requirement, leading to better-defined requirements. Simultaneously, the process remainsagile, i.e., some requirements can be defined and imple-mented quickly, while others move through their lifecycleat a regular pace

Figure 1 displays a visualization of the agile SPM process.The figure is based on the default SCRUM development pro-cess, and is supplemented with the SPM-specific adaptations.The framework is based on information gathered from thecase company during the case-study.

The input for the SPM process is in most cases an idea ora wish for new functionality. This idea enters the process inthe form of a vision, shown by the cloud at the bottom leftof the figure. During a number of sprints, this vision is thenrefined several times, going through the agile requirementsrefinery, which will be discussed in the next section. TheSPM teams select a set of PB items and place them ontheir PSB, after which the tasks on the PSB are performedduring the length of the sprint. The main deliverable of thisprocess is an updated version of the PB that can be usedby the development teams to develop the software product.As a result of sprint review meetings held at the end ofeach sprint, new (retrospective) knowledge is gained thatcan help to improve the process. Finally, the figure includesbugs from earlier versions. These form an alternative wayof generating PB items and do not follow the usual paththrough the requirements refinery, introduced in section II-C.Instead, they are placed directly on the PB.

Each working day, also known as a scrum, starts witha SCRUM-meeting during which the previous day is dis-cussed. As this session is primarily meant to improve theproductivity and the effectiveness of the SPM team, asmall set of possible improvements is discussed. This helpsavoiding experienced problems in the future.

The end-result of an agile SPM sprint, lasting betweentwo and six weeks, consists of the requirements definitionsused by the development teams. The sprint length is equalto the length of development sprints, in order to synchronizethe heartbeat of the product management and the develop-ment process. For each sprint a product management sprintbacklog (PSB) is composed for each SPM team. The PSBconsists of tasks that can be finished by the SPM team withinthe sprint.

C. The Requirements Refinery

The structuring of the workflow into sprints and scrumsenables agile SPM dealing with customer wishes. Similarto the SCRUM development method, no new items can beadded to the PSB, as it has been finalized at the beginningof the sprint. This means that the SPM team(s) can focuson the work at hand without disruptions. On the other hand,

it also requires considerable thought about the structuringof specific tasks, since they need to be completed withinthe timeframe of one sprint. SPM tasks, however, are noteasily restructured into fine grained tasks of up to onemonth. For this reason, the default SCRUM-approach to taskmanagement has been substituted by the more fine-grainedapproach that is described in this paper.

This approach, the agile requirements refinery, provides asolution for managing large requirements. The approach issuited to the characteristics of SPM tasks, and it resemblesan industrial refinery in a way that during each sprintor iteration work is being performed on the requirementdefinitions that appear on the PB, to refine them from coarse-grained to fine-grained. Each refinement, from one stageto the next, can generally be performed within one month.When this is not possible, the item is placed back on thePB to be picked up again in the future. Structuring the SPMtasks in such a way results in backlog items with a smallergranularity, suited for the length of a sprint. By refininglarge requirements according to the abstraction levels of therequirements refinery, structure is added to the backlog thatwill help in completing the tasks in an effective manner.

Since SCRUM itself does not provide guidelines for effec-tively managing large amounts of requirements of differentgranularity, a set of stages is introduced. Within the agilerequirements refinery, a product functionality vision willgenerally move through these stages, during which it isrefined with details and specifications. The stages are:

• Vision – A vision is the starting point for each productlifecycle. It is an idea, brought up by the companyboard, a customer or any other stakeholder, and isdefined in generic terms. Once the idea reaches aproduct manager, he or she then converts it into a (setof) theme(s). An example of a vision is the wish totarget small enterprises as potential customers for anERP software package.

• Theme – A theme is the formal elaboration of a vision,describing it in more detail. The product managerdefines the envisioned purpose of the new functionality,the business value of the theme, and the involved stake-holders. A theme should briefly describe the businessproblem from which it originates and the main issuesthat fall within the theme scope. This can where possi-ble be extended with a set of provisional requirements.In total, a theme description should not exceed one pageof text, in order to maintain clarity. The previouslydescribed vision can for instance be translated to thetheme ’small enterprises’, describing its importance andwhat would be required to accomplish it. In reality, avision is often so complex that it can be refined intomultiple themes. To ensure the technical feasability ofa theme, it is reviewed by the development teams.

• Concept – Themes are broken down into smaller piecescalled concepts. A concept is a high-level focal pointwithin the theme, consisting of a set of solution storiesthat can later be used to deduct detailed requirements.The elaboration of each concept results in a documentdescribing product drivers, product constraints and theconcept scope. The description should on the one handbriefly explain the necessity of the concept, while onthe other hand it should be clear and detailed enough tobe able to use it for the definition of detailed require-ments. The previous ’small enterprise’ theme could forinstance be converted to a set of concepts such as’productX Lite’, describing the high-level requirementsof a software product suited to the needs of smallenterprises. Each concept definition should be checkedwith the software architect(s).

• Requirement definition – The detailed definition ofrequirements is performed in three steps, of whichonly the first one is performed by the SPM team(s).SPM translates the concepts into a list of require-ment definitions without going into a lot of detail.Requirement definitions consist up to this point of adescription, a rationale and a fit criterion. The latterdescribes a constraint that must be met in order for thisrequirement to be successfully implemented. To ensurefeasability and compatibility with other requirements,each requirement definition should be checked witharchitects, functional designers or lead developers.After the initial high-level requirement definitions havebeen determined based on the previously defined con-cepts, the software development teams then elaboratethese into requirements containing a detailed descrip-tion of some desired functionality, described in suf-ficient detail to work with. To accomplish this, eachrequirement definition is first processed during a devel-opment sprint by a development team, to ensure thatthey are feasable, consistent and understandable in ageneral manner. Then a second pass is made, where thedevelopment team ensures requirement clarity, so thateach requirement is understood by all team members.This results in a list with all relevant requirements andtheir detailed descriptions, including any necessary di-agrams, technical specifications or otherwise necessaryinformation that is required for the implementation ofthe requirement.

With smaller topics, the definition of a vision and atheme might not be necessary, in which case the problemcan be placed within an existing theme or concept. Theyare then elaborated without constructing a vision, themeand/or concept, or they are elaborated with the vision,theme and concept constructed afterwards. In other words,the requirements refinery is not restricted to a top-downapproach, but can also be used bottom-up.

D. SCRUM SPM Process

Figure 2 shows a view of the SCRUM SPM process, basedon the meta-modelling technique by van de Weerd [21]. Inthe figure, the deliverable side has been omitted in order tofocus on the process aspect. Its notation is based on a UMLactivity diagram. Standard activities and sub-activities aredepticted by white boxes, and open activities are shown bygray boxes. Arrows are used to show the control flow fromone activity to the next. The top part of the activity diagram,indicated by a light gray box, will recur several times withineach SPM sprint, once for each requirement.

At the start of each sprint, each SPM team has to prepareits PSB. The teams make a selection of PB items, of whichthey think that they can be completed within the upcomingsprint. This activity is similar to the sprint preparation asperformed by the development teams.

The next step is to proceed with either refining the itemsthat are on the PSB, or introducing new ideas obtainedthrough customer support, meetings with business consul-tants, customer sessions, industry analysts and involvementat different types of forums in which market parties areactive. During a sprint, each item is refined from its currentstage to the next level of detail, i.e. from vision to theme orfrom concept to requirement definition.

When a vision enters the process, it is described globally,after which one or more themes are derived from it. Eachtheme is described according to the specificion in II-C. Whenthe description is finished, the required investment needed toimplement the team is estimated. Themes are then reviewedby the development teams, after which they are placed onthe PB.

Concept specification starts with breaking down the themeinto a set of concepts. Every concept contains a set ofsolution stories which are used for defining detailed require-ments. The concepts are defined by product managers andsoftware architects. Again, an estimation is made regardingthe required investment for implementation. After conceptsare defined, they are reviewed by software architects anddomain experts.

If a concepts is approved, the concept is broken down intoa set of requirement definitions. A requirements engineerand a SCRUM development team are responsible for thedefinition of requirements. Requirements can be brokendown into smaller pieces to fit into a sprint. Requirementsare also assigned a priority, after which they are put onthe PB. The highest rated requirements are to be developedfirst. This priority rating is assigned by the product boardand the sales department, and the requirement definitions arereviewed by lead developers, architects, functional analystsand domain experts. In some cases, requirement definitionsare rejected due to being unclear or because they are notdescribed in sufficient detail. In such cases, the requirementdefintion needs to be further specified.

When requirement definitions are approved, the costs andbusiness value are calculated. Each requirement is valuedand prioritized, after which the ordered list is placed on thePB, where it is used for deciding when features will be de-veloped. After prioritizing the requirements, time is allocatedto each requirement or concept to allow the determinationof a sprint planning. When requirements are clear and haveenough detail they are assigned to the development teams.The requirements are then placed in the DSB of the specificdevelopment team.

After each completed SPM sprint, an evaluation takesplace. During this evaluation, each team looks back at thelast sprint, and discusses about the aspect that went good orwrong. The results are written down, and from the resultinglist, two or three items are chosen to be put on the sprintbacklog of the next SPM sprint. This enables the teams togradually improve the process, learning not only from theirown mistakes, but also from those of the other teams.

E. SPM Sprint

The agile aspect of the proposed SPM approach liesmainly in the fact that, like software development, the SPMtask is performed according to sprints with a fixed length of

Figure 2. SCRUM Software Product Management Process

two to six weeks (varying per company). These sprints arenot performed synchronously to the software developmentsprint, but are shifted back half of the development sprintduration. This ensures that the DSB is always up-to-date andready for use once the software development sprint starts, re-ducing the time between the inception of a requirement andits realization in the product. Also, information regardingimplementation progress and the accuracy of requirementssizes and descriptions can flow back from the developmentteams to the SPM teams.

Figure 3. Alternating Sprints

Figure 3 illustrates this concept of alternating sprints.The horizontal timeline shows the synergy between softwareproduct management and software development, by switch-ing from a focus on SPM to a focus on software developmentand back. The SPM team(s) deliver(s) an updated PB whilethe development teams are developing the next productrelease candidate (depicted by a floppy). Based on thisrelease candidate, SPM will then redefine the PB, resultingin continuous double-loop feedback.

Similar to SCRUM software development, the status ofcompleted, canceled or ongoing tasks is continuously keptup-to-date on the PSB. Also, a burn-down chart is createdcontinuously to allow monitoring of the progress of thesprint. Another similarity is that the PSB is filled with itemsfrom the PB at the beginning of each sprint.

III. CASE STUDY RESEARCH APPROACH

The main research question to this research is In whichway can software product management be performed in aSCRUM development context?. This research question canbe split into two subquestions. In the first part of this paper,we have answered the question: how can agile conceptsbe applied to software product management?. This researchquestion is answered by developing a method for agile SPM.In the second part of the paper, we will focus on whatare the implications of introducing agile SPM in an agiledevelopment setting. In order to answer this question, themethod is tested in a case study of a production environmentin a product software company in the Netherlands. Data hasbeen collected to answer the research question [22] by meansof:

• Interviews – The main research questions have beenanswered in part during the unstructured interviewswith product stakeholders. We interviewed one require-ments engineer, two product managers and the chieftechnology officer. These interviews were recorded,and information regarding the SPM process and issuesrelated to it were extracted later on.

• Document study – The case company provided uswith guideline documents such as the altered Volererequirements specification template [23] that is in useat the case company, the product backlog and the sprintbacklogs for the SPM team. These documents wereadded to our case study database. Some of the filled-in Volere templates were used to gain understandingabout the relation between the PSBs. The PSBs itselfwere used for a qualitative analysis to obtain furtherinsight in the practical consequences of agile SPM andto extract some examples.

Based on the information from the backlogs and the inter-views with the product stakeholders, we have derived theset of lessons learned that is presented in the final section.This list has been appended by the CTO at FacComp. Theentire list has been reviewed by the CTO to make sure thatthe most important items have been addressed accurately.

A. Case Study Company: Planon

The main contribution of this work lies in the descriptionof a unique case among Dutch product software compa-nies, and potentially among product software companies ingeneral. The company at which the case study has beenperformed, Planon International (from now on referred toas FacComp), has, as one of the first known companies,attempted to implement an agile SPM process based on theagile principles in general (and the SCRUM developmentmethod specifically).

FacComp is an international software vendor that pro-duces Facility Management and Real Estate managementsoftware for organizations (Integrated Workplace Manage-ment Systems). Founded in 1984, it currently has a customerbase of over 1300, which is supported by more than 325employees. The company’s products are marketed throughsix subsidiaries, based in the Netherlands, Belgium, Ger-many, UK, India and the US, and a worldwide networkof partners. The company made approximately 1.9 millionprofit with a revenue of 30 million in 2008. FacComp devel-ops client-server software (two- and three-tier architectures)with which it attempts to support the processes of facilitymanagement.

The decision to switch to an agile SPM approach stemmedfrom their positive experiences with agile development.For the implementation of its software, Planon switchedfrom Prince2 to the SCRUM method in 2004. Managementrecognized that by working according to Prince2, severalissues arose. Firstly, release cycles could take up to one or

one and a half year. This was combined with the fact thatrelease end-dates were difficult to predict. Another importantissue was the fact that during a project, many changeswere requested. The Prince2 method did not offer sufficientsupport for this, resulting in a lot of calculations that causeda large share of SPM time to be put into these tasks insteadof in product value. These downfalls motivated the switchto SCRUM, which has resulted in several improvements.Changes are now implementable against far lower costs,and software is developed in one-month sprints, resultingin two releases per year, with marketing-versions deliveredin between.

IV. SPM SPRINT BACKLOG ANALYSIS

To better understand the implications of the SPM adap-tation of SCRUM, an analysis of the PSBs was needed togain a more detailed view of the results and implicationsof FacComp’s adaptations of the SCRUM-process in orderto accomodate SPM. The data-set consisted of twenty-onePSBs, describing an equal amount of months. The PSB’shave been gathered from March 2007, when SCRUM wasintroduced into the SPM process, until November 2008.

The analysis focused mainly on general statistics aboutthe task structure, including task duration and workload perperson, as well as on pattern discovery. Table I displaysstatistics about the sprints included in our study. From leftto right, the table first shows the number of tasks thatwere placed on the PSB in that month, the total amount ofplanned hours for those tasks and the amount of unfinishedwork at the end of the sprint. Subsequently, the tableshows the average amount of hours per task, the averageworkload per person expressed in amount of tasks and theaverage workload per person expressed in hours. The finalcolumn shows an effectivity-score, obtained by calculatingthe reduction in hours assigned to all the tasks. The bottomthree rows show statistics about the lowest, the highest andthe average score for all items.

Furthermore, we have checked the backlogs for anyanomalies. Any anomalies we found were either removedfrom the dataset, or further analyzed based on the informa-tion received from the CTO at FacComp. We then groupedthe backlog items according to their characteristics. Thesegroups have been checked with the chief technology officer,to make sure that they were correct.

Over the two years of experience, the PSBs provideinformation regarding the number of tasks and their charac-teristics. The PSBs provide insight into two years’ evolutionof the number of tasks and their characteristics. First, severalrecurring, standard backlog items can be identified. Second,the evolution and introduction of the requirements refinerycan be followed from the first introduction of themes,concepts and requirement definitions. The abstraction levelsof the refinery (i.e. themes, concepts and requirement def-initions) make large requirements more manageable in an

# Period # Tasks # Hours Start # Hours End Avg Hours per Task Avg Tasks per Person Avg Hours per Person Efficiency1 2007-03 45 449 154 10.0 9.0 89.8 65.7%2 2007-04 57 513 177 9.0 11.4 102.6 65.5%3 2007-05 56 527 147 9.4 11.2 105.4 72.1%4 2007-06 57 539 102 9.5 11.4 107.8 81.1%5 2007-07 112 409 179 3.7 22.4 81.8 56.2%6 2007-08 95 574 301 6.0 19.0 114.8 47.6%7 2007-09 81 550 215 6.8 16.2 110.0 60.9%8 2007-10 58 750 274 12.9 11.6 150.0 63.5%9 2007-11 53 544 188 10.3 10.6 108.8 65.4%10 2007-12 43 324 142 7.5 7.2 54.0 56.2%11 2008-01 60 648 193 10.8 10.0 108.0 70.2%12 2008-02 67 497 226 7.4 11.2 82.8 54.5%13 2008-03 65 604 250 9.3 10.8 100.7 58.6%14 2008-04 84 669 320 8.0 14.0 111.5 52.2%15 2008-05 100 619 248 6.2 16.7 103.2 59.9%16 2008-06 121 586 198 4.8 20.2 97.7 66.2%17 2008-07 85 530 208 6.2 14.2 88.3 60.8%18 2008-08 91 443 197 4.9 15.2 73.8 55.5%19 2008-09 82 523 176 6.4 13.7 87.2 66.3%20 2008-10 81 543 116 6.7 13.5 90.5 78.6%21 2008-11 91 455 129 5.0 15.2 75.8 71.6%

Avg 75.4 537.9 197.1 7.7 13.5 97.4 63.3%Lowest 43.0 324.0 102.0 3.7 7.2 54.0 47.6%Highest 121.0 750.0 320.0 12.9 22.4 150.0 81.1%

Table IRESULTS OF THE PSB ANALYSIS

agile environment. To illustrate, two themes will be trackedthrough the entire SPM process.

A. Standard Backlog Items

From the PSB, several standard recurring backlog itemscan be identified. The standard items, as opposed to inci-dental tasks, form a base structure of recurring tasks, mostlywith the same amount of hours allocated each sprint. Thesetasks can be used to create a form of rhythm within theteam(s).

At the case company, the list of standard backlog itemshas evolved during the reported period from a disorganizedlist into a stable list of tasks, shown in table II. On thelefthand side, all standard backlog items related to the SPMsprint are shown. On the righthand side, all standard backlogitems related to the development sprint are shown. All tasksare performed by the SPM team(s).

As described earlier, the PSBs were at first mainly struc-tured in a product-focused manner. As a result, recurringbacklog items were spread across the PSB, resulting in adisorganized list which had to be recreated from scratch

Standard SPM Backlog Items Development Sprint PreparationsPrepare and Attend Product Board Backlog PreparationsSprint Review Sprint Planning with Dev. TeamsTeam Retro Meeting Sprint Review with Dev. TeamsTeam Allocation Overview How-to-demo StoriesProblem and Change Management Several Product Related TasksRelease Plan

Table IISTANDARD BACKLOG ITEMS ON THE PSB

every month. As of month five, a small list of recurringbacklog items related to the product board is distinguished.However, this is comprised of only ninety hours. This listgrows to a set of five different tasks (of which some occurmultiple times, once for each product manager), with atotal amount of 268 planned hours. This list stays relativelystable until month fifteen, in which the new PSB structureis introduced. At that moment, the list of standard backlogitems is reduced to two tasks with a total amount of 72hours. Remarkable is the steady growth of this list in thenext six months, after which the list of standard backlogitems consists of six different tasks, similar to the tasks ofthe earlier months, totaling only 80 hours. The final list ofstandard backlog items is shown on the lefthand side oftable II.

The low amount of planned hours can be explained bytaking into account the introduction of SCRUM principles.At the same time as the introduction of the new PSBstructure, a new group of tasks has been introduced on thelist, containing all the tasks related to the management of theupcoming development sprint. Although the exact contentsof the group differ every sprint, a large share of the tasks isrecurring and thus added to the righthand side of table II.

B. Themes, Concepts & Requirements

The introduction of the requirements refinery, describedin section II-C, was not performed in one step. Although theterm concept is found on the PSB as of month 2, themesare introduced for the first time in month 15. Regarding theconcepts, several interesting notes can be made. The PSBsshow a clear evolution in the use of the term. In the first fewmonths, the sub-list ’concepts’ contains an aggregation of

tasks related to concept-elaboration in general. As of monthfive, tasks within the concepts-list are grouped accordingto the specific concept that they belong to, thus providingan early indication of the corresponding theme. Furtherelaboration of product features is displayed under a products-list within the PSB.

The switch to the requirements refinery in month 15 hasclear effects on the backlog. Most notable is the immediatestructure and clarity that is created by this change. Bydividing the tasks related to the elaboration of requirementsinto lists named ’theme definition’, ’concept definition’ and’requirement elaboration, a clearer overview of the workloadis obtained. For every task it becomes instantly clear in whatphase of elaboration the requirement currently is.

Another consequence of the approach can be seen intwo trends in the evolution of task size and amount. Onthe one hand, the amount of tasks on the PSBs increasedapproximately twofold, whereas the average size of thetasks decreased with approximately 50%. Evidence on thePSBs suggests a relation with the introduction of themesand concepts on the PSB, as larger tasks such as ’describerequirements’ are now split into smaller tasks, specific tothe current stage.

C. Illustration: Maintenance Planning

To illustrate the specific workings of themes, conceptsand requirements within the PSB, the maintenance planningtheme is followed throughout its evolvement. The themewas introduced in 2008, when the case company chose toachieve a redefinition of its existing maintenance manage-ment solutions. The theme describes functionality related tothe maintenance of facilities, and was initially introduced onthe PB in month fourteen of the analysis. The entire SPMlifecycle of the theme lasts seven months.

Although the theme elaboration has not been documentedin the PSBs, the theme is elaborated into several concepts.These concepts are ’planned maintenance (PM)’, ’plannedpreventative maintenance (PPM)’ and ’maintenance man-agement (MM)’. Besides these, several other concepts existthat fall partially within this theme, such as ’work orders’and ’asset’. Each of these concepts is described in severaldocuments, of which the ’vision, scope & requirements’document is the most detailed. Within the theme, a focaltransition is visible from ’planned preventative maintenance’to ’planned maintenance’. Furthermore, ’maintenance man-agement’ is introduced in a later stage. For this example,the focus lies on the concepts of ’planned maintenance’ and’maintenance management’.

The ’planned maintenance’ concept was introduced inmonth fourteen, right before the introduction of the newPSB structure. The PB shows that the concept of ’plannedmaintenance’ was elaborated into 152 requirements, sub-divided over the groups ’no value’, ’contract’, ’generic’and ’maintenance planning’. Although a theme-section was

not yet available in the PSB of that month, it is clearfrom the task-descriptions that they are related to theme-level requirements. During the next five months, the tasksrelated to the theme should shift from theme-level towardsrequirements-level. However, the PSB shows that ’plannedmaintenance’ tasks are placed under the requirements sectionright away. These tasks are concerned with the detailedelaboration of requirements, and would thus be expectedlater in the process.

This is slightly different for the initial tasks related to’maintenance management’ (i.e. the other concept withinthe ’maintenance planning’ theme). The tasks related to theconcept can be found on the PSBs for the first time in monthfifteen of our analysis, at the same time as the introductionof the new PSB structure, and for the last time in monthtwenty. These tasks are, similar to ’planned maintenance’tasks, initially placed on the theme-level. As the conceptmatures, task-focus moves towards the concept-level andfinally towards requirements elaboration, analogous to the’theme/concept/requirements’ lifecycle.

D. Illustration: Planon Lite

As shown in the previous section, the introduction ofthemes, concepts and requirements on the PB does notnecessarily mean that all ideas brought up within the com-pany follow the same, complete track through all phases.Although it is recommended to do so with large, complicatedthemes, the previous section has shown that it is possible andperhaps more efficient to take a ’shortcut’.

At the same time, introducing a more fine-grained notationalso does not mean that every theme or concept will make itthrough all the steps of the requirements refinery. In fact, theadded detail allows for an increased visibility of theme lifecycles, which can result in the deletion of certain themesor concepts from the backlog. As an example of this, wedescribe the lifecycle of a new product idea, coined withinthe company in the fifth month of the analysis. This concept,called Planon Light, aimed at providing smaller companieswith facility management services. The concept started outas an idea with a set of tasks related to the elaboration of thevision. After this vision was created, it was discussed andrevised. It then had to be reviewed by the CIO. However,as the priority of this task was not high, it remained on thePSB for several months. Only in month eleven is the taskcompleted, after which the Planon Light concept disappearsfrom the backlog, indicating a rejection of the concept.

This example shows two important points. Firstly, itshows that not all features start out at the theme-level.As indicated before, only complex features are consideredthemes, whereas smaller features can be directly translatedto concepts or requirements. Secondly, the fact that taskskeep recurring on the backlog indicates that basic SCRUMprinciples can be successfully translated to the productenvironment process, adding more clarity and structure.

V. LESSONS LEARNED

During its attempts to implement an agile SPM method,our case company has gained valuable experiences in thisarea. These experiences, which have mostly been mentionedin the previous sections, are listed in this section as a set oflessons that should be taken into account when implementingagile SPM alongside an agile software development method.

• Alternating cycles for SPM and Development – Oneof the main lessons learned has been the importance ofthe alternating sprints. As discussed in section II-E, thesoftware development and the SPM sprint are both per-formed continuously, but with a difference in startingdate of approximately half of the sprint duration. Thisimplies that each SPM sprint ends halfway the softwaredevelopment sprint, ensuring that the PB is ready to beused when the development teams start their new sprint.

• Daily SCRUM meetings are essential – The dailystand-ups, or SCRUM meetings, that are essentialwithin the SCRUM development method, are also val-ued highly within the agile SPM method. The fifteen-minute meeting at the start of each day is experiencedas a positive, helpful aspect of the process. By pro-viding constructive critique, potential problems can beavoided and existing problems can be solved.

• Large requirements are in need of structured detail-ing – The essence lies in the division of requirementsinto themes, concepts and requirements. The structuredagile requirements refinery approach has made it pos-sible to effectively manage large sets of requirementsof different granularity. Both high level and low levelrequirements are placed on the PB and handled in timeby the appropriate person.

• Backlog administration requires discipline – Wehave seen that strict documentation of all tasks on thePSB is still difficult to achieve. Although the PSB canplay a useful role in controlling the SPM process andkeeping track of the progress of a sprint, the motivationto keep the current set of tasks and the amount oftime spent on a specific task up-to-date is still lacking.However, it should be noted that one of the agileprinciples is a favoring of individuals and interactionsover processes and tools. This means that, as long asthe work gets done, project administration becomes lessimportant.

• Early collaboration promotes reuse and integration– Since product managers in a SCRUM team coopera-tively work on a PSB and discuss requirements beforethey have been implemented, re-use and integrationopportunities can be spotted at an early stage. Wesuspect that higher quality software products are builtusing this approach than other approaches with lesscommunication during the requirements specificationprocess.

VI. VALIDITY THREATS

In order to ensure the quality of our work, we have triedto adhere to four validity criteria for empirical research.The validity threats are construct, internal, external, andreliability threats [22], [24]. Construct validity refers to theproper definition of the concepts used within the study. Forthis study, well established concepts were used to constructtheories. These theories were established in a discussionsession at the beginning of the project. Since well-knownconcepts were used to describe novel phenomena, constructvalidity is guarded. Furthermore, peer review was usedto check whether the constructs were used correctly. Theinternal validity, which concerns relations between concepts,was threatened by incorrect facts and incorrect results fromthe different sources of information. Interviews were heldwith several people in order to cross-check documentationfound and to confirm facts stated in other interviews.

With respect to external validity, concerning the abilityto generalize the results, a threat is that this case is notrepresentative for other software producers working withSCRUM. FacComp is a standard product software sup-plier, which deals with a lot of new requirements. Thepractices described in this paper can be a successful wayto manage teams of product managers for similar sizedsoftware vendors working with SCRUM. Finally, to defendreliability, similar results would be gathered if the case studywas redone if the circumstances are at least similar (sameinterviewees, same documents, etc), due to the use of a casestudy protocol, structured interviews, and a peer-reviewedresearch process [24].

VII. CONCLUSIONS AND OUTLOOK

Up until now, no attempts to apply agile principles tothe SPM process had been described in literature. Thispaper demonstrates such a method, based on the provenstructures of a well-adopted agile development method. Byproviding the lessons that have been learned during thisprocess, it is our hope that other companies can benefitfrom the experience of the case study company and thatother researchers can apply and measure the effects of therequirements refinery.

In the description of the SCRUM development methodwe have shown that an agile development process impliesan environment that is dynamic and to which it is constantlyadapting, be it in a controlled, effective way. It is not hardto imagine that such a dynamic development environmentrequires an SPM process that is adequately adapted to this.The effect of this is an increased demand for agile SPMprocesses, of which one has been described in this work.The main contribution of this work has been the descriptionof an innovative SPM process based on agile principles. Thetextual description along with process-deliverable diagramsboth for the software development as well as the SPMprocesses allows effective reuse of the described method

in other companies that find themselves in a comparablesituation.

The experiences of the case study company have shownthat, to ensure effective agile SPM, several factors should betaken into account, such as task size, backlog structure andwillingness to keep the backlog up-to-date. By providingthe specific lessons that FacComp has learned during itsexperience with agile SPM and SCRUM, we allow com-panies that wish to implement agile SPM to circumventpotential problems related to these items. However, as statedbefore, not a lot of research has been performed in the areaof agile SPM. Future research should be aimed at furtherelaboration and formalization of the requirements of agileSPM processes. Part of this consists of further analysisof the tasks that are relevant to an agile SPM process.Besides this, more insight should be gained regarding thesuitability of development methods for the application ofagile SPM. More information should be gathered regardingcurrent implementations of agile SPM processes, and theirintegration with agile development.

ACKNOWLEDGEMENTS

We would like to thank Planon for sharing its experiences,and for providing us with all required documents. Also, wewould like to thank Jaap Kabbedijk for his input duringthe writing of this paper and Tjan-Hien Cheng for hiscontribution to the work.

REFERENCES

[1] P. Abrahamsson, J. Warsta, M. T. Siponen, and J. Ronkainen,“New directions on agile methods: A comparative analysis,”Proceedings of the International Conference on SoftwareEngineering, vol. May, p. 244, 2003.

[2] J. Stapleton, “Dsdm: Dynamic systems development method,”in Proceedings of Technology of Object-Oriented Languagesand Systems, 1999.

[3] K. Beck, Extreme programming explained: embrace change.Boston, USA: Addison-Wesley Longman Publishing Co.,Inc., 1999.

[4] S. Palmer and J. Felsing, A Practical Guide to Feature-DrivenDevelopment. Prentice Hall, 2002.

[5] K. Schwaber, “Scrum development proces,” in Proceedingsof the Conference on Object-Oriented Programing Systems,Languages, and Applications Workshop on Business ObjectDesign and Implementation, 1995. [Online]. Available:http://jeffsutherland.com/oopsla/schwapub.pdf

[6] “Agile manifesto.” [Online]. Available:http://www.agilemanifesto.org

[7] T. Dingsoyr, G. K. Hanssen, T. Dyba, G. Anker, and J. O.Nygaard, Lecture Notes in Computer Science. SpringerBerlin / Heidelberg, 2006, ch. Developing Software withScrum in a Small Cross-Organizational Project, pp. 5–15.

[8] B. Fitzgerald, G. Hartnett, and K. Conboy, “Customising agilemethods to software practices at intel shannon,” EuropeanJournal of Information Systems, vol. 15, pp. 200–213, 2006.

[9] C. Mann and F. Mauer, “A case study on the impact of scrumon overtime and customer satisfaction,” in Agile DevelopmentConference, 2005.

[10] A. Danait, “Agile offshore techniques - a case study,” in AgileConference, 2005.

[11] I. van de Weerd, S. Brinkkemper, R. Nieuwenhuis,J. Versendaal, and L. Bijlsma, “Towards a reference frame-work for software product management,” in 14th IEEE Inter-national Requirements Engineering Conference, 2006.

[12] L. Gorchel, The Product Managers Handbook: The CompleteProduct Management Resource (2nd edition). NTC BusinessBooks, 2000.

[13] P. Carlshamre and B. Regnell, “Requirements lifecycle man-agement and release planning in market-driven requirementsengineering processes,” in Workshop on Database and ExpertSystems Applications, 2000.

[14] P. Carlshamre, K. Sandahl, M. Lindvall, B. Regnell, andJ. N. och Dag, “An industrial survey of requirements inter-dependencies in software product release planning,” in FifthIEEE International Symposium on Requirements Engineering,2001.

[15] D. Greer and G. Ruhe, “Software release planning: an evo-lutionary and iterative approach,” Information and SoftwareTechnology, vol. 46, no. 4, pp. 243–253, 2004.

[16] P. Berander, Evolving Prioritization for Software ProductManagement, ser. Blekinge Institute of Technology DoctoralDissertation Series. Blekinge Institute of Technology, 2007.

[17] B. Regnell, M. Host, J. N. och Dag, P. Beremark, andT. Hjelm, “An industrial case study on distributed prioritisa-tion in market-driven requirements engineering for packagedsoftware,” Requirements Engineering, vol. 6, no. 1, pp. 51–62, 2001.

[18] M. Pichler, H. Rumetshofer, and W. Wahler, “Agile require-ments engineering for a social insurance for occupationalrisks organization: A case study,” in 14th IEEE InternationalRequirements Engineering Conference, 2006.

[19] M. Pittman, “Lessons learned in managing object-orienteddevelopment,” IEEE Software, vol. 10, no. 1, pp. 43–53, 1996.

[20] G. Booch, Object Solutions: Managing the Object-OrientedProject. Addison-Wesley, 1995.

[21] I. van de Weerd and S. Brinkkemper, Handbook of Researchon Modern Systems Analysis and Design Technologies andApplications. Hershey: Idea Group Publishing, 2008, ch.Meta-modeling for situational analysis and design methods,pp. 38–58.

[22] R. K. Yin, Case Study Research - Design and Methods.SAGE Publications, 2003.

[23] J. Robertson and S. Robertson, “Volere requirements speci-fication template edition 6.0,” Atlantic Systems Guild, Tech.Rep., 1998.

[24] S. Jansen and S. Brinkkemper, Information Systems ResearchMethods, Epistemology, and Applications. Idea GroupInc, 2008, ch. Applied Multi-Case Research in a Mixed-Method Research Project: Customer Configuration UpdatingImprovement, pp. 120–139.