A study of the principles, approaches, life-cycle, patterns and best practices, process and deliverables

in the Scrum Methodology

Scrum

Rim Mukhopadhyay Student ID - 5599695

Course Instructor – Sietse Overbeek

TA – Dimitra Papachristou Business Informatics, Faculty of Sciences, Utrecht University, Utrecht, The Netherlands.

1

Table of Contents 1. Introduction ............................................................................................................................................................................................................ 2

1.1 History ..................................................................................................................................................................................................................... 2

1.2 Definition ................................................................................................................................................................................................................ 2

2. Approaches ............................................................................................................................................................................................................. 2

3. Roles ....................................................................................................................................................................................................................... 3

4. The Process ............................................................................................................................................................................................................. 4

4.1 Example ................................................................................................................................................................................................................... 4

4.2 Phases and Deliverables .......................................................................................................................................................................................... 5

4.3 Process Deliverable Diagram................................................................................................................................................................................... 8

4.4 Activity table ........................................................................................................................................................................................................... 9

4.5 Concept table ........................................................................................................................................................................................................ 10

5. Literature study ..................................................................................................................................................................................................... 11

Best Practices .............................................................................................................................................................................................................. 11

6. References ............................................................................................................................................................................................................ 13

2

1. Introduction

“Scrum” is an iterative software development methodology that is applied when the client-requirements are volatile or

liable to change. Instead of starting the development activities after finalizing or freezing the requirements, the

requirements “evolve” in-tandem with the development process – thereby making it an “Agile Software Development

Methodology”. The basic governing principles of Scrum are to accommodate “requirements volatility” (the fact that the

customer himself does not have a concrete set of requirements in the beginning), and segregating the work into a number

of cross functional teams, each with their prioritized set of tasks. As the design and development progress, the

stakeholders/ customers are shown an early version of the product developed so far, to assess what the further system

requirements would be. This cycle takes place as many times as deemed necessary and feasible. Each cycle produces a

usable version of the product.

This document discusses the background and history of Scrum, the Roles in a Scrum approach, the phases in the

development lifecycle (when Scrum is applied), and the Deliverables from each of these phases; it also attempts to explain

Scrum methodology further by instantiating it. It concludes by discussing the most common approaches and successful

patterns of Scrum.

1.1 History

The Agile approach was developed by Jeff Sutherland, John Scumniotales and Jeff McKenna while at Easel Corporation,

inspired by a “30 day planning cycle approach” proposed by Hirotaka Takeuchi and Ikujiro Nonaka in the Harvard

Business Review (1986). This was later influenced by Sutherland’s perception of industry observations, leading to the

more precise “Scrum Method”. In the paper “Teams that Finish Early Accelerate Faster: A Pattern Language for High

Performing Scrum Teams” by Sutherland, Harrison and Riddle (2014), a few glimpses of the history and evolution of

Scrum may be found. It elaborates the purpose of Scrum as “One of Scrum's design goals was to encapsulate best

practices from 40 years of software development into a process that was simple enough for the average developer to use

with less than 2 days of startup time”. This gives us valuable insight regarding the motivation behind the development of

this method.

1.2 Definition

In the selected paper “Aligning Architecture Knowledge Management with Scrum” (Eloranta & Koskimies, 2012),

several variations in Scrum methodology have been discussed; and Scrum has been defined as an “Iterative and

incremental framework for agile project management”. This implies that this methodology may be tailored and applied to

organizations to suit their own needs. It has been defined as a “framework”, meaning that it consists of basic principles

and collection of best practices from across the Industry, which may be adapted sparingly or completely, depending on the

organizational structure and culture.

The definition “A Pattern Language for Hyper productive Software Development, a groundbreaking work that

established a pattern foundation for Scrum, the most widely deployed Agile processes in the world” is significant in our

understanding of this method, as it comes from none other than Jeff Sutherland, who has authored “The Scrum Guide’,

co-authored the “Agile Manifesto”, and is widely accepted as the “Inventor of Scrum” (courtesy Greening, in his paper

“Enterprise Scrum: Scaling Scrum to the Executive Level”, 2010).

2. Approaches

The paper (Eloranta, 2012) delves into the different architectural approaches to Scrum. Before describing these, it is notable

