This document provides an introduction to the Scrum methodology for software development. It discusses the software crisis in the 1960s that led to the need for more formal development methodologies. Scrum is defined as an agile framework that uses short iterations called sprints, a product backlog of features, and core roles of a product owner, development team, and scrum master. The document outlines Scrum's empirical process of transparency, inspection, and adaptation and how it aims to deliver high quality working software through frequent inspection and adaptation.

1. Introduction To Scrum
By
Fahad Alshareef & Naser Alsaeed
King Saud University
College of Computer and Information Sciences
Department of Software Engineering

2. Review Questions
• What is a software?
• What is software engineering?
• What is a software development
methodology?
• What is software quality?

3. Software Development Methodologies
• How did methodologies come to be? What was the
actual need for them?
First NATO Software Engineering Conference in 1968 at Garmisch, Germany

4. The Software Crisis
Edsger W. Dijkstra

5. Summary of Edsger’s Speech
• As hardware and computing power expands,
and new technologies are invented, society
demand applications for such inventions. This
is where a programmer (software engineer) is
needed.
• Adding resources only makes a programmer’s
life more difficult!
• If resources expand, so will the complexity of
the software.

6. These are the major issues that caused the software
crisis:
• Projects running over-budget.
• Projects running over-time.
• Software was very inefficient.
• Software was of low quality.
• Software often did not meet requirements.
• Software was very inefficient.

7. So, What’s The Solution?
• Formal engineering approaches.
• CASE tools and documentation.
• Professionalism and discipline.
• Methodologies and processes.
• The reality is that there is no “one solution” to
help with this problem. All of them work
together to help solve the software crisis.

8. Software Methodologies
• Now that we know the actual need for
methodologies, what are they?
• A methodology or a process is a framework.
• It defines what is considered software
development and what is not.
• It tells you how and when to do it.

9. Software Methodologies
How to choose a methodology?
• Based on the nature of the software.
• Based on the organization or client you are
working with.
• Based on the team’s familiarity and expertise.
• Be careful of it’s effect on budget!

10. Agile Methodologies
• Agile mainly define by two things:
• Iterative Development
• Incremental Development

11. Agile Methodologies
• In February, 2001, 17 software developers met to
discuss lightweight development methods.
• They wrote a manifesto which included the following
values:
• Individuals and interactions over Processes and tools
• Working software over Comprehensive documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan

12. Agile Methodologies
• From that meeting, many of the software
developers went on to create methodologies
like Extreme Programming, Adaptive Software
Development, and Scrum.

13. Scrum Introduction
Jeff Sutherland
Ken Schwaber

14. Scrum Introduction
• A “scrum” is a method of restarting the play in
rugby.

15. Scrum Definition
• Scrum is a process framework that has been
used to manage complex product
development since the early 1990s.
• The Scrum framework consists of Scrum
Teams and their associated roles, events,
artifacts, and rules. Each component within
the framework serves a specific purpose and
is essential to Scrum’s success and usage.

16. Scrum Theory
• Empiricism is a philosophical theory which
states that knowledge only comes from the
senses.
• Rationalism is a philosophical theory which
states that knowledge only comes from
reason, deduction, and logic.
• Scrum is founded on empiricism.

17. Scrum Theory
• Three pillars uphold every implementation of
empirical process control(empiricism):
• Transparency
• Inspection
• Adaptation

18. Scrum Theory
Transparency:
• Significant aspects of the process must be visible to those
responsible for the outcome.
• Transparency requires those aspects be defined by a common
standard so observers share a common understanding of
what is being seen.
Example:
• A common language referring to the process must be shared
by all participants.
• Those performing the work and those accepting the work
product must share a common definition of “Done”.

19. Scrum Theory
Inspection:
• Scrum users must frequently inspect Scrum
artifacts and progress to detect undesirable
variances.
• Their inspection should not be so frequent
that inspection gets in the way of the work.

