A Metamodel for Modeling and Measuring

Scrum Development Process

Ernesto Damiani1, Alberto Colombo1, Fulvio Frati1, and Carlo Bellettini2

1Department of Information Technology, University of Milan2Department of Information Science, University of Milan

{colombo,damiani,frati}@dti.unimi.itcarlo.bellettini@unimi.it

Abstract. Many organizations using agile processes would like to adopta process measurement framework, e.g. for assessing their process ma-turity. In this paper we propose a meta-model supporting derivation ofspecific data models for agile development processes. Then, we show howour meta-model can be used to derive a model of the Scrum process.

Keywords: Software development process, Scrum, MOF, meta-model.

1 Introduction

Software Process Management (SPM) is aimed at controlling and managing allthe resources involved in software production. Four core SPM responsibilitiescan be defined [6]:

– Process Definition, including the creation of the environment required forcontrolling the process;

– Process Measurement, including all measurement activities needed to detectdeviations from the process expected performance or behavior;

– Process Control, including all actions taken to control the process behavior;– Process Improvement, including all changes to the process that can improve

its capabilities and performance.

In this paper, we focus on the first two responsibilities, describing i) a genericenvironment for modeling agile development processes, and ii) a generic mea-surement framework, that can be applied to any process instantiated in theenvironment.

As an application, we describe a roadmap to achieve the formalization of theagile development process Scrum using the OMG Meta-Object Facility (MOF).The paper is organized as follows. Section 2 discusses some related works aboutdevelopment process measuring and modeling. Then, Section 3 describes ourmeta-model and the related measurement framework, while Section 4 uses theproposed schema to model the agile process Scrum, showing how a measurementframework can be applied to Scrum. Finally, Section 5 presents our conclusions.

G. Concas et al. (Eds.): XP 2007, LNCS 4536, pp. 74–83, 2007.c© Springer-Verlag Berlin Heidelberg 2007

A Metamodel for Modeling and Measuring Scrum Development Process 75

2 Related Work

The idea of a meta-model for the development process is well established inliterature. Seminal work by Mi and Scacchi [7] defined meta-modeling as “aconstructing and refining a process concept vocabulary and logic for repre-senting families of processes and process instances in terms of object classes,attributes, relations, constraints, control flow, rules, and computational meth-ods”. Mi and Scacchi’s meta-model was developed for representing generic knowl-edge about the software process. Other approaches, like the SD packages, werespecifically aimed at representing statistical or numerical information. The latterapproaches have given rise to sophisticated, performance-related process analy-sis tools (see http://www.intelsystech.com/), while generic process meta-modelshave targeted extensibility, relying on process vocabularies represented asontologies [10].

More recently, a need for standardizing process descriptions in order to sup-port interchange and fusion of process data emerged. Piattini et al. [9] describedthe advantages of using Object Management Group’s standard Meta Object Fa-cility (MOF) to represent software processes. MOF (Meta-Object Facility) is astandard supported by OMG [8]: it defines a generic pattern for the constructionof systems based on metadata.

Conceptually, MOF can be described as a layered structure composed of fourlevels: at the top there is i) the definition of all the concepts and attributes ofthe MOF language itself, which is used to build ii) meta-models, which definethe structure and semantic of the metadata describing a generic environment;then, meta-models are used to create iii) models, that depict specific objectsand describes the structure (e.g., the relational schema) for iv) representing andstoring the user data.

Recent work by Ventura Martins et al. [13] presents the ProjectIT initiative,including a complete software development workbench and an example of devel-opment process meta-model.

All these approaches are based on the MOF-based SPEM (Software ProcessEngineering Meta-model) specification [12] proposed by OMG to describe a con-crete software development process or a family of related software developmentprocesses. While in this paper we focus on applying the meta-model notion toagile processes, a general, detailed description of our own SPEM-based proposalfor a measurement framework and of a set of metrics for the assessment of ageneric software process is reported in [5].

3 Process Development and Measurement Meta-Model

In this Section we show how MOF is used to define two meta-models: one usedto generate models for describing the development process and the other used togenerate models for describing a measurement framework. Again at the meta-model level, we also define a simple trigger layer that connect the two meta-models.