that the main challenge faced in a Scrum environment is that the architecture documents lag behind, as often there is no

exclusive time dedicated to design conception. Keeping this issue in mind, Eloranta mentions the following approaches:

3

(i) Big Upfront Architecture design – In this approach, there is a dedicated time and effort focusing on the design.

The architectural design is created by a dedicated team prior to the start of the Scrum sprints. This might involve

communication between the architects and developers, and some documentation.

(ii) Sprint 0 Architecture – In this approach, the architecture is designed in the initial sprint (sprint 0), but by the

development team. This approach might cause the design to encounter integrity issues if simultaneously conceived

by multiple teams.

(iii) In-sprints design – In this approach, there is no extra time allotted to the design; the design is developed iteratively

and in tandem with the implementation. Whenever a design issue is encountered, decisions are made and the

product modified accordingly.

(iv) Separated Architecture team – In this approach, there is a separate team for the architecture design. This team

comprises of members from the development teams, as well as external architects. However, they have separate

meetings dedicated to design/ architecture discussions and solutions.

An interesting extension of the Scrum Approach is to conduct a “Scrum of Scrums” – wherein micro managing of the

Scrums may be achieved, specifically for distributed teams. The paper “Challenges in Adapting Scrum in Legacy Global

Configurator Project” by Gupta & Manikreddy (2015) considers the option of conducting a Daily Meeting, to ensure that

the daily targets are not lagging behind.

3. Roles

The basic Scrum Methodology consists of three pivotal roles. The paper “Scrum Master Activities: Process Tailoring in

Large Enterprise Projects” (Bass, 2014) gives a concise yet clear overview of these roles.

(i) Product Owner – This role is a business-centric one, meaning that the primary responsibility is ensuring that the

Clients’/ Stakeholders’ needs are satisfied. The Product owner would create a list of “Priorities”, which would

have to be addressed in each sprint (by the Teams). He would also maintain a “Product backlog” to monitor the

development of the product – but would address these from the Client’s perspective, and not the development

teams’ perspectives.

(ii) Scrum Master – This role entails planning and coordinating between the teams involved. He would act as a

“facilitator” (Bass) and work to remove the hurdles that any of these teams might encounter. He would also be

responsible for planning the cycles (sprints). As an advocate of the Agile Methodology, he would ensure that all

the teams are complying with the principles involved in Agile Development Cycle. In line with this, Bass

describes the Scrum Master as the “Process Anchor” and “the primary interface between the product owner and

the software development team”, as he is in charge of the co-ordination and communication between the teams.

The Scrum Master would look into integrating the deliverables of the teams together.

(iii) The Team(s) – The group of people working on developing the product. They may be segregated into

development and testing teams, depending on the task and workforce available. The development teams may be

further segregated based on the parts or aspects of the product they are working on. These are described as “self-

organizing and cross functional” teams in the paper “Do Daily Scrums Have to Take Place Each Day? A Case

Study of Customized Scrum Principles at an E-Commerce Company” (Pauly, Michalik and Basten, 2015). This

paper points out that in order for the Scrum to be successful, these teams should be self-sufficient, and

empowered to make decisions if the need be. Special care should be taken to facilitate seamless communication in

between teams that are spread out over diverse locations, or the scrum process might not be the most efficient, as

explained by Ghosh (2012) in his paper “Challenges in Distributed Scrum”.

4

4. The Process

This section of the document explains the Scrum Process in a systematic way. First we have an example to depict the

workings of the method, followed by a detailed Phase- Deliverable mapping. This information is then shown in the form

of a Process Deliverable Diagram accompanied by Activity and Concept tables.

4.1 Example

This section explains the above steps with the help of an example. This example is a fictitious one, and has been inspired

by case studies encountered in the following papers - “Managing Technical Debt in Software Projects Using Scrum: An

Action Research” by Oliveira, Goldman & Santos, (2015), and “Project Management Using the Scrum Agile Method: A

Case Study within a Small Enterprise” by Romano & da Silva (2015).

An organization “Org”, which produces custom-made venue booking solutions for hotels and resorts receives an order from

a hotel (H) that has undergone a recent rebranding. The Management board of H are relatively new (due to an organizational

restructuring), and has a faint idea of how it should look. Two Management representatives (MR1 and MR2) have been