20. Scrum Theory
Adaptation:
• If an inspector determines that one or more aspects of a process
deviate outside acceptable limits, and that the resulting product will
be unacceptable, the process or the material being processed must
be adjusted. An adjustment must be made as soon as possible to
minimize further deviation.
• Scrum prescribes four formal events for inspection and adaptation:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

21. Product Backlog
• In Scrum, features are written from the
perspective of the end user. Example: “As a
(role), I want (feature), so that (benefit).”
• Features are known as user stories.
• The Product Backlog is a kind of “wish list” for
all the features that would make the product
great.

22. Product Backlog

23. Release Backlog
• We identify the features that will make it to the
release.

24. Release Backlog
• After that, we prioritize them based on their
importance, and estimate how long each will take.

25. The Scrum Team
The Scrum Team consists of:
• Product Owner
• Development Team
• Scrum Master

26. The Scrum Team
The Product Owner:
The Product Owner is the sole person responsible for managing the
Product Backlog. Product Backlog management includes:
• Clearly expressing Product Backlog items.
• Ordering the items in the Product Backlog to best achieve goals
and missions.
• Optimizing the value of the work the Development Team
performs.
• Ensuring that the Product Backlog is visible, transparent, and
clear to all, and shows what the Scrum Team will work on next.
• Ensuring the Development Team understands items in the
Product Backlog to the level needed.

27. The Scrum Team
The Product Owner:
• The Product Owner is one person, not a committee. The Product
Owner may represent the desires of a committee in the Product
Backlog, but those wanting to change a Product Backlog item’s
priority must address the Product Owner.
• For the Product Owner to succeed, the entire organization must
respect his or her decisions.
• The Product Owner’s decisions are visible in the content and
ordering of the Product Backlog.
• No one is allowed to tell the Development Team to work from a
different set of requirements, and the Development Team isn’t
allowed to act on what anyone else says.

28. The Scrum Team
The Development Team:
• The development team includes designers, developers,
testers, and anyone who may be needed to create the system.
• Scrum recognizes no titles for Development Team members
other than Developer, regardless of the work being performed
by the person
• Individual Development Team members may have specialized
skills and areas of focus, but accountability belongs to the
Development Team as a whole.

29. The Scrum Team
The Scrum Master:
• The Scrum Master is responsible for ensuring Scrum is
understood and enacted. Scrum Masters do this by ensuring
that the Scrum Team adheres to Scrum theory, practices, and
rules.
• The Scrum Master is similar to product managers.

30. Scrum Events
Sprints:
• We organize the features into milestones that are 30 days or less. Each
feature will take up a certain amount of time based on the time required
to finish it.

32. Scrum & Software Quality
• Nothing in software engineering guarantees
high quality. This is true for Scrum as well.
• Choosing a methodology affects quality!
• Scrum supports walkthroughs.
• Scrum has daily meetings which insures no
obstacles are facing the team.
• Scrum is Agile, and therefore measures quality
in terms of working software.

33. Scrum & Software Quality
• In Scrum, everyone is responsible for quality
and testing.
• This is good, because in other methodologies
the coder may not test his code and leave it to
the testers.
• SQ = Meeting requirements; Scrum =
Responding to changing requirements;
therefore Scrum fulfils one of the conditions
of achieving high quality.

34. Scrum & Software Quality
• One of the major causes for software errors is
client-developer communication failures.
• Scrum removes this issue because it’s agile,
and one of agile development’s values is:
• Customer collaboration over Contract negotiation
• Also, faulty requirements definitions is a major cause
for errors. Scrum removes this issue by insuring all
requirements are written in end-user perspective.

35. Q & A
• Any questions?

36. Useful Resources
• https://www.scrum.org/Scrum-Guide
• http://www.slideshare.net/lemiorhan/high-
quality-software-development-with-agile-and-
scrum-12193579
• http://www.youtube.com/watch?v=XU0llRltyF
M
• This presentation is uploaded on: