1. SCRUM
Overview and step by step guide to
Agile Development
at Micro, Small & Medium Enterprises
Workshop , Chennai
- Syed Nazir Razik

2. About :
Managing Partner at Fuente Systems Inc
Co Founder of The Knowledge Foundation and
powering up events like PROTO, Barcamp Chennai,
Blogcamp , MoMo Chennai, SearchCamp,
WikiCamp so on
Serial Entrepreneur and been involved with many
organizations like Mecosoft, Numeric Fuente,
Kondagan, Fortuna Tech in creating value.
Technology Adviser for some organizations like
Shamail IT, Fashion Media abroad
NiXi Fellow on Internet Governance creating
awareness on issues like Intellectual Property rights.
ISOC Chennai Chapter campion on Online Child
Safety.
PMP – Project management Professional since
2005
CSM – Scrum practitioner since 2007

3. The Basics of Scrum
S c rum D a ily S c rum
M a s ter M eeting
4-W eek
S print
R eview
P ro duc t O w ner T he T ea m
11
Commitment
22
33
44
P o tentia lly
5
No Changes S hippa ble
6
7
P ro duc t
8
(in Duration or Deliverable)
9
10
11
12
13
R etro s pec tive

4. SCRUM – the SCRUM methodology coined by Ken Schwaber at 1996
OOPSLA ( http://jeffsutherland.com/oopsla/schwaber.html )

5. The Stakeholders of Scrum
S c rum D a ily S c rum
M a s ter M eeting
4-W eek
S print
R eview
P ro duc t O w ner T he T ea m
1
Commitment
2
3
4
P o tentia lly
5
No Changes S hippa ble
6
7
P ro duc t
8
(in Duration or Deliverable)
9
10
11
12
13
R etros pec tive

6. The PRODUCT OWNER – Stakeholder #1
Responsible for the overall project vision and goals

Responsible for managing project ROI vs. risk

Responsible for taking all inputs into what the team

should produce, and turning it into a prioritized list (the
Product Backlog)
Participates actively in Sprint Planning and Sprint

Review meetings, and is available to team throughout
the Sprint
Determines release plan and communicates it to upper

management and the customer

7. The TEAM – Stakeholders # 2
T he T ea m
7 people, + or – 2

Has worked with as high as 15, as few as 3

Can be shared with other teams (but better when not)

Can change between Sprints (but better when they don’t)

Can be distributed (but better when colocated)

Cross-functional

Possesses all the skills necessary to produce an increment

of potentially shippable product
Team takes on tasks based on skills, not just official “role”

Self-managing

Team manages itself to achieve the Sprint commitment


8. The SCRUM Master – Stakeholder # 3 S c rum
M a s ter
The Scrum Master does everything in their power to help the
team achieve success
This includes:
1. Serving the team
The ScrumMaster takes action to help remove impediments to the team’s effectiveness
The ScrumMaster facilitates the team’s group interactions, to help the team achieve its
full potential
2.Protecting the team
The ScrumMaster protects the team from anything that threatens its effectiveness, such
as outside interference or disruption
The ScrumMaster will need to confront uncomfortable issues, both inside and outside the
team
3.Guiding the team’s use of Scrum
The ScrumMaster teaches Scrum to the team and organization
The ScrumMaster ensures that all standard Scrum rules and practices are followed

9. What The SCRUM MASTER doesn't do ?
S c rum
M a s ter
The ScrumMaster does not manage the team
The ScrumMaster does not direct team-members
The ScrumMaster does not assign tasks
The ScrumMaster does not “drive the team” to hit its
goals
The ScrumMaster does not make decisions for the team
The ScrumMaster does not overrule team-members
The ScrumMaster does not direct product strategy,
decide technical issues, etc.

10. Manager 's New Roles at Agile as SCRUM Master
Decide task assignments among the Provide coaching and mentorship to
team members and assign them team-members
Keep track of whether team-members Surface issues to the team that they
have done the tasks I’ve assigned to might overlook – scaling, performance,
them security, etc.
Make commitments on behalf of the Provide input on features, functionality,
team about how much they can get and other aspects of what’s being
done by X date produced
Give direction to the team on how to do Do performance evaluations and provide
the work, so they can meet the feedback to team-members
commitment I made
Convince team that the commitments Provide advice and input to the team on
made on their behalf are attainable difficult technical issues that come up
Monitor the team's progress, to make Plan training for team, and do career-
sure they stay on schedule, and aren't development and planning with team-
having problems members
Conduct weekly update and 1:1 Stay abreast of latest developments in
meetings with team, to surface issues, the technology their team uses, industry
and provide direction news, etc.
Recruit, interview and hire new Plan and oversee budgets and financials,
members of the team and think about tools, skills and other
future needs
Fire team-members who are consistently Help remove impediments that the team
not able to perform is not able or well-placed to resolve
themselves

11. The Basics of Scrum
S c rum D a ily S c rum
M a s ter M eeting
4-W eek
S print
R eview
P ro duc t O w ner T he T ea m
1
Commitment
2
3
4
P o tentia lly
5
No Changes S hippa ble
6
7
P ro duc t
8
(in Duration or Deliverable)
9
10
11
12
13
R etros pec tive
Product Backlog

12. Product Backlog
Product Owner lists
items in descending
order of priority (highest
priority item is listed
first, next-highest is
second, etc.)
Size estimates are rough
estimates (can either be
arbitrary “points”, or
“ideal days”)

13. Product Backlog
List of everything that could ever be of value to

the business for the team to produce
Ranked in order of priority

Priority is a function of business value versus risk

Product Owner can make any changes they

want before the start of a Sprint Planning
Meeting
Items added, changed, removed, reordered

How much documentation is up to the team

and Product Owner to decide
The farther down the list, the bigger and less

defined the items become
~2 Sprints worth are defined in detail


14. Sprint Planning Meeting of
Scrum
S c rum D a ily S c rum
M a s ter M eeting
4-W eek
S print
R eview
P ro duc t O w ner T he T ea m
1
Commitment
2
3
4
P o tentia lly
5
No Changes S hippa ble
6
7
P ro duc t
8
(in Duration or Deliverable)
9
10
11
12
13
R etro s pec tive
Product Backlog

15. Sprint Planning Meeting of
Scrum
Takes place before the start of every Sprint
Team decides how much Product Backlog it will commit to
complete by the end of the Sprint, and comes up with a
plan and list of tasks for how to achieve it
What’s a good commitment?
Clearly understood by all
Shared among the team
Achievable without sacrificing quality
Achievable without sacrificing sustainable pace
Attended by Team, Product Owner, ScrumMaster,
Stakeholders
May require 1-2 hours for each week of Sprint duration
2 week Sprint = 2-4 hours, 4 week Sprint = 4-8 hours

16. Sprint Planning
− Team understands the Sprint
details of what the Product Pre-Planning
Owner has prioritized on
Meeting
the Product Backlog
− Team decides how
much productive
time it has available
during the Sprint Sprint
Planning
− Team decides how
many Product Backlog Meeting
items it can commit
to complete during
the Sprint

17. Sprint Cycle: 2-Week Sprint
Mon Tues Weds Thurs Fri
1 2 3
6 7 8 9 10
Sprint
First Day
1 2 3 4
Planning
of Sprint
Meeting
13 14 15 16 17
Last Day
5 6 7 8 Sprint Review
of Sprint & Retrospective
20 21 22 23 24
Sprint
Planning
Meeting
27 28 29 30 31

18. Available Time During Sprint
Sprint Length 2 weeks
Workdays During 8 days
Sprint
Team Member Avail Days Avail Hours Total Avail
During Per Day Hrs in Sprint
Sprint*
Tracy 8 4 32 (8 * 4)
Sanjay 7 5 35 (7 * 5)
Phillip 8 3 24 (8 * 3)
Jing 5 5 25 (5 * 5)

19. The Sprint Backlog
Day of
Sprint
Backlog Task Owner Initial Est. 1 2 3 4 5 6
Item
Enable all users Design business logic Sanjay 4
to place book in
shopping cart
Design user interface Jing 2
Implement back-end Tracy 2
code
Implement front-end Tracy 6
code
Complete Joe 8
documentation
Unit testing Philip 4
Regression testing Philip 2
Upgrade Implement back-end Tracy 5
transaction code
processing
module
Complete Joe 6
documentation
Unit testing Philip 3
Regression testing Philip 3

20. The Sprint
Sprint Length -4 weeks is standard in literature
Many teams start with 2 week Sprints
Factors in deciding your Sprint length
Length of the release
Amount of uncertainty
How long priorities can stay unchanged
Overhead of Sprint Planning and Review
Team and Product Owner work together to decide
Sprint length
Can change during the project

21. Burndown Chart

22. The Sprint Review of Scrum
S c rum D a ily S c rum
M a s ter M eeting
4-W eek
S print
R eview
P ro duc t O w ner T he T ea m
1
Commitment
2
3
4
P o tentia lly
5
No Changes S hippa ble
6
7
P ro duc t
8
(in Duration or Deliverable)
9
10
11
12
13
R etro s pec tive

23. The Sprint Review of Scrum
Purpose of the Sprint Review is
Demo what the team has built
Generate feedback, which the Product Owner can incorporate in
the Product Backlog
Attended by Team, Product Owner, ScrumMaster,
functional managers, and any other stakeholders
A demo of what’s been built, not a presentation about
what’s been built
no Powerpoints allowed!
Usually lasts 1-2 hours
Followed by Sprint Retrospective

24. The Sprint Retrospective
S c rum D a ily S c rum
M a s ter M eeting
4-W eek
S print
R eview
P ro duc t O w ner T he T ea m
1
Commitment
2
3
4
P o tentia lly
5
No Changes S hippa ble
6
7
P ro duc t
8
(in Duration or Deliverable)
9
10
11
12
13
R etro s pec tive

25. The Sprint Retrospective
What is it?
1-2 hour meeting following each Sprint Demo
Attended by Product Owner, Team, Scrum Master
Usually a neutral person will be invited in to facilitate
What’s working and what could work better
Why does the Retrospective matter?
Accelerates visibility
Accelerates action to improve

26. Scrum Release Cycle
2 Common Approaches:

Multi-Sprint Release RELEASE
SPRINT
SPRINT SPRINT
SPRINT SPRINT SPRINT
Release Every Sprint
RELEASE RELEASE RELEASE RELEASE RELEASE RELEASE
SPRINT SPRINT SPRINT
SPRINT SPRINT SPRINT

27. Scrum Disadvantages
It’s hard!

Makes all dysfunction visible

− Scrum doesn’t fix anything: the team has to do it
− Feels like things are worse at the beginning
Bad products will be delivered sooner, and doomed

projects will fail faster
High risk of turnover

− Some people will refuse to stay on a Scrum team
− Some people will refuse to stay if Scrum is abandoned
Partial adoption may be worse than none at all

If adoption fails, time will have been wasted, and

some people may leave

28. SCRUM – Fuente Flavour
Source : http://wordpress.fuentesystems.com/?p=21
http://www.scrumalliance.org/resources

29. syed@proto.in
+919884208327
Search “ Syed Nazir Razik “