nominated to oversee this matter. From the Org, a small team (people who have worked together successfully in the past)

has been assembled. The Team is managed by Mr. Z. The Business Consultant Mr. B from Org has been entrusted with the

role of “Client point of contact”.

Step 1 – Business Kickoff meeting

MR1 and MR2 meet B and explain what they want.

B creates a business requirements document and reviews it with MR1 and MR2 to ensure they are on the same page.

Step 2 – Development Kickoff meeting

B meets with Z and Team, and explains what the customer has in mind. B assumes the role of Product Owner.

Z and a few team members translate the business requirements to a requirements specification document.

Step 3 – Design planning

Architects from Org sit and discuss what functionalities and performance are required to satisfy the requirements.

Step 4 – Start of Sprint1

Z assumes role of Scrum Master, and sets immediate targets for the sprint. The Product Backlog is drafted, which contains

the main module of the software, and assigns a few testers and developers to this task.

Step 5 – Sprint1 (2 weeks)

The team works together to code this functionality, and tests it.

Step 6 – Sprint Review

The “somewhat-ready” website is shown to B. B is satisfied with what he sees.

B understands how to use it and fixes an appointment with MR1 and MR2 to do a demo presentation.

Team makes a note that though the functionalities seem okay, the appearance and speed could be improved. However, since

this is not affecting the primary functionality, the Team puts this is the Sprint Backlog.

Step 7 – Client Demo

The first version is presented to MR1 and MR2, and they like how it is shaping up, and say that they would like to have it

enhanced further for two more weeks, as they need it to be LIVE before New Year’s Eve.

5

Step 8 – Sprint2 Kickoff

B explains to Z what suggestions the clients have given so that the product comes closer to what they had in mind.

These are added to the Product Backlog.

Step 9 - Sprint2 (2 weeks)

The Team addresses the new cosmetic changes (Product Backlog), and tests it.

They would like to resolve the issues in the Sprint Backlog, but since there are time constraints, Z prioritizes the most

important performance issue and asks the Team to focus on that.

Step 10 – Final Demo

Team presents the final product to B.

B schedules the final demo with MR1 and MR2.

The website goes LIVE.

Step 11 – Retrospection

Z and Team have some drinks to celebrate the success of the launch, at the same time, make a note of what they could have

done more efficiently.

4.2 Phases and Deliverables

Though there are many tailorings in use with regards to conduction of Scrums, some common steps have been identified

along with the corresponding deliverables. Below is an overview of the life-cycle of a Scrum Product Management

methodology.

1. Pre-game – The stakeholders, Product-owners and teams gather to understand the requirements. There might be several

variations to this – in some instances, the development team could be part of the meetings; alternatively, the product

owner meets the stakeholders first, and then has another meeting with the Teams to explain the requirements.

Deliverables

Product vision – The basic principles of the product as foreseen by the primary stakeholders, to serve as a Bible during the

course of the development.

Product Roadmap – The plan for how the product would evolve in future. This would contain the important milestones in

the life-cycle of the product.

Appointment of the Scrum-master – This is a very important decision, as the Scrum master would be in charge of future

communications between the Product-owner and the Teams.

Set of initial requirements – Based on which the development starts; this is not a definitive document, and changes as and

when the product takes shape.

2. Sprint-planning – The Team meets to set targets for the next sprint. The work-allocation and targets are set for the

following sprint.

Deliverables

Product backlog – The equivalent of a “requirements-prioritization”. This would be a list containing the functionalities and

performance requirements of the product which are to be addressed and worked-upon during the upcoming sprint.

6

Definition of completion clauses – The definition of when the product could qualify as having been “completed”. It is

noteworthy that it might be difficult to address the entirety of the requirements, and there could be infinite room for

improvement – thus it is very important to set a definition of when the product is “sufficiently complete” (when this clause

is met, this version or iteration of the product would be presented to the stakeholders).

Sprint backlog – The Scrum master would draw up a detailed plan of how the items in the Product backlog are to be

addressed and resolved in the upcoming sprint.

3. Sprint – The time allotted to the Team(s) during which they operate autonomously with the aim of achieving the set