76 E. Damiani et al.

Fig. 1. Development Process Meta-model

3.1 Development Process Meta-Model

The meta-model that describes the development process has been designed to beas generic as possible. We took SPEM [12] as a basis of our work and simplifiedit by considering only meta-classes that can be interesting for measurementpurposes.

To facilitate meta-model description, Fig. 1 contains a graphical representa-tion of our process meta-model, where the boxes depict meta-classes, and archesindicate relations. The top element of the meta-model is the class1 Organization,that gathers all the Project nodes and supports enterprise-wide analyses acrossprojects. The class Project represents a single project of an organization; eachproject is associated to a specific development process, that is defined as a setof phases.

A development process is presented as a non-empty set of Phase classes. Eachphase can be linked to another phase, to allow iterations in the developmentprocess, and is composed by a series of Activity classes; depending on the level1 Note that, for the sake of simplicity, in the remainder of the paper, the terms class,

entity, and node are used in place of meta-class to denote meta-model elements.

A Metamodel for Modeling and Measuring Scrum Development Process 77

of granularity chosen, each activity could be itself decomposed in Task or Sub-activity. Here, for the sake of conciseness, we limit our description to activityclasses.

Further, each activity is in relation (many-to-many) with the following classes:

– Workproduct, that represents the set of workproducts the activities are ex-pected to produce

– Role, that defines the roles that cooperate to carry out a specified activityand produce a set of workproducts;

– Tool, that indicates the tools required to use and produce workproductswithin activities.

3.2 Measurement Framework Meta-Model

The measurement meta-model, depicted in Fig. 2, is based on the Goal/Quest-ion/Metric paradigm (GQM) [1] that establishes a mechanism for defining andinterpreting software measurements. In particular, the GQM approach requires

Fig. 2. Measurement Framework Meta-model

78 E. Damiani et al.

organizations to specify the goals for their projects, and traces these goals to thedata that are intended to define these goals operationally, providing a frameworkto interpret the data and understand the goals.

Specifically, our measurement meta-model is defined as a skeletal genericframework exploitable to get measures from any development process.

The InformationNeed node is the container node that identifies the informa-tion need over which all the measuring actions are based, as for instance aninternal process assessment. This node is used as a conceptual link between thetwo meta-models.

Following the GQM paradigm, the measurableConcept class defines the areasover which the analysis is based; examples of measurableConcept data instancescould be “Software Reuse” or “Software Quality”, indicating as goals an assess-ment of software reuse and software quality level within the organization.

The measurableAttributes node defines which attributes have to be measuredin order to accomplish the analysis goals. Furthermore, this element specifiesthe way how attribute values could be collected: indeed, there a strict relationbetween workProduct and measurableAttribute classes.

The measure class defines the structure of measurement values observed dur-ing a measurement campaign. Measure is strictly related to unit and scaleTypeclasses, that define, respectively, the unit of measurement used and the typeof scale adopted (nominal, ordinal, and so forth). In particular, measure is inrelation with the metric class, that defines conditioning and pre-processing ofmeasurements in order to provide meaningful indicators. Finally, the metric classis in relation with the threshold node that specifies the threshold values for eachmetric when needed for qualitative evaluation.

3.3 Trigger Meta-Model

The trigger meta-model defines a skeletal middle layer that connects develop-ment process and measurement framework meta-models, factoring out entitiesthat model application of measures to attributes. Fig. 3 shows the trigger meta-model and its relation with the other two meta-models.

The trigger meta-model is composed of two entities: trigger and triggerData.Trigger is the class that represents a specific question, component, or probe

that evaluates a specific attribute in a given moment of the development process.Indeed, trigger is related to the measurableAttribute class in order to specifywhich attributes are to be measured, and with organization, project, phase, andactivity classes to indicate the organizational coordinates where attributes haveto be measured.

Finally, the triggerData class identifies a single result of a measurement ac-tion performed by a trigger instance. There is a slight but important differencebetween data represented by triggerData and raw measures: measure instancessupply triggerData values to metrics applying, whenever necessary, suitable ag-gregations to reduce the cardinality of triggerData result set.

