The document provides an overview of Scrum, including its values, principles, roles, meetings, artifacts, and processes. The four values of the Agile Manifesto are listed, followed by the twelve principles. Scrum roles include the Product Owner, Scrum Master, and Development Team. Key Scrum events include the Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, and Retrospective meetings. Main artifacts are the Product Backlog, Sprint Backlog, and Sprint Burn Down Chart.

1. SCRUM OVERVIEW
Nilesh Harde
Scrum Master

2. 4 VALUES OF THE AGILE MANIFESTO
1. Individuals and interactions over processes
and tools
2. Working software over comprehensive
documentation
3. Customer collaboration over contract
negotiation
4. Responding to change over following a plan

3. 12 PRINCIPLES OF THE AGILE
MANIFESTO
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together
daily throughout the project.

4. 12 PRINCIPLES OF THE AGILE
MANIFESTO
5. Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

5. 12 PRINCIPLES OF THE AGILE
MANIFESTO
9. Continuous attention to technical excellence and
good design enhances agility.
10. Simplicity--the art of maximizing the amount of
work not done--is essential.
11. The best architectures, requirements, and
designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts
its behavior accordingly.

6. SCRUM ROLES
1. Product Owner
2. Scrum Master
3. Scrum Development Team

7. SCRUM ROLES – PRODUCT OWNER
1. Responsible for Return on Investment(ROI)
2. Responsible for product vision
3. Focused more on the what than on the how
4. Final arbiter of requirements questions
5. Constantly re-prioritizes the Product Backlog
6. Accepts or rejects each product increment
7. Managing the release plan

8. SCRUM ROLES – SCRUM MASTER
1. facilitator, coach, mentor
2. Protects the team from external interference and
distractions
3. Removes impediments
4. Helps the team become self-organizing
5. Enforces Time Boxes
6. Promotes Improved engineering practices
7. Has no management authority

9. SCRUM ROLES – SCRUM DEVELOPMENT
TEAM
1. Cross-functional group
2. Attempts to build a ‘potentially shippable
product increment’ every sprint
3. Collaborates
4. Self-organizing
5. 7+/- 2 members

10. SCRUM MEETING
1. Backlog Refinement Meeting
2. Sprint Planning Meeting
3. Daily Scrum Meeting
4. Sprint Review Meeting
5. Sprint Retrospective Meeting

11. Backlog Refinement
Meeting
Sprint Planning
Meeting
Daily Scrum
Meeting
Sprint Review
Meeting
Sprint Retrospective
Meeting

12. BACKLOG REFINEMENT MEETING
• Participants : Product Owner, Team, Scrum
Master
• Duration: < 10% of Capacity of Team;
2 Weeks Sprint – 1 day
• Decomposition of large Product Backlog
Items(PBIs) into smaller ones (e.g. epics to user
stories)
• Clarification of requirement
• Estimation of effort

13. SPRINT PLANNING MEETING
• Participants : Product Owner, Team, Scrum Master
• Duration: < 10% of Capacity of Team;
2 Weeks Sprint – 4 hours
When : At the beginning of each Sprint
• Agree to Sprint goals and negotiate which items from
Product Backlog will be committed to the Sprint
Backlog
• Team will come up with an initial list of tasks
necessary to complete the committed PBIs

14. SPRINT PLANNING MEETING
• 2 Part Meeting
• Sprint Planning Part 1 (”what”)– for committing to
Product Backlog items (PBIs)
• Sprint Planning Part 2 (“how”)– for coming up
with tasks.
• DONE
 Tested
 Refactored
 Potentially shippable

15. DAILY SCRUM MEETING
• Participants : Development Team, Scrum Master,
Product Owner (optional)
• Duration: 15 minutes each day
• Daily Scrum 3 Questions
1. What did I do yesterday?
2. What will I do today?
3. What impediments I faces?

16. DAILY SCRUM MEETING
Tracking Progress during the Sprint
 Every day, the Team members update their estimate of the effort remaining
to complete their current work in the Sprint Backlog.
Initial Estimate
of Effort
0 1 2 3 4 5 6
modify datababase Nilesh 5 4 3 0 0 0
create webpage (UI) Uday 3 3 3 2 0 0
create webpage (javascript logic) Uday & Radhika 2 2 2 2 1 0
write automated acceptance tests Reshma 5 5 5 5 5 0
update buyer help webpage Nilesh & Reshma 3 3 3 3 3 0
merge DCP code and complete layer-
level tests 5 5 5 5 5 5
complete machine order for pRank 3 3 3 3 5 5
change DCP and reader to use pRank
http API 5 5 5 5 5 5
Improve trasaction
processing
performance
Daily Updates of Work Remaining on the Sprint Backlog
Product Backlog Item Sprint Task Volunteer
New Estimates o
Remaining at end
As a buyer, I want to
place a book in a
shopping cart