targets. Depending on the product and the organization, the duration may vary; some organizations might prefer a

fortnightly sprint, whereas others might opt for longer or shorter sprints.

Deliverables

Product (partial) – Each sprint would entail a certain amount of advancement in the product. Sprints could be planned such

that the release-worthy version of the product might be ready in a couple of sprints, or in a single sprint, depending on the

task-at-hand, team strength, available resources and nature of the product.

4. Daily Scrum – The daily status meeting (organized by the Scrum Master), to discuss what work has been done till that

point of time, what the immediate targets are, and resolution of any issues faced. A common industry practice is to have

these meetings at the same location and time, so as to minimize the time spent on coordinating logistics of the meeting.

Deliverables

Updated Sprint backlog – Based on the targets achieved or pending, this document is updated to reflect the latest status of

the development.

5. Sprint review meeting – At the completion of every sprint, the development teams, stakeholders and Product-owners

meet. The Teams present the product (developed so far), and the product-owners and stakeholders assess whether this.

Deliverables

Agreement on completion clauses – The assessment (by the Product owner) as to whether the product meets the completion-

sufficiency criteria at the end of each sprint.

Updated Product backlog – The items that have met the completion criteria are removed from the list, and the ones that are

deemed insufficient are retained, to be addressed in the next sprint.

6. Sprint retrospective meeting – This is an optional step, intended to facilitate evaluation of the effectiveness of the

previous sprint.

Deliverables

Feedback from the Teams and Stakeholders, to gauge the levels of satisfaction from their respective viewpoints.

Lessons learnt – A note of the positive and negative experiences from the sprint, which might be useful for future sprints.

7. Release – At the end of each sprint, the resultant product from it is released to the customers. By principle, early releases

contribute to the success of the final product. This is due to the fact that the feedback and user acceptance data would

help streamline the product further to meet the clients’ needs.

Deliverables

7

Product – A version of the final product (might not be perfect, but should be sufficient with respect to the stakeholders’

requirements).

Figure 1 – Scrum Process (Eloranta & Koskimies, 2012)

8

4.3 Process Deliverable Diagram

Conduct sprint review

Execute sprint

Plan sprint

Pre-gaming

Conduct business-kickoff meeting Product-owner, Stakeholder

Conduct dev-kickoff meeting Product-owner

Analyze requirement Dev team

Design product Architect

Decide sprint duration

Estimate work

Allocate work

Develop product Dev. team

Present deliverable Dev. team

Assess deliverable Product-owner

Release product

Dev. team

Conduct daily-scrum Scrum-master

Conduct retrospect meeting

Product-owner

PRODUCT VISION

PRODUCT ROADMAP

BUSINESS REQUIREMENT DOC.

PRODUCT ARCHITECTURE

FUNCTIONAL REQUIREMENT DOC.

COMPLETION CLAUSE

PRODUCT (PARTIAL)

LESSONS LEARNT LOG

influences

is derived from

depends on

is d

erive

d fro

m

is d

erive

d fro

m

ESTIMATE

Man-days

SCHEDULE

Task

Responsibility

Target date

decides

Is created as per

SPRINT BACKLOG

Task id

Status

PRODUCT BACKLOG

Requirement ID

Status

PRESENTATION

sh

ow

ca

se

s

[is product

satisfactory]

[else]

Scrum-master

LIVE PRODUCT

is based on

0..*

1

1..*

1

1

1..*

0..1

11

0..*

0..*1

1

0..*

1

1..*0..*

1..*

0..1

1

9

4.4 Activity table

(Continued on the next page)

Activity Sub activity Description Role

Conduct business kickoff

meeting

Product owner(s) meet with the stakeholders to

understand the Business Requirements. The basic

principles of the product as foreseen by the primary

stakeholders, and the plan for how the product

would evolve in future are discussed.

Product Owner

Conduct development kickoff

meeting

Product owner(s) meet the Development teams to

explain the requirements.Product Owner

Analyse the requirementsThe business requirements are analysed and

translated into functional requirements.Development Team

Design productThe basic high-level architecture of the product is

created.Architect

Deciding sprint-duration

Based on the type of work and the organization, the

length of each sprint is decided. The duration may

vary; some organizations might prefer a fortnightly

