2. Manifesto for Agile Software Development
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items
on the right, we value the items on the left more.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• What this is about
– Conceptual understanding of Scrum
– Understanding of the overall Scrum process
– Understand how the essential Scrum roles work together with the
• What this is not
– Comparison with another methodologies/framework
– How to implement Scrum in Verizon
– Scrum Experiences Implementation
When is Scrum appropiate?
8. What’s SCRUM?
• Scrum is not a Methodology. Scrum is a Framework for
surfacing organizational dysfunction.
• Scrum is an iterative incremental, agile software
• Scrum doesn’t provide answers. It helps you ask better
• Scrum doesn’t actually do anything. People do things.
• Scrum seeks to optimize overall progress by making
10. When is Scrum Appropriate?
• Scrum works best when the
problems to be solved lie in
the Complex Space.
• New Product Development
Work and Knowledge Work
both tend to exist in the
• Research lies in the Chaos
• Maintenance lies in the
• Product Backlog
– Living list of Requirements
– Broken Down into User Stories
– The WHAT of the product
– ROI Prioritized
• Sprint Backlog
– Committed Backlog: A list of
tasks representing the HOW
of the system
• Release Burndown
– Amount of Work Remaining for a Release
– Basis of measurement: Story Points or
– Level and usage: Project level
• Sprint Burndown
– Amount of Work Remaining for a Sprint
– Basis of measurement: Effort hours
– Level and usage: Sprint level
• Velocity Trend
– How much work the team can expect to complete based on prior efforts.
– Basis of measurement: Story points or “ideal engineering hours”
– Level and usage: most useful at the project level.
• The ScrumMaster is responsible for ensuring that the Scrum Team
adheres to Scrum values, practices, and rules.
• The ScrumMaster helps the Scrum Team understand and use self-
management and cross-functionality.
• The ScrumMaster should never be the Product Owner.
• The Product Owner is the one and only person responsible for
managing the Product Backlog
• There are no titles on Teams, and there are no exceptions to this
rule. Teams do not contain sub-Teams dedicated to particular
domains like testing or business analysis, either.
• Teams are self-organizing. No one – not even the ScrumMaster –
tells the Team how to turn Product Backlog into increments of
• Group of people working together very closely and self
• Incentivizes changing requirements
• Timeboxing creates the rhythm that drives development
• Delivering items of highest value to the Customer First
– Don’t waste time developing something that the Customer may
SCRUM in under 10 Minutes (HD) by @hamids
SCRUM GUIDE By Ken Schwaber, May, 2009
SCRUM Development Process by Ken Schwaber
Hyperproductive Distributed Scrum Teams
Agile Estimation / Planning
SCRUM Alliance http://www.scrumalliance.org/