Scrum is an agile framework for managing software development projects, characterized by short development cycles called sprints, daily stand-up meetings, and emphasis on self-organizing cross-functional teams. Key roles include the product owner, who prioritizes features; the scrum master, who facilitates the process; and the development team. Scrum uses artifacts like the product backlog, sprint backlog, and burndown charts to track progress. Ceremonies like sprint planning, daily scrums, sprint reviews, and retrospectives promote inspection and adaptation.

1. Scrum Basic
Understanding
Toufiq Mahmud Tushar
Senior Software Engineer – Augmedix

2. Outline
• Scrum Overview
• Scrum Origin
• Agile Manifesto
• Scrum Roles
• Scrum Ceremonies
• Scrum Artifacts
• Scrum of Scrum

3. Scrum
An Empirical Process for Maximizing ROI of Software Development
Projects

4. Empirical Process
• Visibility: those aspects of the process that affect the
outcome must be visible to those controlling the process.
• Inspection: those aspects of the process that affect the
outcome must be inspected frequently enough that
unacceptable variances in the process can be detected.
• Adaptation: If the inspector determines from the inspection
that one or more aspects of the process are outside
acceptable limits and that the resulting product will be
unacceptable, the inspector must adjust the process or the
material being processed.

5. Visibility
What is the actual (not ideal) relationship between these aspects
and the outcome?
• Design Artefacts
• Spike Solutions
• Test Frameworks
• Automated Tests
• Design patterns and coding standards
• Product Increments

6. Inspection
• What is the actual (not ideal) relationship between these aspects and
the outcome?
• Design Artefacts
• Spike Solutions
• Test Frameworks
• Automated Tests
• Design patterns and coding standards
• Product Increments
• How do you inspect these aspects?

7. Adaptation
• Adjust the process or the material being processed
• Making decisions based on information that was not known at the
outset of the project
• Refusing to decide is a decision: the team accepts accountability for
averting disaster by managing priorities

8. Scrum is Defined
• Is an agile, lightweight process
• Can manage and control software and product development
• Uses iterative, incremental practices
• Has a simple implementation
• Increases productivity
• Reduces time to benefits
• Embraces adaptive, empirical systems development
• Is not restricted to software development projects

9. Scrum has a mindset
• Scrum is commitment-oriented: You’ll be introduced to chickens
later.
• Scrum is results-oriented: projects produce increments of a
shippable product, activities are time boxed, and ceremony is
discouraged.
• Scrum is disciplined. There are practices you must follow on a
specified time table.

10. 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”

11. Scrum origins
• Jeff Sutherland
• Initial scrums at Easel Corp in 1993
• IDX and 500+ people doing Scrum
• Ken Schwaber
• ADM
• Scrum presented at OOPSLA 95 with Sutherland
• Author of three books on Scrum
• Mike Beedle
• Scrum patterns in PLOPD4
• Ken Schwaber and Mike Cohn
• Co-founded Scrum Alliance in 2002, initially
within the Agile Alliance

12. Scrum has been used by:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce

13. Agile Manifesto
Process and tools
Individuals and
interactions
over
Following a plan
Responding to
change
over
Comprehensive
documentation
Working software over
Contract negotiation
Customer
collaboration
over

14. Scrum

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

16. Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Product owner
•ScrumMaster
•Team
Roles

17. Scrum Roles
• Product Owner
• Possibly a Product Manager or Project Sponsor
• Decides features, release date, prioritization, $$$
• Scrum Master
• Typically a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Remove impediments / politics, keeps everyone productive
• Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• Membership should change only between sprints

18. 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

19. The Scrum Master
• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences

20. The team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g. database administrator)

21. The team
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between sprints

22. •Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies

23. Very Small Exposure
Requires Very Little
Ceremony

24. Sprints
• Scrum projects make progress in a series of “sprints”
• Analogous to Extreme Programming iterations
• Typical duration is 2–4 weeks or a calendar month at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the sprint

25. The Sprint Planning Meeting
• Product Owner describes highest priority features to the Team.
• Team decides what the can commit to delivering in the Sprint.
• For a one month or four-week sprint this meeting should last eight
hours.
• For a two-week sprint, plan for about four hours.
• General rule of thumb, multiply the number of weeks in your sprint
by two hours to get your total sprint planning meeting length.
• The Sprint Planning Meeting is typically broken into two parts.

26. Part One: Four Hours (One Month Sprint)
• The Product Owner selects the ideal backlog for the coming Sprint
and communicates its meaning and importance to the team.
• Chickens may be invited to provide clarification, but they are
immediately dismissed.
• Team may ask questions.

