This document provides an overview of agile principles and the Scrum framework. It discusses the history and development of agile methodologies from the 1970s to present day. Key topics covered include the Scrum roles of Product Owner, ScrumMaster, and Development Team, as well as Scrum events such as Sprint Planning, Daily Scrum, Sprint Review, and Retrospective. The document contrasts traditional plan-driven and agile approaches to software development.

2. • Introduction to agile principles
• Scrum framework overview
• Further (and related) topics

4. - Managing the - A Spiral Model of - Dynamic Systems - XP was gained
1990s
1970s
1980s
2000s
Development of Software Development “momentum”.
Large Software Development and Methodology - Adaptive Software
Systems by Dr. Enhancement by (DSDM). Development by Jim
Winston W. Royce. Barry Boehm. - Crystal Highsmith.
- Evolutionary - The Mythical Man Methodologies by - Agile Manifesto.
processes process Month by Fred Alistair Cockburn.
introduced by Tom Brooks. - Agile methodologies
- First toughts and and practicies
Gilb. - PeopleWare by testing on Scrum for growing significantly
DeMarco and Lister. SW projects by Jeff in the market.
- Scrum roots on the S. And Ken S.
NNPDG article by - Origins of Extreme
Takeuchi and Programming (XP)
Nonaka. from Kent Beck.
- RUP Objectory v1.0 - Feature Driven
- Capability Maturity Development by
Model (CMM) and Peter Coad and Jeff
Managing the De Luca.
Software Process
book by Watts
Humphrey's.

5. 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.
reference: http://agilemanifesto.org

6. Welcome changing Deliver working
Our highest priority is to requirements, even late in software frequently, Business people and
satisfy the customer development. Agile from a developers must
through early and continuous processes harness change
delivery couple of weeks to a couple work
for of months, with a together daily throughout
of valuable software the customer's competitive preference to the shorter the project
advantage timescale
Build projects around The most efficient and Agile processes promote
motivated individuals. effective method of sustainable
Give them the environment conveying information to and Working software is development.
and support they need, within a development the primary measure The sponsors, developers,
and trust them to get the team is face-to-face of progress and users should be able
conversation to maintain a constant pace
job done indefinitely
Continuous attention to The best architectures,
technical Simplicity--the art of requirements, and
At regular intervals, the team
reflects on how
maximizing the amount designs
excellence of work not done--is
to become more effective,
and good design emerge from self- then tunes and adjusts
enhances agility
essential organizing teams its behavior accordingly
reference: http://agilemanifesto.org

7. Far from
agreement
Here’s where
Requirements
Scrum Excels
Close to
agreement
Close to Technology Far from
certainty certainty
reference: adapted from schwaber, 2003

8. I know all details about End with all
where I should go (start requirements Plan-Driven
with plan and all completed
requirements)
Inspect and adapt
I know what is the
End with Vision and $$
product/project vision Value-Driven
Goals met
(start with goals and
some priority
requirements)
reference: adapted from schwaber, 2003

9. Traditional Agile
Fixed Requirements Resources Schedule
Value/Vision
Driven
Plan-Driven
Variable Resources Schedule Requirements
reference: sliger & broderick, 2008

11. “THE PERSON WHO KNEW THAT
HER SON/DAUGHTER COULD
HAVE MARRIED BETTER, AND
WHO INTENDS TO HELP YOU BE
GOOD ENOUGH. YOU HAVE
JUST INVITED HER TO COME
LIVE WITH YOU”
– KEN SCHWABER

12. • Co-created by Jeff Sutherland and
Ken Schwaber
• Inspirations comes from Japanese
manufacturing (and the HBR article
“The New New Product Development
Game“ from Hirotaka Takeuchi and
Ikujiro Nonaka, published in 1986) Ken Schwaber and Jeff Sutherland
- Scrum Fathers

13. • Grounded in empirical process control theory, employs
an iterative, incremental approach to optmize
predictability and control risk
• Is about
– Transparency
– Inspection
– Adaptation

14. • Scrum teams and associated roles
• Time-boxes
• Artifacts
• Rules

15. • Product Owner
• ScrumMaster
• Scrum Team Manager Stakeholders...
ScrumMaster
Product Owner
Scrum Team
User
Customer

17. • Define the features of the product
• Decide on release dates and contents
• Responsible for the profitability (ROI)
• Prioritize features according to market value
• Adjust priorities at every Sprint, as needed
• Accept or reject work results
• Is one person, not a committee “ROI = $$ and I like that!
Nice to meet you, Im the PO”

19. • Ensures that the team is fully functional and productive
• Enable close cooperation across all roles
and functions
• Remove barriers
• Shield the team from external interferences
• Ensure that the process is followed
• Review and Sprint Planning meetings “The sheepdog for the team”

