Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

An Introduction To: Agile Methodologies: SCRUM and XP

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 33

An

Introduction to
Agile Methodologies: SCRUM
and XP
Agenda
– Introduction
– What is Scrum?
– History of Scrum
– 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 focus on
delivering the highest business value in the shortest
time.

• It allows us to rapidly and repeatedly inspect actual


working software (every two weeks to one month).

• The business sets the priorities. Our teams self-manage


to determine the best way to deliver the highest priority
features.

• Every two weeks to a month anyone can see real


working software and decide to release it as is or
continue to enhance for another iteration.
Characteristics
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of “product
backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile environment for
delivering projects
• One of the “agile processes”
How Scrum Works?
Sprints
• Scrum projects make progress in a series of
“sprints”. Sprint is usually a month-long iteration,
during which the is product functionality is
enhanced in one increment.
• 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 Daily Scrum Meeting
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, ScrumMaster,


Team
• Ceremonies : Sprint Planning, Sprint
Review, Daily Scrum Meeting
• Artifacts : Product Backlog, Sprint
Backlog, and 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 5-10 people
• Cross-functional
– QA, Programmers, UI Designers, 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


• Sprint
• Daily Scrum
• Sprint Review Meeting
Spring Planning Meeting

Product Backlog

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
– Management
– Product Owner
– Other engineers
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
Sprint Backlog during the Sprint

• 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’s
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 it’s 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
• Depicts the total Sprint Backlog hours remaining
per day
• Shows the estimated amount of time to release
• Ideally should burn down to zero to the end of
the Sprint
• Actually is not a straight line
Sprint Burndown Chart

Progress

900
800
Remaining Effort in Hours

752 762
700
664
600 619
500
400
300 304
264
200 180
100 104
0 20

0 2 02 02 02 02 02 02 02 02 02 02 02 02 02 02
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
3 /2 5/2 7/2 9/2 1/2 3/2 5/2 7/2 9/2 1/2 3/2 5/2 7/2 9/2 1/2
5 / 5 / 5 / 5 / 5 /1 5 /1 5 /1 5 /1 5 /1 5 /2 5 /2 5 /2 5 /2 5 /2 5 /3

Date
Scalability of Scrum

• A typical Scrum team is 6-10 people


• Jeff Sutherland - up to over 800 people
• "Scrum of Scrums" or what called "Meta-
Scrum“
Pros/Cons
 Advantages  Drawbacks
 Completely developed  “Undisciplined hacking”
and tested features in (no written
short iterations
documentation)
 Simplicity of the
process  Lack of authority may
create an atmosphere
 Increasing productivity of endless debate whic
 Self-organizing ultimately affects the
 each team member sprint.
carries a lot of  Self organizing team
responsibility means engaging
 Improved experienced staff
communication
 Combination with
Extreme Programming
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.” i.e. If something is known to be
beneficial, then why not to use it on a constant
basis.
Practices to be taken upto Extreme
• 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.
• Charactristics 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.
Thank You !!!

You might also like