An

Introduction to
Agile Methodologies: SCRUM
and XP
Prepared By:
Kunal Anand, Asst. Professor
SCE, KIIT, DU, Bhubaneswar-24
 Agenda
– Introduction
– Scrum in 100 words
– Functionality of Scrum
– Components of Scrum
• Scrum Roles
• The Process
• Scrum Artifacts
– Scaling Scrum
– Extreme Programming
Scrum in 100 words
• Scrum is an agile process that allows us to deliver the highest
business value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual working
software (every two to four weeks).
• The business sets the priorities. Scrum teams self-manage to
determine the best way to deliver the highest priority features.
• Scrum supports self-organizing teams.
• Here, the product progresses in a series of month-long
“Sprints”
• Requirements are captured as items in a list of “Product
Backlog”
• Every two weeks to four weeks anyone can see real working
software and decide to release it as it is or continue to enhance
for another iteration.
How Scrum Works?
Sprints
• Scrum projects make progress in a series of “Sprints”.

• Sprint is usually a month-long iteration, during which the

product functionality is enhanced.

• Target duration is one month (+/- a week or two)

• Product is designed, coded, and tested during the sprint

• NO outside influence can interfere with the Scrum team

during the Sprint.

• Each Sprint begins with the Sprint Planning.

No changes during the sprint

Change

Inputs Sprint Tested Code

• Plan sprint durations around how long you can commit to

keeping change out of the sprint
Scrum Framework
• Roles :
– Product Owner
– Scrum Master
– Scrum Team
• Ceremonies :
– Sprint Planning
– Daily Scrum Meeting
– Sprint Review
• Artifacts :
– Product Backlog
– Sprint Backlog
– Burndown Chart
Product Owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and prioritize every iteration, as needed
• Accept or reject work results.
The Scrum Master
• Represents management to the project
• Responsible for enacting Scrum values and practices
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
Scrum Team
• Typically, a team of 5-10 people
• Cross-functional
– Analysts, Designsers, Programmers, Testers, UI Designers,
QA etc.
• Members should be full-time
– May be exceptions (e.g., System Admin, etc.)
• Teams are self-organizing
• Membership can change only between sprints
Ceremonies: Sprint Planning Meeting

er

t
am

en
wn

s
er

m
Te
tO

ge
to
m
uc

a
s
ru

an
Cu
od

Sc

M
Product Backlog Pr

Team Capabilities
Sprint Goal
Sprint Planning
Business Conditions
Meeting Sprint Backlog
Technology

Current Product
Parts of Sprint Planning Meeting
• 1st Part:
– Creating Product Backlog
– Determining the Sprint Goal.
– Participants: Product Owner, Scrum Master, Scrum Team

• 2nd Part:
– Participants: Scrum Master, Scrum Team
– Creating Sprint Backlog

Note: A special form of Sprint Planning Meeting that happens

before the beginning of the Project.
Daily Scrum Meeting
• Parameters
– Daily
– 15-minutes
– Stand-up
– Not for problem solving
• Three questions:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?
• Is NOT a way to collect information about WHO is behind the
schedule
• Is a meeting in which team members make commitments to
each other and to the Scrum Master
• Is a good way for a Scrum Master to track the progress of the
Team
Few Scrum FAQs

• Why daily?
– “How does a project get to be a year late?”
• “One day at a time.”
– Fred Brooks, The Mythical Man-Month.

• Can Scrum meetings be replaced by emailed status reports?

– No
• Entire team sees the whole picture every day
• Create peer pressure to do what you say you’ll do
Sprint Review Meeting
• Team presents what it accomplished during the sprint

• Typically takes the form of a demo of new features or

underlying architecture

• Formal
– 2-hour prep time rule

• Participants
– Customers/Users
– Management
– Product Owner
– Other engineers
Artifacts: Product Backlog

• A list of all desired work on the project

• List is prioritized by the Product Owner
• Requirements for a system, expressed as a prioritized list of
Backlog Items
• Is managed and owned by a Product Owner
• Spreadsheet (typically)
• Usually is created during the Sprint Planning Meeting
• Can be changed and re-prioritized before each PM
Sample Product Backlog
 From Sprint Goal to Sprint Backlog
• Scrum team takes the Sprint Goal and decides what tasks are
necessary
• Team self-organizes around how they’ll meet the Sprint Goal
– Manager doesn’t assign tasks to individuals
• Managers don’t make decisions for the team
• Sprint Backlog is created
• Changes
– Team adds new tasks whenever they need to, in order to
meet the Sprint Goal
– Team can remove unnecessary tasks
– But: Sprint Backlog can only be updated by the team
• Estimates are updated whenever there is new information
Sprint Backlog
• A subset of Product Backlog Items, which define the work for
a Sprint
• Is created ONLY by Team members
• Each Item has its own status
• Should be updated every day
• No more than 300 tasks in the list
• If a task requires more than 16 hours, it should be broken
down
• Team can add or subtract items from the list. Product Owner is
not allowed to do it
Sample Sprint Backlog
Sprint Burn down Chart
Progress
• Depicts the total Sprint
Backlog hours remaining 900
800
per day 752 762
700
664
600 619
• Shows the estimated amount 500

Remaining Effort in Hours

400
of time to release 300 304
264
200 180
104
• Ideally should burn down to 100
20
0
zero to the end of the Sprint

• Actually, it is not a straight

Date
line
Scalability of Scrum
• A typical Scrum team is 5-10 people
• Jeff Sutherland - up to over 800 people
• "Scrum of Scrums" or what called "Meta-Scrum“
Pros:
 Completely developed and tested features in short
iterations
 Simplicity of the process
 Increasing productivity
 Self-organizing
 each team member carries a lot of responsibility
 Improved communication
 Combination with Extreme Programming
Cons
 “Undisciplined hacking” (no written documentation)
 Lack of authority may create an atmosphere of endless
debate whic ultimately affects the sprint.
 Self organizing team means engaging experienced staff
Extreme Programming
• Widely referred to as “XP”
• Proposed by Kent Back in 1999
• It is based on the fact that “Taking the best practices that
have worked well in the past in development projects
should be taken to the extreme levels.”
• Code Review: Its a good way to detect and correct problems
at the earliest. XP suggests “Pair Programming”.
• Testing: Testing helps to remove bugs and improves the
reliability. XP suggests “Test Driven Development”.
• Incremental Development: XP suggests that team should
come up with new increments every few days, rather than
doing all the development in one go.
• Encourages “Simplicity” in development.
Basic idea of XP
• XP is based on frequent releases called “iterations” during
which the developers implement “user stories”.

• A user story is a simplistic statement of a user about a

functionality, they need. It carefully avoids finer details like
different scenarios, the preconditions etc.

• Based on user stories, the team proposes “Metaphors”. It is a

common vision of “how the system would work”.

• The team also constructs a “Spike” which is actually like a

prototype. i.e. a proposed solution which may or may not be
the best one.
Contd..

• Design, Coding, Testing

• Listening
• Feedback
• Keeping the solution to a problem as simple as possible.
• Applicability of XP
– Innovative and research projects
– Smaller projects.
Selecting an appropriate SDLC model
• Characteristics of the software to be developed:
– For small projects, agile is favorable.
– Products or embedded software, iterative model may be
preferred.
– Object oriented projects is good with incremental model.
• Characteristics of the development team:
– for experienced team, embedded system can also be
developed in iterative waterfall.
– If the team is novice, then even a simple processing
application software may also need prototype model.
• Characteristics of the customer:
– If the customer is not quite familiar with computers, then
prototype model is suitable.