20. • Cross functional. Organizes itself and its work
• Team members must have all necessary skills to
create an increment of work
• Everyone chips in, even if that requires learning
new skills or remembering old ones
• 5 - 9 team members
• Has the right to do everything within the
boundaries of the project guidelines to reach the
Sprint goal Multi-skill ninja team
• Demonstrates work results to the Product Owner

21. • Release Planning Meeting
• Sprint
• Sprint Planning Meeting
• Daily Scrum
• Sprint Review
• Sprint Retrospective

22. 1 Release Planning
Meeting
2 Sprint planning
meeting 1
3 Sprint planning
5 meeting 2
4 The Sprint
Selected 5 Daily Scrum
Product Backlog 6 Sprint Review
7 Sprint Retrospective
4
Vision
Anticipated ROI,
Releases, Milestones 1 New functionality
2 3 is demonstrated
at the enf of
Sprint
Functional and
nonfunctional emerging Requirements
and prioritized requirements brake down into activities/tasks

23. • Establish a plan and goals that the Scrum Teams and
the rest of the organizations can understand and
communicate
• Release planning requires estimating and
prioritizing the Product Backlog for the Release
• Release planning is not a commitment to precise
details
• Release planning is entirely optional. If Scrum Setting the vision and the strategic
teams start work without the meeting, the absence plan
of its artifacts will become apparent as an impediment
that needs to be resolved

24. • A Sprint is an iteration
• Time-boxed
• All work is done in Sprints
• Consisted by the Sprint Planning,
development work, Sprint Review and the
Sprint Retrospective
• Sprints can be cancelled before the Sprint
time box is over. Only the Product Owner has
the authority to cancel the Sprint
It’s time to run!

25. • Is where the Sprint is planned
• Splited in two moments:
– The PO with the ScrumTeam support selects
the Product Backlog items that will compose
the Sprint Backlog (needs to consider team
velocity, etc. during this selection)
– With the Sprint Backlog defined, the team
works together to came up with a plan to the Operational plan being defined
Sprint that is beginning
– Meeting output: Sprint Backlog

26. • The Scrum heartbeat
• 15 minutes
• 3 questions
– What did you do yesterday?
– What will you do today?
– Are there any impediments in your way?
• The Daily Scrum is not a status meeting
• The Daily Scrum is an inspection of the progress “Look, our burndown is about to screw up,
we need to attack more harder to change that”
toward the Sprint Goal that the team was committed for

27. • The team presents to the PO and stakeholders
functionality that is done and answer
questions.
• The Product Owner identifies what has
been done and what hasn’t been done
• The Team discusses what went well during
the Sprint and what problems it ran into, and
how it solved these problems
“Let me show you that story operating”
• The entire group then collaborates about what it
has seen and what this means regarding what to do next

28. • Time to review the good and the bads
• Inspect how the last Sprint went in regards to
people, relationships, process and tools
• The meeting is from the team to the team
• PO attendance is not obrigatory
• ScrumMaster hold this meeting
• Team identify the actions to adapt and improve
the ongoing process “Definetely we need more automation in our
tests, we are wasting a lot of time doing
manual qualification...”

29. • Product Backlog
• Sprint Backlog
• Release Burndown
• Sprint Burndow

30. • The PO “wish list”
• Items prioritized by the
business importance/value
• The PO is the owner
• As long as a product exists,
the Product Backlog also exists
img source: http://epf.eclipse.org/wikis/scrum/

31. user
stories
Sprint
themes
Release Priority
Next Release epics

32. • Details the work, or tasks, that
the team defines to turning the
Product Backlog it selected for
that Sprint into an increment of
potentially shippable product
functionality img source: http://epf.eclipse.org/wikis/scrum/

33. • Shows the Release progress
• How much selected Product
Backlog was “burned”
• Updated at the end of each Sprint
• Normally the unit measure is Story
Points (not a rule) against Sprints
img source: http://epf.eclipse.org/wikis/scrum/

34. • Shows the Sprint progress
• How much the team already
“burned” in that Sprint
• Primary tool for the Daily Scrum
meetings (with task boards or
Sprint activities list)
• Normally the unit measure is img source: http://epf.eclipse.org/wikis/scrum/
Hours against time (daily basis)

37. • Scrum requires teams to build an increment of
product functionality every Sprint
• This increment must be potentially shippable, for
Product Owner may choose to immediately
implement the functionality
• The detailed definition of Done should be agreed
between the ScrumTeam and the PO

38. • Plannig Poker
• User Stories and Story Points
• Technical Debt
• Team Velocity
• Complex Adaptive Systems
• Lean manufacturing
• Constraints Theory
• Kanban

39. • www.scrum.org • Books
• www.scrumalliance.org