Introduction

The Scrum approach to development is best described as a method to manage, enhance and maintain an existing system or production prototype. Central to this approach is the assumption that systems development processes are of an unpredictable and complex nature, implying that the development process can only be generally described as a sequence of progressing phases. Scrum looks at systems development processes from a different perspective, namely that it regards these as a “loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems” (Schwaber, 1995).

Another assumption central to the Scrum method is that as the complexity of a system development process increases over time, the greater the need for maximum flexibility to adapt to external changes and appropriate controls will be. This desired level of flexibility can only be achieved through performing assessments of the project in a continuous manner, and to provide accurate responses to threats and risk in complex environments with rapidly changing circumstances (Schwaber, 1995). It is for this reason one of the primary goals of Scrum to facilitate a project team in achieving this desired flexibility, by placing emphasis on ‘control factors’. Examples are working in small teams and intensive collaboration contributing to shortened feedback cycles and optimal exchange of tacit knowledge, and frequent reviews with the development team to assess the efficiency and effectiveness of the development process – including an assessment of whether the demands of the customer are met (Schwaber, 1995).

Although several (primitive) predecessors of the Scrum development method can be found in existing literature in the domain of the manufacturing industry from the 1980s, it was not until 1995 when Schwaber and Sutherland (1995) presented a paper in which they comprehensively describe the Scrum method as it is known today. Their version of Scrum was primarily based on their practical and academic expertise, also taking the essence of earlier published work offering similar approaches to development into account (Sutherland & Schwaber, 1995).

When taking a closer look at the Scrum development method, it can be seen that the method consists of four general phases, of which each can be broken down into general follow-up activities (Schwaber, 1995). An overview containing the most prominent constituents of the Scrum method in order to provide a comprehensive overview of the different phases, deliverables and descriptions hereof, are described in Table 1.

Table 1 Overview of the general Scrum phases, descriptions and deliverables

Phase	Description	Deliverables
Project planning	A detailed planning is made of the project from a bird’s eye view. First a ‘product backlog’ is created, usually based on a prioritization of user stories and functional requirements. Afterwards, a ‘release plan’ is created based on specifically defined ‘release functionalities’ and ‘release dates’. ‘Risks’ are also identified, including estimating the ‘required development resources and budget’.	Product backlog, release plan, risk list, project plan
Architectural design	The architectural design phase consists of assessing the current ‘system architecture’ and ‘domain models’ to see whether it can support the new requirements as formulated in the release plan. In addition, ‘product standards’ may also be defined which the development team should adhere to.	Product standards, system architecture, domain model(s)
Release development	During release development, the Scrum team develops the functionalities as formulated in the release plan. As soon as all functionalities are developed, they are wrapped together in a ‘working executable version’. A comprehensive review is also conducted to make sure the developed version is free of errors.	Component source code(s), executable version
Release finalization	During the closure phase of Scrum, ‘release documentations’ are made, including ‘marketing and training materials’. All three deliverables are based on the developed working executable version.	Documentation, marketing material, training material

In addition to these various phases and activities, the Scrum method also places emphasis on the assignment of specific roles to project stakeholders. Various roles can be distinguished, and vary from project to project (Mahnic & Vrana, 2007). The most common roles that can be considered omnipresent in every Scrum development process are described in Table 2.

Table 2 Overview of most common roles in Scrum development processes

Role	Description
Scrum master	One person that can be seen as the ‘mini-CEO’ of a project, such as the project manager. The scrum master has the responsibility of making sure the development processes go according to plan. He or she also has to ensure that every relevant stakeholder follows the Scrum rules and practices that have been agreed upon before the start of the project.
Product owner	One person that is responsible for representing the interests of any stakeholder with regard to the development process and the final to-be delivered system. The product owner also manages and maintains the product backlog, which is a prioritized list of items (e.g. functionality requirements) that have to be turned into working deliverables.
Team	Stakeholders related to the development of the aforementioned backlog items, such as product functionalities. Teams are self-managing and organizing, and are cross-functional possessing knowledge of various topics related to development. The entire team carries the responsibility of making a success of each item to be developed from the ‘product backlog’ – a concept that will be further elaborated upon in section three.