sprint, whereas others might opt for longer or

shorter sprints.

Scrum Master

Estimating workEffort-estimation of the work for the first sprint is

arrived at.Scrum Master

Allocating workThe estimated work is assigned to the team

members based on their roles.Scrum Master

Developing product

During this time, the development teams operate

autonomously with the aim of achieving the set

targets.

Development Team

Daily Scrumming

The daily status meeting to discuss what work has

been done till that point of time, what the

immediate targets are, and resolution of any issues

faced. A common industry practice is to have these

meetings at the same location and time, so as to

minimize the time spent on coordinating logistics of

the meeting.

Scrum Master

Presenting deliverableThe Teams present the product (developed so far) to

the stakeholders.Development Team

Assessing deliverable

The Product-Owners and stakeholders assess

whether the deliverable so far meets the completion

criteria. If the stakeholders are satisfied, the product

is deemed complete and releasable.

Product Owner

Organize pre-

game

Plan sprints

Execute sprints

Conduct review

meeting

10

4.5 Concept table

(Continued on the next page)

Activity Sub activity Description Role

Release product NA

The product(s) that have been cleared by the

stakeholders as satisfactory (product(s) that meet

the completion criteria) are made available or LIVE

to the stakeholders.

Development Team

Conduct

retrospective

meeting

NA

This is an optional step, intended to facilitate

evaluation of the effectiveness of the previous

sprint.

Product Owner

Concept Type Definition

Product Vision Standard Concept

The basic principles of the product as foreseen by the

primary stakeholders, to serve as a Bible during the course of

the development.

Product Roadmap Standard Concept

The plan for how the product would evolve in future. This

would contain the important milestones in the life-cycle of

the product.

Business Requirement

DocumentClosed Concept

The client or customer's perspective of what is required of

the product.

Functional Requirement

DocumentClosed Concept

The development perspective of the features required in the

product, based on the business requirements.

Product Architecture Closed ConceptThe system-design, based on the features required and other

non-functional or performance requirements.

EstimateStandard Concept with

attributes

An calculation of how much effort is required to achieve the

product or deliver the business requirements. Its attribute is

"Mandays" which is the unit measure of work.

ScheduleStandard Concept with

attributes

The time-lines for what task is to be done by whom, and the

deadlines for the same. It has attributes "task id",

"responsibility" and "target date".

Product BacklogStandard Concept with

attributes

The equivalent of a “requirements-prioritization”. This

would be a list containing the functionalities and

performance requirements of the product which are to be

addressed and worked-upon during the upcoming sprint. It

has attributes "requirement id" and "status".

11

5. Literature study

Though the primary object of study was the paper “Aligning Architecture Knowledge Management with Scrum” (Eloranta,

2012), a few other papers provided very valuable insight on the Scrum Methodology.

Best Practices

In the paper by Sutherland et al (2014), some patterns have been identified for successful Scrum conduction across

industries. These are enumerated as below, to ensure that each sprint is as productive as possible.

Stable and small teams – Familiarity with team members promotes efficiency, as it is possible to predict their

performances. According to Sutherland et al, Research at Harvard University has shown that the optimum size for

scrum teams is five people, and that stability in teams is a good performance indicator.

Status monitoring of the previous sprints facilitates accurate prediction of future performance.

Concept Type Definition

Completion Clause Closed Concept

The definition of when the product could qualify as having

been “completed”. It is noteworthy that it might be difficult

to address the entirety of the requirements, and there could

be infinite room for improvement – thus it is very important

to set a definition of when the product is “sufficiently

complete” (when this clause is met, this version or iteration

of the product would be presented to the stakeholders).

Product (partial) Closed Concept

Each sprint would entail a certain amount of advancement

in the product. It may be understood as a release-worthy

version of the product created in one sprint. It is a version of

the final product (might not be perfect, but should be

sufficient with respect to the stakeholders’ requirements).

Sprint BacklogStandard Concept with

attributes

The Scrum master would draw up a detailed plan of how the

items in the Product backlog are to be addressed and

resolved in the upcoming sprint. It has attributes "task id"

and "status".

Presentation Standard ConceptThe demonstration and briefing session to show to the

customer how the product has shaped up thus far.