A Metamodel for Modeling and Measuring Scrum Development Process 79

Fig. 3. Trigger Meta-model

4 Scrum Model

In this section we use our software process meta-model to model an agile processand couple it with measurement framework. As a proof-of-concept, we shall focuson the Scrum development process [2,4]. A major difference between traditionaldevelopment processes and empirical ones like Scrum is that analysis, design, anddevelopment activities during a Scrum process are intrinsically unpredictable;however, a distributed control mechanism is used to manage unpredictabilityand to guarantee flexibility, responsiveness, and reliability of the results. At firstsight, it may seem that Scrum’s unpredictability could make it difficult to use ameasurement framework to assess a Scrum process. However, we shall see thatour meta-model seamlessly superimposes a measurement framework to Scrumactivities.

4.1 The Scrum Development Process

In the following sections we propose an instance of our development processmeta-model based on Scrum, defining phases, activities, and workproducts ofit. Our description of Scrum is based on the work of Schwaber [11] that clearlydefines Scrum phases and workproducts and gives guidelines for defining itsactivities.

Phases and Activities. The Scrum process is composed by the following fivephases (see Fig. 4):

1. Planning, whose main tasks are the preparation of a comprehensive Backloglist (see Section 4.1), the definition of delivering dates, the assessment of therisk, the definition of project teams, and the estimation of the costs. For thisphase, none activity has been formalized; to maintain coherence with theproposed meta-model, we define a generic planningActivity.

80 E. Damiani et al.

Fig. 4. Scrum model

2. Architecture, that includes the designing of the structure of Backlog itemsand the definition and design of the system structure; also for this phase wehave instanced a generic architectureActivity.

3. Sprint, that is a set of development activities conducted over a predefinedperiod, in the course of the risk is assessed continuously and adequate riskcontrols and responses put in place. Each Sprint phase consists of one ormore teams performing the following activities:

A Metamodel for Modeling and Measuring Scrum Development Process 81

– Develop: that defines all the development actions needed to implementBacklog requirements into packets, performing changes, adding new fea-tures or fixings old bugs, and documenting the changes;

– Wrap: that consists in closing the modified packets and creating an ex-ecutable version of them showing the implementation of requirements;

– Review: that includes a review of the release by team members, whichraise and resolve issues and problems, and add new Backlog items to theBacklog list;

– Adjust: that permits to consolidate in modified packets all the informa-tion gathered during Sprint meetings.

4. Sprint Review, that follows each Sprint phase, whereby it is defined an iter-ation within the Scrum process. Recent literature [11] identified a series ofactivities also for the Sprint Review phase:– Software Reviewing: the whole team, product management and, possibly,

customers jointly review the executable provided by the developers teamand occurred changes;

– Backlog Comparing: the implementation of Backlog requirements in theproduct is verified;

– Backlog Editing: the review activities described above yield to the for-malization of new Backlog items that are inserted into the Backlog list;

– Backlog Items Assigning: new Backlog items are assigned to developersteams, changing the content and direction of deliverables;

– Next Review Planning: the time of the next review is defined based onthe progress and the complexity of the work.

5. Closure, that occurs when the expected requirements have been implementedor the project manager “feels” that the product can be released. For thisphase, a generic closureActivity has been provided.

Workproducts. A typical Scrum work product is the Backlog, a prioritized listof Backlog Items [3] that defines the requirements that drive further work to beperformed on a product. The Backlog is a dynamic entity, constantly changedby management, and evolves as the product and its environment change. TheBacklog is accessed during all activities of process and modified only in duringReview and Backlog Editing.

Backlog Items define the structure and the changes to apply to the software.We identified as instances of our workproduct class the entities Release com-posed by a set of Packet that includes all the software components implemented.Fig. 5 shows an excerpt of the Scrum model showing relation with our activityand workproduct instances. It is important to note that each workproduct in-stance is characterized by a list of measured attributes that are themselfes in-stances of the measurableAttribute class of our measurement meta-model. Duringthe configuration of the data representation and storage environment, it is neces-sary to point out which attributes to measure and which workproducts considerin measuring these attributes.

