1. An Introduction
to Agile Scrum
By Sourav Mukherjee
6th Dec 2012

2. Expectations from this session
 What is scrum
 How can we use it in our projects
 Scrum benefits
 Scrum roles
 Scrum artifacts
 Scrum Daily Stand-up
 Scrum Planning
 Scrum Review & Retrospective
 Q&A

3. My expectations from you
• Let’s focus on Software Projects
• Keep away your day to day stuff for a while
• Listen with an open mind
 Consider yourself as a child who has a fresh mind
and is learning a new thing
 OR may be as someone who is offered a job to work
as a scrum master
• Don’t relate things to your work as you do it today – at
least during the theory session
• Don’t get stuck with the thought that it is all world of
dreams and not possible practically

4. What is Scrum?
• 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. Teams self-organize 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 it for another sprint.

5. Scrum has been used by

6. Scrum has been used for
 Commercial software  Video game development
 In-house development  Satellite-control software
 Contract development  Websites
 Fixed-price projects  Handheld software
 Financial applications  Network switching
applications

7. Characteristics
 Self-organizing teams
 Product progresses in a series of two-to four-week
“sprints”
 Requirements are captured as items in a list of “product
backlog”
 No specific engineering practices prescribed
 One of the “agile processes”

8. The Agile Manifesto
The Scrum Framework implements the cornerstones
defined by the agile manifesto
Individuals and
over Process and tools
interactions
Comprehensive
Working software over
documentation
Customer
over Contract negotiation
collaboration
Responding to
over Following a plan
change

9. Scrum Overview

10. What is a Sprint?
 In the Scrum Framework all activities needed for the
implementation of entries from the Scrum Product
Backlog are performed within Sprints (also called
'Iterations'). Sprints are always short: normally about 2-4
weeks.
 Each Sprint start with two planning sessions to define the
content of the Sprint: the WHAT-Meeting and the HOW-
Meeting. The combination of these two meeting are also
defined as Sprint Planning Meeting.
 In the WHAT-Meeting the Scrum Team commits to the User
Stories from the Scrum Product Backlog and it uses a
HOW-Meeting to break the committed User Stories into
smaller and concrete tasks. Then implementation begins.

11. Sequential vs. overlapping development
Requirements Design Code Test
Rather than doing all of one
thing at a time...
...Scrum teams do a little of
everything all the time

12. No changes during a sprint
Change
Plan sprint durations around how long you can commit to keeping
change out of the sprint

13. Scrum framework
Roles
•Product owner
•Scrum Master
•Team Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Task Board
•DoD
•Burndown charts

14. 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 priority every iteration, as needed
 Accept or reject work results

15. The Scrum Master
 Primary job is to remove impediments to the ability of
the team to deliver the sprint goal.
 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.

16. The team
 Typically 7-9 people
 Cross-functional:
◦ Programmers, testers, user experience designers, etc.
 Members should be full-time
◦ May be exceptions (e.g., database administrator)
 Teams are self-organizing
◦ Ideally, no titles but rarely a possibility
 Membership should change only between sprints

17. The WHAT and HOW Meeting
 (time-boxed: 8 hours)
 At the beginning of any Sprint (iteration 1-4 weeks), two half:
 * BackLog selection (WHAT to do)
 + Some of Product Backlog (user stories) will be chosen to
be (time-boxed: 8 hours)
 At the beginning of any Sprint (iteration 1-4 weeks), two half:
 * BackLog selection (WHAT to do)
 + Some of Product Backlog (user stories) will be chosen to
be Sprint Backlog.
 + Business value : is set by the Product Owner (client
representative).
 -> represents PRIORITY: how Important the story is to the client.
 + Development effort : is set by the Team.
 -> represents COMPLEXITY: how Hard to implement the story
according to the average developer’s experience.
 User Story: As a [USER] , I want [Feature X] so that [Y
satisfied]

18. Planning Task
 * Task estimation (HOW to do)
◦ + each user story is broken down into concrete tasks, and for
each task every group “votes” a number as “the estimated
points” for the task.
◦ + Planning poker cards: for displaying the “voted/estimated”
points. One task point is implicitly considered 1 man hour, for
simplicity. (note: some may use 1 man day for 1 story point).

19. Planning Estimation
 * Task estimation (HOW to do)
◦ + If the points from the groups for the task are
unanimous, or similarly (highest number is not higher than
1.5 the lowest number), the “final estimated points” is
determined and marked into the task.
◦ + If the points of the group are not similarly (see above),
the groups of highest number and lowest number will, in
turn, tell the team why they think their number is suitable.
After that all groups will re-estimate that task again. (this step
may be repeated several times until a compromise is reached)
◦ + Total estimated points for a story should not exceed a
predefined certain amount (20-40 man hours), otherwise the
story may either be labeled as “epic” to be broken into smaller
stories so as to not violate that limitation.

20. The Daily Stand-Up
 Time: short (usually 5-15 minutes)!
 It should start at the same time every working day (practically 15-
45 mins after start working time).
 Venue: near the collaboration space,
 i.e. near the Scrum taskboard enough to see the characters there.
 Agenda: Everybody tells others about his tasks, in 3 points:
 + What has he done since the previous stand-up ? (DONE’s
yesterday)
 + What is he planning to do today ? (DO’s today)
 + Is there any obstacle preventing him/her from doing what
he/she has planned ? (any IMPEDIMENT)

21. The Sprint Review Meeting
 Review meeting (time-boxed: 3-4 hours)
◦ internal showcase for whole team
◦ demonstrate what is being done
◦ direct feedback (incomplete features do not count)
 Typically takes the form of a demo of new features or underlying
architecture
 No slides
 Whole team participates
 Invite the world

22. The Sprint Retrospective
 Retrospective meeting (time-boxed: 2-3 hours)
 (All Scrum team members raise their opinions about the Sprint, in
3 topics)
◦ what we did well?
◦ what did not go well?
◦ which improvement should be applied right next Sprint?

23. What is a Product Backlog
 The requirements
 A list of all desired work on the project
 Ideally expressed such that each item has value to the
users or customers of the product
 Prioritized by the product owner
 Reprioritized at the start of each sprint

24. What is a Sprint Backlog
 Individuals sign up for work of their own choosing
 Estimated work remaining is updated daily
 Work for the sprint emerges
 If work is unclear, define a sprint backlog item with a larger amount
of time and break it down later
 Update work remaining as more becomes known

25. Sprint Task Board
User stories (with tasks) visible on a physical board.

26. The sprint Burndown chart
 Burn chart is a graphical representation of work left to do
versus time.
 tracking the team’s progress & predicting when tasks
will be completed
 how many story points the team can earn –
the velocity. It helps predict delivery times based on

27. Definition of Done (DoD)
In order to be able to decide when an activity from the Sprint
Backlog is completed, the Definition of Done (DoD) is used.
It is a comprehensive checklist of necessary activities that
ensure that only truly done features are delivered, not only in
terms of functionality but in terms of quality as well.
The DoD may vary from one Scrum Team to another, but must
be consistent within one team.
There might be different DoD at various levels:
◦ DoD for a Scrum Product Backlog item (e.g. writing code,
tests and all necessary documentation)
◦ DoD for a sprint (e.g. install demo system for review)
◦ DoD for a release (e.g. writing release notes)

28. Question?