27. Part Two: Four Hours (One Month Sprint)
• The Team decides how much it can commit to delivering in the
coming Sprint.
• The Product Owner answers questions but does not direct the team’s
choices. No chickens allowed.
• The outcome is the Sprint Backlog.

28. Daily Scrum Meeting
• Parameters
• Daily, ~15 minutes, Stand-up
• Everyday at constant time
• Not for problem solving
• Whole world is invited
• Only team members, Scrum Master, product owner, can talk
• Helps avoid other unnecessary meetings
• Three questions answered by each team member:
1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?

29. The sprint review
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying
architecture
• Informal
• One hour for one week sprint.
• No slides
• Whole team participates
• Invite the world

30. Sprint retrospective
• Periodically take a look at what is and is not working
• 45 minutes for each week of Sprint duration.
• Done after every sprint
• Whole team participates
• Scrum Master
• Product owner
• Team
• Possibly customers and others

31. Everyone answers 3 questions
• These are not status for the ScrumMaster
• They are commitments in front of peers
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3

32. •Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts

33. Scrum's Artifacts
• Scrum has remarkably few artifacts
• Product Backlog
• Sprint Backlog
• Burndown Charts
• Can be managed using just an Excel spreadsheet
• More advanced / complicated tools exist:
• Expensive
• Web-based – no good for Scrum Master/project manager who travels
• Still under development

34. Product Backlog
• The requirements
• A list of all desired work on
project
• Ideally expressed as a list of user
stories along with "story points",
such that each item has value to
users or customers of the product
• Prioritized by the product owner
• Reprioritized at start of each
sprint
This is the
product backlog

35. Sample Product Backlog
Backlog item Estimate
Allow a guest to make a reservation 3 (story points)
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-
per-available-room)
8
Improve exception handling 8
... 30
... 50

36. User Stories
• Instead of Use Cases, Agile project owners do "user stories"
• Who (user role) – Is this a customer, employee, admin, etc.?
• What (goal) – What functionality must be achieved/developed?
• Why (reason) – Why does user want to accomplish this goal?
As a [user role], I want to [goal], so I can [reason].
• Example:
• "As a user, I want to log in, so I can access subscriber content."
• story points: Rating of effort needed to implement this story
• common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.

37. Estimation
• Playing Poker
• T-Shirt Sizes

38. Estimation – Playing Poker
• Each team member is given a set of cards with numbers on them.
• The numbers are usually ordered from 0 to 21 using the Fibonacci
sequence: 0, 1, 2, 3, 5, 8, 13, and 21.
• Then each story is read aloud by PO.
• After each story is presented, everybody on the team is asked to hold
up the card showing the level of effort that they believe this story
represents for the team.
• Once all the votes are in, the team members with the lowest and
highest estimates explain why they chose their scores.
• Once all the votes are in, the team members with the lowest and
highest estimates explain why they chose their scores.
• Stories estimated at 20 or higher may be so large that they need to
broken up into smaller stories before they can be attempted.

39. Sprint Backlog
• Individuals sign up for work of their own choosing
• Work is never assigned
• Estimated work remaining is updated daily
• Any team member can add, delete change sprint backlog
• 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

40. Sample Sprint backlog
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the Foo class
Mon
8
16
8
12
8
Tue
4
12
16
8
Wed Thu
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8

41. Sprint Burndown Chart
• A display of what work has been completed
and what is left to complete
• one for each developer or work item
• updated every day
• (make best guess about hours/points completed each day)
• variation: Release burndown chart
• shows overall progress
• updated at end of each sprint

42. Sample Burndown ChartHours

43. Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Mon
8
16
8
12
Tue Wed Thu Fri
4
12
16
7
11
8
10
16 8
50

44. The Sprint Burndown Chart

45. The Product Increment
• Delivers measurable value
• “Potentially Shippable”: the process can be halted after every Sprint
and there will be some value, some ROI
• Must be a product, no matter how incomplete

46. Scalability
• Typical individual team is 7 ± 2 people
• Scalability comes from teams of teams
• Factors in scaling
• Type of application
• Team size
• Team dispersion
• Project duration
• Scrum has been used on multiple 500+ person projects

47. Scaling: Scrum of Scrums

48. Scrum vs. Other Models

49. Credits, References
• Mike Cohn, Mountain Goat Software
www.mountaingoatsoftware.com
• Scrum and The Enterprise by Ken Schwaber
• Succeeding with Agile by Mike Cohn
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Software Development with Scrum by K. Schwaber and M.
Beedle
• User Stories Applied for Agile Software Development by Mike Cohn
• www.agilescrum.com/
• www.objectmentor.com
• jeffsutherland.com/
• www.controlchaos.com/scrumwp.htm
• agilealliance.com/articles/articles/InventingScrum.pdf

50. Thanks