2. Individuals and interactions over processes
and tools
AGILE
Working software over comprehensive
documentation
Customer collaboration over contract
negotiation
Responding to change over following a plan
Agile development methods focus rigorously on delivering
business value early and continuously
3. WATERFALL AGILE
Fixed Requirements Resources Time
Value
Plan Driven
Driven
Estimated Resources Time Features
4. One of the criticisms of
Analysis
waterfall projects is that they
Design tend to deliver what was
Development originally requested in the
Testing
requirements document, not
what the stakeholders discover
Deployment
they actually need as the
Maintenance project and system unfolds.
5. In the agile community, waterfall projects are sometimes
compared to "fire and forget" weapons, for which you
painstakingly adjust a precise trajectory, press a fire button and
hope for the best.
Agile projects are likened to cruise missiles, capable of
continuous course correction as they fly and therefore much likelier
to hit the targeted feature-set and date accurately.
6. Scrum is founded on empirical process
control theory or empiricism.
Empiricism asserts that knowledge
comes from experience and making decisions
based on what is known.
Scrum employs an iterative, incremental
approach to optimize predictability and
control risk.
Three pillars uphold every
implementation of empirical process control:
transparency, inspection, and adaptation.
7.
8. Strategy
Agility is…
Charter
Funding
Vision
Release
Estimation
Release
Plan Iteration
Retrospective
Iteration
Daily Review
Plan
Acceptance Testing
Standup Continuous
Refactoring
TDD
Integration
Collaboration
Build
Working
Software
9.
10. Holds the responsibility for maximizing the value of the product and
the work of the Development Team.
Collects requirements from stakeholders and users.
Sets priorities to the requirements by business value, risk, priority,
and necessity and creates the Product Backlog.
Manages the Product Backlog and is responsible for its content,
availability, and ordering.
11. Holds the responsibility for ensuring that the Scrum theory,
practices, and rules are understood and adhered to.
Coaches the Development Team in self-organization and cross-
functionality.
Teaches and leads the Development Team to create high-value
products.
Removes impediments to the Development Team’s progress.
Facilitates Scrum events as requested or needed.
12. Hold the responsibility of developing and delivering a potentially
releasable Increment of “Done” product at the end of each Sprint.
Organize and manage their own work.
Report progress.
14. PRODUCT BACKLOG
List of all features, functions, requirements, enhancements
and fixes that constitute the changes to be made to the product
in future releases.
Owned and managed by Product Owner
Prioritized by business value
Changes in business requirements, market conditions or
technology may cause changes in the Product Backlog.
Can change without affecting the active sprint.
15. SPRINT BACKLOG
Set of Product Backlog items selected for the Sprint plus a
plan for delivering the product Increment and realizing the Sprint
Goal
Owned and managed by the Development Team
At any point in time in a Sprint, the total work remaining in
the Sprint Backlog items can be summed & tracked using Burn-
Down chart.
Are not to be changed during the Sprint
16. INCREMENT
Sum of all the Product Backlog items completed during a
Sprint and all previous Sprints.
At the end of a Sprint, the new Increment must be “Done,”
which means it must be in useable condition.
18. Self - organizing teams
Progresses in a series of “Sprints”
Requirements are captured as items in a list of “product
backlog ”
No specific engineering practices prescribed
One of the Agile processes
20. Sprint Planning Meeting
The team meets with the product owner to choose a set of work to
deliver during a sprint
21. Sprint Planning Meeting
Product Backlog Sprint Prioritization
Select and declare Sprint Goal
Team Capabilities
Analyze and evaluate product backlog
Select top most features
Business Conditions
Technology Sprint Planning
Decide how to achieve Sprint goal
Product Status
Team decomposes selected features
into Sprint Backlog
Competition
Estimate Sprint backlog in hours
23. The Sprint
Time Boxed effort
Usually 2 weeks to 1 month long
Can be longer or shorter
Defined workload
No changes once sprint begins
If workload changes, sprint is restarted
Begins with Sprint planning meeting
Involves Daily SCRUM, development, Product Backlog grooming
Ends with demonstrable release
25. Daily SCRUM
Time Boxed to 15 minutes
Run by Scrum Master; Attended by all
Stakeholders usually do not speak
Team shares status and discuss issues
Answer 3 questions
What I did yesterday
What I will do today
What is on my way
Team updates Sprint Backlog
Scrum Master updates impediments list
27. Sprint Review
Time Boxed to 2 or 4 hours
Run by Scrum Master; Attended by all
Team demonstrates new functionality to the Product Owner and
any other invited stakeholders
Review if the Sprint goal was met
Decide on what to do next
29. Sprint Retrospective
Time Boxed to 1 or 2 hours
Run by Scrum Master
Attended by Team members and Product Owner
Team discusses the just-concluded Sprint and determines what
could be changed to improve the product and the process in the
next Sprint
Team determines
what do we want to stop doing?
what do we want to keep doing?
what do we want to start doing?
30. Sprint Planning Meeting 4 hours
The Sprint 2 to 4 weeks
Daily Scrum 15 minutes
Sprint Review 2 or 4 hours
Sprint Retrospective 1 or 2 hours
Scrum meetings are time-boxed and occur on a regular schedule
