6. 12 Principles behind the Agile
Manifesto
• Our highest priority is to satisfy the customer
through early and continuous delivery of valuable
software.
• Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
• Deliver working software frequently, from a couple
of weeks to a couple of months, with a preference
to the shorter timescale.
• Business people and developers must work
together daily throughout the project.
• Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
• The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
• Working software is the primary measure of
progress.
• Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and
good design enhances agility.
• Simplicity the art of maximizing the amount of
work not done is essential.
• The best architectures, requirements, and designs
emerge from self-organizing teams.
• At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
25. The Rules
• Everyone is part of one big team.
• Each ball must have air-time.
• Each ball must be touched at least once by every
team member.
• Balls cannot be passed to your direct neighbor to
your immediate left or right.
• Each ball must return to the same person who
introduced it into the system.
• There are a total of five iterations two minutes
each.
45. #1 – Absolute Estimation
Beagle 11
Labrador 32
Great Dane 91
Chihuahua 2
Appalachian Mountain Dog -
American Cocker Spaniel 14
Border Collie 20
Staffordshire Bull Terrier 17
What did we learn?
56. Definition of Done aka DoD
• The team agrees on, and displays
prominently somewhere in the
team room, a list of criteria which
must be met before a product
increment "often a user story" is
considered "done".
• On a feature level, the acceptance
criteria should be agreed up front
BEFORE the User Story is
submitted to acceptance.
57. Definition of Ready aka DoR
• By analogy with the "Definition of
Done", the team makes explicit
and visible the criteria (generally
based on the INVEST matrix) that
a user story must meet prior to
being accepted into the upcoming
iteration.
• On a feature level, the acceptance
criteria should be agreed up front
BEFORE code is written.
64. POST-GAME: Debriefing
• What did you observe?
• How did it feel being on a Scrum
team?
• How did the short iterations go?
• How accurate were the
estimations?
• What would we have done
differently from the beginning, if
we had another chance to play
the game?
• What was the job of the Product
Owner?
• How did it feel after the first
sprint when almost all items
required re-work?
• What did the Scrum Masters do?
• How will your strategy change, if
you know the Product Owner is
unavailable during sprints?
• How did inter-team
communication go? Were there
any dependencies? How were
they resolved?
• What did you learn?