17. DAILY SCRUM MEETING
Sprint Burn down Chart
It is also common for someone to add up the effort remaining for the
Team as a whole, and plot it on the Sprint Burn down Chart. Graph
shows, each day, a new estimate of how much work remains until the
Team is finished.
If the burn down line is not tracking downwards towards completion
near the end of the Sprint, then the Team needs to adjust, such as to
reduce the scope of the work or to find a way to work more effectively
while still maintaining a sustainable pace.

18. DAILY SCRUM MEETING
50 49 48
44 43
34
0
10
20
30
40
50
60
0 1 2 3 4 5 6 7 8 9 10
NewEstimateofWorkRemaining
Day
Sprint Burndown Chart

19. SPRINT REVIEW MEETING
• Participants : Product Owner, Development
Team, Scrum Master, Other Stakeholders
• Duration: 2 hours for 2 weeks Sprint
• When: At the end of Sprint
• Agenda
1. Product Demonstration
2. Product Owner declares what’s done
3. Measure Velocity ( optional )
4. Stakeholder feedback

20. PRODUCT BACKLOG
• Example
• As a <student>, I can <see my previous semester grades
online> so that <I don’t have to wait until I get to school to
know my previous grades>
• Acceptance Criteria: Columns align neatly on FingerFly
4.1 and JPhone
• EFFORT : SMALL

21. SCRUM USER STORIES
 Format
As an [actor], I [want|must] [action] so that [achievement]
Or in a shorter version:
As an [actor], I [want|must] [achievement]
 Example
• As a <customer> I want to <see the catalogue of saleable
items> so that <I can order one of them>
• As an <administrator> I want <be able to disable
accounts>

22. VELOCITY
Measure Velocity
• PBIs declared as done are one Medium ( 4 Story Points),
one Small( 2 Story Points ) and one Small( 2 Story Points)
• Using relative sizing numbers, velocity works out to 8 story
points the Sprint
• PBIs DONE or Velocity = 4 + 2 + 2 = 8 Story Points
• If velocity stays stable for serval sprints it may eventually
help you forecast how far down the Product Backlog you’ll
get before the release date.

23. SPRINT RETROSPECTIVE MEETING
• Participants : Development Team, Scrum Master,
Product Owner (Optional)
• Duration: 1.5 hours for 2 weeks Sprint
• When: At the end of Sprint ( after Sprint Review)
• Sprint Review meeting involves inspect and
adapt regarding the product.
• Sprint Retrospective involves inspect and adapt
regarding the process and environment.

24. SPRINT RETROSPECTIVE MEETING
Purpose
 Inspect how the last Sprint went with regards to
people, process, and tools.
• Identify and order the major items that went well
and potential improvements.
• Create a plan for implementing improvements to
the way the Scrum Team does its work.

25. SPRINT RETROSPECTIVE MEETING
• By the end of the Sprint Retrospective, the Scrum
Team should have identified improvements that it
will implement in the next Sprint. Implementing
these improvements in the next Sprint is the
adaptation to the inspection of the Scrum Team
itself.

26. SCRUM ARTIFACTS
1) Product Backlog
2) Sprint Backlog
3) Sprint Burn down Chart

27. PRODUCT BACKLOG
 List of desired functionality
 Visible to all stakeholders
 Any stakeholder can add items
 Constantly re-prioritized by Product Owner
 Items at top are more granular than items at
bottom
 Maintained during the Backlog Refinement
Meeting

28. PRODUCT BACKLOG ITEM(PBI)
 Specifies the what more than the how of a
customer centric feature
 Often written in User Story form
 May have item-specific acceptance criteria
 Effort is estimated by the tem, in relative units
(e.g. story points)
 Effort is roughly 2-3 people 2-3 days
Account lockout after three
attempts
Acceptance Criteria: ....
Small

29. SPRINT BACKLOG
 Consists of committed PBIs negotiated between the
team and the product owner during Sprint Planning
Meeting
 Scope commitment is fixed during Sprint Execution
 Initial task are identified by the team during Sprint
Planning Meeting
 Team will discover additional tasks needed to meet the
fixed scope commitment during Sprint execution
 Visible to team
 Referenced during the Daily Scrum Meeting

30. SPRINT BACKLOG

31. SPRINT TASK
 Specifies how to achieve the PBIs what
 Requires one day or less of work
 Remaining efforts is re-estimated daily, typically in
hours
determine requirements for password policy
page layout(design)
get latest JBoss running
choose persistence strategy(Hibernate?)
write code(using test driven development)
exploratory testing

32. SPRINT BURN DOWN CHART
 Indicates total remaining team task hours within
one Sprint
 Re-estimated daily