Example

An example is provided in this section in order to get a clear view on what a systems development project would look like when the Scrum method is used. In this case, a fictional scenario is discussed where DevComp? is performing ongoing maintenance for a tailor-made Enterprise Resource Planning (ERP) system for a customer named CustComp? . Every typical development phase starting from the inception of ideas to working deliverables will be explained in a short, yet consolidated manner. A visual representation of the development process discussed is depicted in Figure 1. The steps described in the following sub-sections are in accordance with the phases and their respective deliverables as described in Table 1.

Figure 1 Visual representation of a Scrum development process (Original image by Trialox, 2010)

Project Planning

During the project planning phase, a detailed planning is made of the project by the product owner. In this simplified fictional scenario, four ‘requests’ are placed the ‘product backlog’ and ordered in the following way: an integrated transactional database (#3), a new management portal (#4), a new document management module (#5), and a new data-mining tool (#6) (see Figure 1: Product Backlog). Two requests have already been worked out, as can be seen in Figure 1: Working Increment of Software.

After the product backlog is created, the product owner then defines ‘release functionalities’ and ‘release dates’ to be incorporated in a ‘release plan’. The release plan contains in this case one request package from the product backlog, being the integrated transactional database (#3). Various other factors that need to be taken into account are also included in the release plan, such as time pressure and minimum quality levels. A template of such a release plan can be found here: Release Plan Template. It is important to note that we consider the term release plan analogous to the term sprint backlog, due to avoiding mixing up different levels of granularity.

The scrum master can start to form ‘project teams’ after the release plan has been formulated. Soon after this is done, potential threats, in this case ‘risks’, are identified by the product owner. These risks will all be assessed, analyzed, and prioritized by the product owner, resulting in an ordered ‘risk list’. This risk list is then input for the creation of a list containing activities that need to be undertaken in order to monitor the identified risks.

Finally, the product owner identifies and estimates the required development resources and budget, after which approval by higher management is requested for the new release plan. In this scenario the release plan is approved, meaning the project transitions towards the architectural design phase.

Architectural Design

After the project planning activities have been conducted, an assessment of the current ‘system architecture’ and ‘domain model(s)’ are performed by the entire team to make sure these are able to support the requirements as formulated in the release plan. In addition, ‘product standards’ are also identified. In this scenario, the system architecture and domain models are found to be capable of handling the new requirements, and one ‘product standard’ is identified, being the adherence to an open standard from the financial domain named XBRL (Extensible Business Reporting Language) for the integrated transactional database.

Release Development (Sprint)

After the architectural design phase, the project transitions towards the release development phase, also termed one or multiple sprints. During this phase, the formulated release plan is realized by the Scrum team during a set timeframe. The ‘project plan’ is first reviewed to ensure common ground among project participants, after which the development of individual ‘components’ may start. As soon as all the components have been developed they are wrapped together, leading to an ‘executable version of software’. In this scenario, CustComp? ’s existing system now has another request implemented: the integrated transactional database (#3). The updated executable version is comprehensively reviewed by the Scrum team to ensure the software is free of errors, which is the case in this scenario.

It should be mentioned that Scrum teams have short meetings each day to discuss the progress and e.g. potentially identified risks to the project. This is done to ensure the project can adequately adjust itself to the rapid changes in the environment, therefore ensuring flexibility. Incorporating the many feedback mechanisms that are inherent to the Scrum method into this PDD however, is out of scope.

Release Finalization

After the development phase is completed, the project transitions to the closure phase. The closure phase of the Scrum method consists of conducting three unordered activities: the creation of ‘release documentation’, ‘marketing material’, and ‘training material’. The release documentation contains information such as version-related data (i.e. changes to the product compared to prior versions), and other valuable information such as system-administration related information. When all of the aforementioned deliverables are created, the updated executable version of the system can be handed over to CustComp? (the customer). Considering three requests (#4, #5 & #6) are still on the product backlog, more sprints will be necessary in order to fulfill all requests as formulated on the product backlog.

Process-Deliverable Diagram

The engineering discipline of method engineering is concerned with the design, construction, and adaptation of methods, techniques and tools for systems development (Brinkkemper, 1996). Topics in the domain of method engineering include for instance identifying method fragments, comparing methods, formalizing method properties, and formally describing methods. An important question related to the latter topic, is how to describe and store methods in a method base, in order to easily reuse the method fragments in a method engineering process.

A comprehensive elaboration on this question is provided in the work of Van de Weerd and Brinkkemper (2008), where the authors present a meta-modeling technique to describe both the process and deliverable part of a method in one diagram. Whereas a model is a representation that contains statements about the properties of an artifact (object) of a real or imagined world, a meta-model is a model that consists of formal statements about models (Van de Weerd & Brinkkemper, 2008).

The resulting meta-model diagram is called a process-deliverable diagram (PDD). A PDD provides a simple overview supporting the documentation and communication of methodical processes and deliverables by connecting activities with their respective deliverables. An advantage of PDDs is that the diagrams are relatively clear, compact, and are modeled with a notation that is similar to UML activity diagrams, and are thus easy to understand (Van de Weerd & Brinkkemper, 2008).

Description of the Process-Deliverable Diagram for Scrum

Figure 2 shows the PDD for the Scrum method, as originally described by Schwaber (1995). The PDD shows the main activities and concepts created and used throughout the Scrum method. On the left side of the diagram, the activities performed during a Scrum process are shown. The resulting deliverables from these activities are modeled and concepts on the right side of the diagram. Arrows going from the process side to the deliverable side link related activities and deliverables together, indicating which deliverables have been produced by which activities. It is important to notice that input arrows (which concepts are required by an activity) are not shown in a PDD, as all produced deliverables are assumed to be generally available (Van de Weerd & Brinkkemper, 2008).

Furthermore, three different types activities and concepts can be seen in the PDD. The majority of the activities and concepts are ‘standard’, meaning the activity or concept has no sub activities or concepts and is thus considered atomic. Next to standard activities and concepts, complex activities and concepts can be distinguished. Complex activities and concepts do have sub activities or sub concepts. This complex variant can be split up in two versions: open and closed activities and concepts. An open activity or concept means the meta-model details can be found in this or another meta-model of the method engineering study at hand. A closed activity or concept then means that the sub activities and concepts are not known in this context, or are not relevant to further elaborate on (Van de Weerd & Brinkkemper, 2008). In addition, different roles are assigned to all the various activities, reflecting which project team member or members that fulfill a specific role are responsible for conducting the relevant activity.

As the Scrum method covers an entire system’s development, a certain level of granularity had to be chosen for this PDD. In this case, a single instance of a sprint is realized, meaning one “executable version” of a software product or system is delivered according to a “release plan”. Again as aforementioned, it is important to mention that the term release plan is in this context to a certain extent interchangeable with the term “sprint backlog”, although a release plan comprises more details. For the sake of clarity and to prevent including a lower level of granularity, the term release plan was chosen. In addition, daily feedback mechanisms by means of short daily review meetings are inherent to the Scrum method. The results of these daily Scrum meetings however are intangible, meaning no specific deliverables are generated. The daily Scrum cycles should thus be taken into account as an inherent characteristic of the Scrum method. Including every single feedback mechanism described by the Scrum method would make the PDD an estimated two times larger than its current size. Last but not least, several additional rules, unclarities and open issues that could not be depicted graphically are described below the PDD.

Figure 2 Process-Deliverable Diagram of the Scrum method

Activity Table

Each PDD is accompanied by an activity table. The activity table for the Scrum PDD is shown in Table 3 below. The activity table provides short but comprehensive descriptions, and includes both the main activities as well as sub activities of the Scrum method.

Table 3: Activity table of the Scrum Process-Deliverable Diagram

Activity	Sub-Activity	Description
Plan project	Create product backlog	A PRODUCT BACKLOG is created by the product owner through gathering customer request if it concerns new product development, but can also contain product functionality requirements that are not adequately addressed by the current product release in case it concerns an existing product. Such inadequacies include bugs, defects, customer requested enhancements, functionalities, and technology upgrades.
	Define functionalities for releases	For every Scrum sprint, one RELEASE FUNCTIONALITY or more are derived from the PRODUCT BACKLOG by the product owner. A RELEASE FUNCTIONALITY can thus be derived based on any of the aforementioned inadequacies as described in PRODUCT BACKLOG, or concern new product requirements.
	Define delivery dates for releases	The DELIVERY DATE of a planned release is defined by the product owner to decide when the final EXECUTABLE VERSION of the (new) deliverable is to be handed over to a customer.
	Define release plan	The RELEASE PLAN for a Scrum project is defined by the product owner based on one RELEASE FUNCTIONALITY or more, and also contains a DELIVERY DATE.
	Form project teams	PROJECT TEAMs are formed by the scrum master that will be assigned with the task to realize and implement contents as described in a RELEASE PLAN.
	Identify risks	For each Scrum project, potential RISKs are identified by the product owner. Identified RISKs are stored in a RISK LIST.
	Assess risks	Each identified RISK is assessed by the product owner to study its nature, leading to an ASSESSMENT REPORT.
	Analyze risk impact	To determine an overall threat level to the Scrum project, the IMPACT of each risk on the Scrum project is analyzed by the product owner.
	Prioritize risks	The resulting ASSESSMENT REPORT of each risk, including determined IMPACT factors of each risk are combined by the product owner to assign a PRIORITY to each risk.
	Define risk monitoring strategy	Based on the determined PRIORITY of each risk, a risk monitoring strategy is defined by the product owner to safeguard the Scrum project.
	Identify required development resources	The required development resources are identified by the product owner and are written down in RESOURCE PLANs.
	Estimate development budgets	The required development budgets are estimated and are described in BUDGET PLANs by the product owner.
	Verify management approval and funding	The product owner has to request approval and funding from management, based on a PROJECT PLAN that in turn is based on the RELEASE PLAN, RESOURCE PLANs and BUDGET PLANs.
Design architecture	Assess current system architecture	The existing or to be developed SYSTEM ARCHITECTURE is assessed by the team, to see whether it is able to support the contents as described in the RELEASE PLAN.
	Assess current domain models	The existing or to be developed DOMAIN MODELs are assessed by the team, to see whether they are able to support the contents as described in the RELEASE PLAN.
	Define product standards	In case necessary, PRODUCT STANDARDs are defined by the team to which a RELEASE PLAN may have to conform, for instance to support standardization.
Develop release	Review project plan	The PROJECT PLAN is reviewed by the team to ensure common ground by all Scrum project participants.
	Develop backlog components	Backlog components are developed by the team according to the RELEASE PLAN. This results in one or multiple COMPONENT SOURCE CODEs.
	Wrap developed backlog components	When the required backlog components are developed, the COMPONENT SOURCE CODEs are wrapped together by the team into an EXECUTABLE VERSION that realizes the RELEASE PLAN.
	Review working executable	The EXECUTABLE VERSION is reviewed by the team to ensure it is bug-free. In case bugs are found, the erroneous COMPONENT SOURCE CODEs are adjusted. In case the EXECUTABLE VERSION is approved, the EXECUTABLE VERSION is considered to be successfully developed.
Finalize release	Create release documentations	Based on the EXECUTABLE VERSION, DOCUMENTATIONs are created by the team to support a customer in understanding and using the EXECUTABLE VERSION.
	Create marketing materials	Based on the EXECUTABLE VERSION, MARKETING MATERIALs are created by the team to hand over the EXECUTABLE VERSION to a customer in a customer-intimate way.
	Prepare training materials	Based on the EXECUTABLE VERSION, TRAINING MATERIALs are prepared by the team to train customers on how to use the EXECUTABLE VERSION.

Concept Table

In addition, each PDD is also accompanied by a concept table containing definitions of the concepts, here presented in Table 4. Properties of relevant concepts are also explained in a short manner, and every concept description provides a reference on where to find the literature source for the given definition.

Table 4: Concept table of the Scrum Process-Deliverable Diagram

Concept	Description
PRODUCT BACKLOG	A PRODUCT BACKLOG contains product functionality requirements that are not adequately addressed by the current product release. Backlog items are bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades (Schwaber, 1995).
RELEASE FUNCTIONALITY	A RELEASE FUNCTIONALITY is a product functionality requirement to be incorporated in a planned release, that is not adequately addressed by the current product release. It may concern a bug, a defect, a customer requested enhancement, a competitive product functionality, a competitive edge functionality, or a technology upgrade (Schwaber, 1995).
DELIVERY DATE	A DELIVERY DATE is the moment when the final deliverable (WORKING EXECUTABLE) is to be handed over to a customer (Schwaber, 1995).
RELEASE PLAN	A RELEASE PLAN is a document describing a software product release. It is based on the following variables: customer requirements, time pressure, competition, quality, vision, and resource (Schwaber, 1995).
PROJECT TEAM	A PROJECT TEAM is a team that is responsible for building a new release (Schwaber, 1995).
ASSESSMENT REPORT	An ASSESSMENT REPORT describes an assessment of a RISK and appropriate risk control (Schwaber, 1995).
IMPACT	An IMPACT is the degree of negative influence a RISK can exert over the Scrum project (Hossain, Babar, Paik & Verner, 2009).
PRIORITY	A PRIORITY is the perceived level of threat assigned to an identified RISK, based on its assigned IMPACT and ASSESSMENT REPORT (Schwaber, 1995).
RISK	A RISK is a perceived threat to a Scrum development project, based on internal or external variables (Hossain, Babar, Paik & Verner, 2009).
RISK LIST	A RISK LIST contains identified RISKs (Schwaber, 1995).
ACTIVITY LIST FOR RISK MONITORING	An ACTIVITY LIST FOR RISK MONITORING contains actions or routines to be taken into account by a project team, in order to safeguard a Scrum project against RISKs (Schwaber, 1995).
RESOURCE PLAN	A RESOURCE PLAN is a document describing what resources (e.g. development tools or physical equipment) are required by the project team to realize a RELEASE PLAN (Schwaber, 1995).
BUDGET PLAN	A BUDGET PLAN is a document describing the amount of funding required by the PROJECT TEAM in order to realize a RELEASE PLAN (Schwaber, 1995).
PROJECT PLAN	A PROJECT PLAN typically contains process plans, consisting of work packages and other project-relevant plans (Feiler & Humphrey, 1993).
SYSTEM ARCHITECTURE	A software SYSTEM ARCHITECTURE comprises a collection of software and system components, connections, and constraints. It also comprises a collection of system stakeholders-need statements, and a rationale which demonstrate that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholder need statements (Gacek, Abd-Allah, Clark & Boehm, 1995).
DOMAIN MODEL	A DOMAIN MODEL defines the behavior of applications in the system through scenarios, data flow diagrams, and state transition diagrams (Tracz, 1995).
PRODUCT STANDARD	A PRODUCT STANDARD is a requirement or set of requirements the product has to conform to (Schwaber, 1995).
COMPONENT SOURCE CODE	A COMPONENT SOURCE CODE is a readable format of commands in a program before it is compiled or assembled into an EXECUTABLE VERSION, in this case of a developed component (Schwaber, 1995).
EXECUTABLE VERSION	An EXECUTABLE VERSION is a compilation of source code of all the separately developed components combined, that can be executed as a computer program (Schwaber, 1995). An EXECUTABLE VERSION also mentions the names of the authors responsible for developing the EXECUTABLE VERSION.
EXECUTABLE VERSION HISTORY	An EXECUTABLE VERSION HISTORY is a chronological record of events related to an EXECUTABLE VERSION. This record contains a reference to the source code of the EXECUTABLE VERSION it is referring to, including an effective date of when the record was updated, the status of the EXECUTABLE VERSION (e.g. alpha, beta, final), and the current version (e.g. 1.1, 1.2.3, or 3.0) (Schwaber, 1995).
DOCUMENTATION	A DOCUMENTATION is a document consisting of written text or visual representations accompanying an EXECUTABLE VERSION upon which it is based (Schwaber, 1995).
MARKETING MATERIAL	A MARKETING MATERIAL is a tangible or intangible material with the purpose of promoting or informing a customer to sell an EXECUTABLE VERSION of (in this case) a software product or system (Schwaber, 1995).
TRAINING MATERIAL	A TRAINING MATERIAL is a tangible or intangible material with the purpose of teaching a customer or user on how to use (in this case) an EXECUTABLE VERSION of a product or system (Schwaber, 1995).

Related Literature

The very origins of the Scrum development method trace back to 1986, when Takeuchi and Nonaka introduced a novel approach to manage development processes based on empirical data gathered through case studies conducted in the manufacturing industry (Takeuchi & Nonaka, 1986). In their approach, emphasis is placed on a trade-off concerning choosing either for increased process speed and flexibility or for design and quality, both at the expense of one another. The term Scrum was then first coined in 1990 by Degrace and Stahl (1990) to describe this approach, referring to a specific formation of a rugby team in sports. Next, an improved version of an iterative and incremental approach to delivering object-oriented software that was initially described by Pittman (1993) and then later enhanced and expanded by Booch (1995), served as the fundamental basis for the core upon which Scrum is built. Several years later, Sutherland and Schwaber (1995) presented their paper describing the Scrum method as it is known today, which took the essence of the aforementioned articles and books into account.

When positioning Scrum within the domain of agile software development, early related predecessors of Scrum have to be studied. Whereas early approaches to systems development such as the waterfall (Royce, 1987), spiral (Boehm, 1988) and iterative (Larman & Basili, 2003) models regard the development process as fixed and predictable, the Scrum approach assumes the opposite. Instead of treating the development process as something monolithic, Scrum prioritizes large items and tasks to be performed into chunks of work that can be managed in a flexible way. Flexibility again is increased by making use of various control mechanisms, therefore leading to greater responsiveness in terms of adaptation to changes in the environment and lesser unpredictability and risk (Schwaber, 2004). Scrum however is just one out of many different agile project management methods. Other agile methods described in literature that are related to Scrum are for instance Feature-Driven Development (Coad, Lefebvre, & De Luca, 1999), Lean Software Development (Poppendieck & Poppendieck, 2003), Crystal Clear (Cockburn, 2004) and Extreme Programming (Beck & Andres, 2004).

To assess the effectiveness of the Scrum development method in practice, a large number of comparisons and case studies have been conducted and described in existing literature. Among examples are case studies on the impact of Scrum on overtime and customer satisfaction (Mann&Maurer, 2005), an assessment of scalability of the Scrum method when applied in different environments (Sutherland, 2001), an assessment of the effectiveness when implementing Scrum in small teams and its results (Rising & Janoff, 2000), and an overview of both the strengths and weaknesses of Scrum compared to other agile development methods (Boehm, 2002).

Related Literature

Beck, K., & Andres, C. (2004). Extreme programming explained: Embrace change (2nd edition). Addison-Wesley Professional.

Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21, 61-72.

Boehm, B.W. (2002). Get ready for agile methods, with care. Computer, 35 (1), 64-69.

Booch, G. (1995). Object solutions: managing the object-oriented project. Redwood City, CA, USA: Addison Wesley Longman Publishing Co., Inc.

Brinkkemper, S. (1996). Method engineering: engineering of information systems development methods and tools. Information and Software Technology, 38, 275-280.

Coad, P., Lefebvre, E., & De Luca, J. (1999). Java modeling in color with UML: Enterprise components and process. Prentice Hall International.

Cockburn, A. (2004). Crystal clear: A human-powered methodology for small teams. Addison-Wesley Professional.

Degrace, P., & Stahl, L. H. (1990). Wicked problems, righteous solutions: A catalog of modern engineering paradigms. Prentice Hall.

Feiler, P.H., & Humphrey, W.S. (1993). Software Process Development and Enactment: Concepts and Definitions. Proceedings of the Second International Conference on the Software Process (ICSP), 28-40.

Gacek, C., Abd-Allah, A., Clark, B., & Boehm, B. (1995). On the Definition of Software System Architecture. Proceedings of the First International Workshop on Architectures for Software Systems, 85-95.

Hossain, E., Babar, M.A., Paik, H., & Verner, J. (2009). Risk Identification and Mitigation Processes for Using Scrum in Global Software Development: A Conceptual Framework. Proceedings of the 2009 16th Asia-Pacific Software Engineering Conference (APSEC '09). IEEE Computer Society, Washington, DC, USA, 457-464.

Larman, C., & Basili, V. R. (2003). Iterative and incremental development: A brief history. Computer, 36, 47-56.

Mahnic, V., & Vrana, I. (2007). Using stakeholder driven process performance measurement for monitoring the performance of a scrum based software development process. Electrotechnical Review, 74 (5), 241-247.

Mann, C., & Maurer, F. (2005). A case study on the impact of scrum on overtime and customer satisfaction. Proceedings of the agile development conference. IEEE Computer Society, Washington DC, USA, 70-79.

Pittman, M. (1993). Lessons learned in managing object-oriented development. IEEE Software, 10, 43-53.

Poppendieck, M., & Poppendieck, T. (2003). Lean software development: An agile toolkit. Addison-Wesley Professional.

Rising, L., & Janoff, N. S. (2000). The scrum software development process for small teams. IEEE Software, 17, 26-32.

Royce, W. W. (1987). Managing the development of large software systems: concepts and techniques. Proceedings of the 9th international conference on software engineering. IEEE Computer Society Press, Los Alamitos, CA, USA, 328-338.

Schwaber, K. (1995). Scrum development process. Proceedings of the 10th annual ACM conference on object oriented programming systems, languages, and applications, 117-134.

Schwaber, K. (2004). Agile project management with scrum. Redmond, WA, USA: Microsoft Press.

Sutherland, J. (2001). Agile can scale: Inventing and reinventing scrum in five companies. Cutter IT Journal, 14 (12), 5-11.

Sutherland, J., & Schwaber, K. (1995). Business object design and implementation. OOPSLA ’98 workshop proceedings report.

Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, January/February, 285-305.

Tracz, W. (1995). Domain-Specific Software Architecture. ACM Software Engineering Notes, 20 (3), 49-62.

Weerd, I. van de, & Brinkkemper, S. (2008). Meta-Modeling for Situational Analysis and Design Methods. In M. Syed & S. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications (p. 38-58). Hershey: Idea Group Publishing.  

-- VincentBlijleven - 10 Feb 2012

• Review_Blijleven_Gregorian.pdf: Review document

• Scrum_VincentBlijleven_Draft_Review_Gregorian.docx: Paper review