Live Product Closed Concept

A release-worthy version of the product, or the final

composite product, deployed in its intended environment of

use.

Lessons Learnt Log Closed Concept

A collection of the take-aways from every cycle. It is intended

to serve as a reference to future developments in the same /

similar projects, aimed at helping the team avoid repeating

mistakes.

12

“Swarming” – Concentrated efforts to address specific items in the backlogs enables the teams to deliver a release-

worthy product faster

“Interrupt pattern” – Setting up predetermined timeslots and protocols for interruptions, so as to minimize punctuating

the work

“Daily Clean Code” – Debugging on a daily basis, so as to avoid accumulation of bugs. The aim is to have a bug-free

code at the end of each working day.

“Emergency Procedures” – Predefined solutions for failures, which are to be triggered by the Scrum-Master if required.

This would help avoid wasting time by trouble-shooting.

“Scrumming the Scrum” – To Zero in on the most prominent issue/hurdle of the previous Sprint cycle, with the aim of

eliminating it from the next Sprint-backlog.

In their paper “Where is Scrum in the current Agile world?” Kapitsaki & Christou (2014) provide us with an understanding

of the extent to which Scrum is deployed in organizations across the world, by citing the history of research and surveys

conducted in this field.

The paper “Scrums: a model for safe agile development” by Maria, Rodrigues & Pinto (2015) elucidates the risk

management options in a Scrum Environment. The vulnerability assessment procedures and the concept of a “Safe Project”

are aspects of Scrum Project Management that could prove valuable to organizations looking to implement this

methodology.

13

6. References

Eloranta, V. P., & Koskimies, K. (2012, August). Aligning architecture knowledge management with Scrum. In

Proceedings of the WICSA/ECSA 2012 Companion Volume (pp. 112-115). ACM.

Greening, D. R. (2010, January). Enterprise Scrum: Scaling Scrum to the executive level. In System Sciences (HICSS),

2010 43rd Hawaii International Conference on (pp. 1-10). IEEE.

Sutherland, J., Harrison, N., & Riddle, J. (2014, January). Teams that finish early accelerate faster: A pattern language for

high performing scrum teams. In System Sciences (HICSS), 2014 47th Hawaii International Conference on (pp. 4722-

4728). IEEE.

Bass, J. M. (2014, August). Scrum Master Activities: Process Tailoring in Large Enterprise Projects. In Global Software

Engineering (ICGSE), 2014 IEEE 9th International Conference on (pp. 6-15). IEEE.

Pauly, D., Michalik, B., & Basten, D. (2015, January). Do Daily Scrums Have to Take Place Each Day? A Case Study of

Customized Scrum Principles at an E-commerce Company. In System Sciences (HICSS), 2015 48th Hawaii International

Conference on (pp. 5074-5083). IEEE.

Ghosh, G. K. (2012, August). Challenges in Distributed Scrum. In Proceedings of the 2012 IEEE Seventh International

Conference on Global Software Engineering (p. 200). IEEE Computer Society.

Oliveira, F., Goldman, A., & Santos, V. (2015, August). Managing Technical Debt in Software Projects Using Scrum: An

Action Research. In Agile Conference (AGILE), 2015 (pp. 50-59). IEEE.

Gupta, R. K., & Manikreddy, P. (2015, July). Challenges in Adapting Scrum in Legacy Global Configurator Project. In

Global Software Engineering (ICGSE), 2015 IEEE 10th International Conference on (pp. 46-50). IEEE.

Romano, B. L., & da Silva, A. D. (2015, April). Project Management Using the Scrum Agile Method: A Case Study within

a Small Enterprise. In 2015 12th International Conference on Information Technology-New Generations (ITNG) (pp. 774-

776). IEEE.

Kapitsaki, G. M., & Christou, M. (2014, April). Where is Scrum in the current Agile world? In Evaluation of Novel

Approaches to Software Engineering (ENASE), 2014 International Conference on (pp. 1-8). IEEE.

Maria, R. E., Rodrigues Jr, L. A., & Pinto, N. A. (2015, October). ScrumS: a model for safe agile development. In

Proceedings of the 7th International Conference on Management of computational and collective intelligence in Digital

EcoSystems (pp. 43-47). ACM.