82 E. Damiani et al.

Fig. 5. Relations with workproducts and activities

BACKLOGITEM(id, name, description, priority, category, version, state,

estimatedEffort)

BG-DEV(backlogItemID, developID)

DEVELOP(id, startDate, finishDate, sprintID)

SPRINT(id, startDate, finishDate)

PROJECT(id, name, description, startDate, finishDate)

Fig. 6. A database schema for Scrum data complying with our data model. The tableBG-DEV implements the many-to-many relation between the BACKLOGITEM andDEVELOP tables.

5 Conclusion

In this paper we have laid the basis for a framework to model a generic softwareprocess meta-model and related measures, and we propose an instance of themeta-model modeling the agile process Scrum, showing how the assessment ofsuch a process is possible without deranging the approach at the basis of thismethodology. It is important to remark that the data model we generated forScrum supports creating and maintaining Scrum process data, e.g. using a rela-tional database. A sample set of tables complying to the model are shown in Fig. 6.

Having been generated from our standard meta-model, the Scrum model canbe easily connected to similar models generated for different agile processeslike XP, supporting enterprise-wide measurement campaigns in organizationsthat adopt multiple agile methodologies. We shall explore this issue in a futurepaper.

A Metamodel for Modeling and Measuring Scrum Development Process 83

Acknowledgments

This work was partly founded by the Italian Ministry of Research under FIRBcontracts n. RBNE05FKZ2 004 TEKNE and n. RBNE01JRK8 003 MAPS.

References

1. Basili, V.R.: Software Modeling and Measurement: The Goal Question MetricParadigm. Computer Science Technical Report Series, CS-TR-2956 (UMIACS-TR-92-96), University of Maryland, College Park, MD (1992)

2. Beedle, M., Schwaber, K.: Agile Software Development with SCRUM. PrenticeHall, Englewood Cliffs (2001)

3. Beedle, M., Devos, M., Sharon, Y., Schwaber, K., Sutherland, J.: SCRUM: AnExtension Pattern Language for Hyperproductive Software Development. In: Har-rison, N., Foote, B., Rohnert, H. (eds.) Pattern Languages of Program Design 4,pp. 637–651. Addison-Wesley, Reading, MA (2000)

4. Cockburn, A.: Agile Software Development. Addison-Wesley, London, UK (2001)5. Colombo, A., Damiani, E., and Frati, F.: Processo di Sviluppo Software e Metriche

Correlate: Metamodello dei Dati e Architettura di Analisi. Nota del Polo - Ricercan. 101, Italy (available in italian only) (February 2007)

6. Florac, W.A., Carleton, A.D.: Measuring the Software Process: statistical processcontrol for software process improvement. Addison-Wesley Professional, Boston,USA (1999)

7. Mi, P., Scacchi, W.: A Meta-Model for Formulating Knowledge-Based Models ofSoftware Development. Special issue: Decision Support Systems 17(4), 313–330(1996)

8. OMG Meta Object Facility (MOF) Home Page (2006) www.omg.org/mof/

9. Ruız, F., Vizcaıno, A., Garcıa, F., Piattini, M.: Using XMI and MOF for Repre-sentation and Interchange of Software Processes. In: Proc. of 14th InternationalWorkshop on Database and Expert Systems Applications (DEXA’03), Prague,Czech Republic (2003)

10. Scacchi, W., Noll, J.: Process-Driven Intranets: Life-Cycle Support for ProcessReengineering. IEEE Internet Computing 1(5), 42–49 (1997)

11. Schwaber, K.: SCRUM Development Process. In: Proc. of OOPSLA’95 Workshopon Business Object Design and Implementation, Austin, TX (1995)

12. SPEM Software Process Engineering Metamodel (2006)www.omg.org/technology/documents/formal/spem.htm

13. P. Ventura Martins, A.R. da Silva.: PIT-P2M: ProjectIT Process and Project Meta-model. In: Proc. of OTM Workshops, Cyprus, pp. 516–525 (October 31-November4, 2005)