A Metamodel for Modeling and Measuring Scrum Development Process

A Metamodel for Modeling and Measuring Scrum Development Process Ernesto Damiani1 , Alberto Colombo1 , Fulvio Frati1 , and Carlo Bellettini2 1

Department of Information Technology, University of Milan 2 Department of Information Science, University of Milan {colombo,damiani,frati}@dti.unimi.it [email protected]

Abstract. Many organizations using agile processes would like to adopt a process measurement framework, e.g. for assessing their process maturity. In this paper we propose a meta-model supporting derivation of specific data models for agile development processes. Then, we show how our 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 all the resources involved in software production. Four core SPM responsibilities can be defined [6]: – Process Definition, including the creation of the environment required for controlling the process; – Process Measurement, including all measurement activities needed to detect deviations 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 generic environment for modeling agile development processes, and ii) a generic measurement framework, that can be applied to any process instantiated in the environment. As an application, we describe a roadmap to achieve the formalization of the agile development process Scrum using the OMG Meta-Object Facility (MOF). The paper is organized as follows. Section 2 discusses some related works about development process measuring and modeling. Then, Section 3 describes our meta-model and the related measurement framework, while Section 4 uses the proposed schema to model the agile process Scrum, showing how a measurement framework 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

2

75

Related Work

The idea of a meta-model for the development process is well established in literature. Seminal work by Mi and Scacchi [7] defined meta-modeling as “a constructing and refining a process concept vocabulary and logic for representing families of processes and process instances in terms of object classes, attributes, relations, constraints, control flow, rules, and computational methods”. Mi and Scacchi’s meta-model was developed for representing generic knowledge about the software process. Other approaches, like the SD packages, were specifically aimed at representing statistical or numerical information. The latter approaches have given rise to sophisticated, performance-related process analysis tools (see http://www.intelsystech.com/), while generic process meta-models have targeted extensibility, relying on process vocabularies represented as ontologies [10]. More recently, a need for standardizing process descriptions in order to support interchange and fusion of process data emerged. Piattini et al. [9] described the advantages of using Object Management Group’s standard Meta Object Facility (MOF) to represent software processes. MOF (Meta-Object Facility) is a standard supported by OMG [8]: it defines a generic pattern for the construction of systems based on metadata. Conceptually, MOF can be described as a layered structure composed of four levels: at the top there is i) the definition of all the concepts and attributes of the MOF language itself, which is used to build ii) meta-models, which define the structure and semantic of the metadata describing a generic environment; then, meta-models are used to create iii) models, that depict specific objects and describes the structure (e.g., the relational schema) for iv) representing and storing 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 development process meta-model. All these approaches are based on the MOF-based SPEM (Software Process Engineering Meta-model) specification [12] proposed by OMG to describe a concrete software development process or a family of related software development processes. While in this paper we focus on applying the meta-model notion to agile processes, a general, detailed description of our own SPEM-based proposal for a measurement framework and of a set of metrics for the assessment of a generic 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 used to generate models for describing the development process and the other used to generate models for describing a measurement framework. Again at the metamodel level, we also define a simple trigger layer that connect the two metamodels.

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 be as generic as possible. We took SPEM [12] as a basis of our work and simplified it by considering only meta-classes that can be interesting for measurement purposes. To facilitate meta-model description, Fig. 1 contains a graphical representation of our process meta-model, where the boxes depict meta-classes, and arches indicate relations. The top element of the meta-model is the class1 Organization, that gathers all the Project nodes and supports enterprise-wide analyses across projects. The class Project represents a single project of an organization; each project is associated to a specific development process, that is defined as a set of phases. A development process is presented as a non-empty set of Phase classes. Each phase can be linked to another phase, to allow iterations in the development process, and is composed by a series of Activity classes; depending on the level 1

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.


77

of granularity chosen, each activity could be itself decomposed in Task or Subactivity. Here, for the sake of conciseness, we limit our description to activity classes. Further, each activity is in relation (many-to-many) with the following classes: – Workproduct, that represents the set of workproducts the activities are expected to produce – Role, that defines the roles that cooperate to carry out a specified activity and produce a set of workproducts; – Tool, that indicates the tools required to use and produce workproducts within activities.

3.2

Measurement Framework Meta-Model

The measurement meta-model, depicted in Fig. 2, is based on the Goal/Question/Metric paradigm (GQM) [1] that establishes a mechanism for defining and interpreting 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 the data that are intended to define these goals operationally, providing a framework to interpret the data and understand the goals. Specifically, our measurement meta-model is defined as a skeletal generic framework exploitable to get measures from any development process. The InformationNeed node is the container node that identifies the information need over which all the measuring actions are based, as for instance an internal process assessment. This node is used as a conceptual link between the two meta-models. Following the GQM paradigm, the measurableConcept class defines the areas over which the analysis is based; examples of measurableConcept data instances could be “Software Reuse” or “Software Quality”, indicating as goals an assessment of software reuse and software quality level within the organization. The measurableAttributes node defines which attributes have to be measured in order to accomplish the analysis goals. Furthermore, this element specifies the way how attribute values could be collected: indeed, there a strict relation between workProduct and measurableAttribute classes. The measure class defines the structure of measurement values observed during a measurement campaign. Measure is strictly related to unit and scaleType classes, that define, respectively, the unit of measurement used and the type of scale adopted (nominal, ordinal, and so forth). In particular, measure is in relation with the metric class, that defines conditioning and pre-processing of measurements in order to provide meaningful indicators. Finally, the metric class is in relation with the threshold node that specifies the threshold values for each metric when needed for qualitative evaluation. 3.3

Trigger Meta-Model

The trigger meta-model defines a skeletal middle layer that connects development process and measurement framework meta-models, factoring out entities that model application of measures to attributes. Fig. 3 shows the trigger metamodel 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 specify which attributes are to be measured, and with organization, project, phase, and activity classes to indicate the organizational coordinates where attributes have to be measured. Finally, the triggerData class identifies a single result of a measurement action performed by a trigger instance. There is a slight but important difference between data represented by triggerData and raw measures: measure instances supply triggerData values to metrics applying, whenever necessary, suitable aggregations to reduce the cardinality of triggerData result set.


79

Fig. 3. Trigger Meta-model

4

Scrum Model

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

The Scrum Development Process

In the following sections we propose an instance of our development process meta-model based on Scrum, defining phases, activities, and workproducts of it. Our description of Scrum is based on the work of Schwaber [11] that clearly defines Scrum phases and workproducts and gives guidelines for defining its activities. Phases and Activities. The Scrum process is composed by the following five phases (see Fig. 4): 1. Planning, whose main tasks are the preparation of a comprehensive Backlog list (see Section 4.1), the definition of delivering dates, the assessment of the risk, the definition of project teams, and the estimation of the costs. For this phase, none activity has been formalized; to maintain coherence with the proposed 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 items and the definition and design of the system structure; also for this phase we have instanced a generic architectureActivity. 3. Sprint, that is a set of development activities conducted over a predefined period, in the course of the risk is assessed continuously and adequate risk controls and responses put in place. Each Sprint phase consists of one or more teams performing the following activities:


81

– Develop: that defines all the development actions needed to implement Backlog requirements into packets, performing changes, adding new features or fixings old bugs, and documenting the changes; – Wrap: that consists in closing the modified packets and creating an executable version of them showing the implementation of requirements; – Review: that includes a review of the release by team members, which raise and resolve issues and problems, and add new Backlog items to the Backlog list; – Adjust: that permits to consolidate in modified packets all the information gathered during Sprint meetings. 4. Sprint Review, that follows each Sprint phase, whereby it is defined an iteration within the Scrum process. Recent literature [11] identified a series of activities also for the Sprint Review phase: – Software Reviewing: the whole team, product management and, possibly, customers jointly review the executable provided by the developers team and occurred changes; – Backlog Comparing: the implementation of Backlog requirements in the product is verified; – Backlog Editing: the review activities described above yield to the formalization of new Backlog items that are inserted into the Backlog list; – Backlog Items Assigning: new Backlog items are assigned to developers teams, changing the content and direction of deliverables; – Next Review Planning: the time of the next review is defined based on the progress and the complexity of the work. 5. Closure, that occurs when the expected requirements have been implemented or the project manager “feels” that the product can be released. For this phase, a generic closureActivity has been provided. Workproducts. A typical Scrum work product is the Backlog, a prioritized list of Backlog Items [3] that defines the requirements that drive further work to be performed on a product. The Backlog is a dynamic entity, constantly changed by management, and evolves as the product and its environment change. The Backlog is accessed during all activities of process and modified only in during Review 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 composed 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 activity and workproduct instances. It is important to note that each workproduct instance is characterized by a list of measured attributes that are themselfes instances of the measurableAttribute class of our measurement meta-model. During the configuration of the data representation and storage environment, it is necessary to point out which attributes to measure and which workproducts consider in 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 table BG-DEV implements the many-to-many relation between the BACKLOGITEM and DEVELOP tables.

5

Conclusion

In this paper we have laid the basis for a framework to model a generic software process meta-model and related measures, and we propose an instance of the meta-model modeling the agile process Scrum, showing how the assessment of such a process is possible without deranging the approach at the basis of this methodology. It is important to remark that the data model we generated for Scrum supports creating and maintaining Scrum process data, e.g. using a relational 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 can be easily connected to similar models generated for different agile processes like XP, supporting enterprise-wide measurement campaigns in organizations that adopt multiple agile methodologies. We shall explore this issue in a future paper.


83

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

References 1. Basili, V.R.: Software Modeling and Measurement: The Goal Question Metric Paradigm. Computer Science Technical Report Series, CS-TR-2956 (UMIACS-TR92-96), University of Maryland, College Park, MD (1992) 2. Beedle, M., Schwaber, K.: Agile Software Development with SCRUM. Prentice Hall, Englewood Cliffs (2001) 3. Beedle, M., Devos, M., Sharon, Y., Schwaber, K., Sutherland, J.: SCRUM: An Extension Pattern Language for Hyperproductive Software Development. In: Harrison, 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 - Ricerca n. 101, Italy (available in italian only) (February 2007) 6. Florac, W.A., Carleton, A.D.: Measuring the Software Process: statistical process control for software process improvement. Addison-Wesley Professional, Boston, USA (1999) 7. Mi, P., Scacchi, W.: A Meta-Model for Formulating Knowledge-Based Models of Software 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 Representation and Interchange of Software Processes. In: Proc. of 14th International Workshop on Database and Expert Systems Applications (DEXA’03), Prague, Czech Republic (2003) 10. Scacchi, W., Noll, J.: Process-Driven Intranets: Life-Cycle Support for Process Reengineering. IEEE Internet Computing 1(5), 42–49 (1997) 11. Schwaber, K.: SCRUM Development Process. In: Proc. of OOPSLA’95 Workshop on 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 Metamodel. In: Proc. of OTM Workshops, Cyprus, pp. 516–525 (October 31-November 4, 2005)