The document provides an overview of Agile development using Scrum. It describes the key principles of iterative development and self-management. It outlines the roles of the Product Owner, Scrum Master, and Team Members. It details rituals like sprint planning, daily standups, reviews and retrospectives. It explains artifacts such as user stories, tasks, and burn down charts. It presents the Scrum timeline and concludes with the Agile Manifesto.
6. Roles
6
Hey, why don't we open a restaurant?
Good idea. What do you want to call it?
Why don't we call it 'Ham and Eggs'?
I don't think so. I'd be committed, but you'd
only be involved.
7. Roles
7
Product Owner: Owns the Product Backlog
Responsibilities
Manage the Product Backlog
Manage the Release Plan
Manage the Return on Investment
In a nutshell...
The PO represents the interests of everyone with a
stake in the project. He is responsible for the final
product
8. Roles
8
Scrum Master: Owns the Scrum Process
Responsibilities
Manage the process
Remove impediments
Facilitate communication
In a nutshell...
The SM is responsible for the Scrum process. He
ensures everybody plays by the rules. He also
removes impediments for the Team
9. Roles
9
Team Member: Owns the Software
Responsibilities
Implement user stories (SQA included)
Deliver functional software increments
Manage themselves
In a nutshell...
The team figures out how to turn the Product Backlog
into an increment of functionality within a Sprint. Each
team member is jointly responsible for the success of
each iteration and of the project as a whole
11. Rituals
11
Sprint Planning
Part 1: The PO presents the User Stories
Part 2: When the Team thinks they have enough
stories to start the Sprint, they begin breaking it
down in Tasks to fill the Sprint Backlog
Constraints
Timebox 4 hours
Owner Product Owner
Participants Team, Scrum Master
12. Rituals
12
Planning Poker
Part of Sprint Planning (1st half)
Consensus-based technique for estimating the
complexity of User Stories
Fibonacci Numbers: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100
4.27 cm ---{ 5x }--- 21.35 cm
13. Rituals
13
Daily Scrum
Standup meeting
The Team daily inspects their progress in relation
to the Planning by using the Burndown Chart, and
makes adjustments as necessary
Constraints
Timebox 15 minutes
Owner Scrum Master
Participants Team (Other interested parties may silently attend)
14. Rituals
14
Daily Scrum (continued)
Each member answers the following
What have you done since the last Daily Scrum?
What will you be doing until the next Daily Scrum?
What are your impediments, if any?
Try out these constraints
No verbs in continuous tenses
No finger pointing
The owner is always accountable for the results / status
15. Rituals
15
Sprint Review
At the end of a Sprint, the Team reviews the work
finished and unfinished, then presents finished
work to stakeholders
Unfinished work cannot be demonstrated
Constraints
Timebox 2 hours
Owner Scrum Master
Participants Team, Product Owner
16. Rituals
16
Sprint Retrospective
At the end of a Sprint, the Team evaluates the
finished iteration
They capture positive ways as a best practice,
identify challenges, and develop strategies for
improvements
Focus on the process
Constraints
Timebox 2 hours
Owner Scrum Master
Participants Team, Product Owner
18. Artifacts
18
Product Vision
Makes the overall goal clear and public
Guides the Team, aligns stakeholders
Captures the essence of the product, briefly
The minimum plan necessary to start a Scrum project consists of a
Product Vision and a Product Backlog. The vision describes why
the project is being undertaken and what the desired end state is.
– Ken Schwaber, 2004
19. Artifacts
19
Product Vision: Questions
Who is going to use the product?
Which user needs will the product address?
Which product attributes are critical to address
the customer needs selected?
How does the product compare against existing
products?
What is the business model?
What is the target timeframe and budget to
develop and launch the product?
20. Artifacts
20
Product Vision: Template
FOR <target customer>
WHO <statement of the need>,
THE <product name> is a <product category>
THAT <product key benefit, compelling reason to buy>
UNLIKE <primary competitive alternative>,
OUR PRODUCT
<final statement of primary differentiation>
Source: Crossing the Chasm , by Geoffrey Moore, 1999
21. Artifacts
21
Definition of Done
By the end of a Sprint, the software increment
must be ready to be released
What does this mean to your organization?
Coded
Reviewed
Tested(functional, unit, load, etc.)
Documented
Deployed onto homologation
What else? What less?
22. Artifacts
22
User Story
Piece of software relevant to end users
A functional requirement that aggregates value to
end users
Complexity set according to Fibonacci Numbers
Card format:
As an <actor>,
I want to <action>,
So that <achievement>.
24. Artifacts
24
Task
Part of a Story
One step towards the achievement
Lower abstraction level
Writing – SMART
Specific
Measurable
Achievable
Relevant
Time-boxed
25. Artifacts
25
Taskboard
Keeps track of progress. Enhanced visibility
Supports the Daily Scrum
Sprint Backlog In Progress Done
26. Artifacts
26
Product Backlog
The requirements for the product are listed in the
Product Backlog
It is an always changing, dynamically prioritized
list of requirements ordered by Business Value
Requirements are broken down into User Stories
by the PO
27. Artifacts
27
Sprint Backlog
It contains all the committed User Stories for the
current Sprint broken down into Tasks by the
Team
All items on the Sprint Backlog should be
developed, tested, documented and integrated to
fulfill the commitment
28. Artifacts
28
Burndown Chart
It shows the amount of work remaining per Sprint
It is a very useful way of visualizing the
correlation between work remaining at any point
in time and the progress of the Team
It is useful for predicting when (and whether) all of
the work will be completed
Types
Sprint Burndown Chart
Release Burndown Chart
29. Artifacts
29
Source: Wikipedia / http://en.wikipedia.org/wiki/File:SampleBurndownChart.png
31. Timeline
31
Source: Wikipedia / http://en.wikipedia.org/wiki/File:Scrum_Process.svg
32. Timeline
32
Extreme Scrum
5-day sprints
5-point stories, or less
2-developer teams, up to 4
Outcomes
More accurate story complexity estimation
Almost instant feedback
Quicker focus adjustment
Quicker response to requirements changing
Manageability goes through the roof
34. Manifesto
34
Values
Individuals and interactions over processes and
tools
Working software over comprehensive docs
Customer collaboration over contract negotiation
Responding to change over following a plan
– Manifesto for Agile Software Development, 2001
35. Manifesto
35
Principles (1 to 3, out of 12)
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
36. Manifesto
36
Principles (4 to 6, out of 12)
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
37. Manifesto
37
Principles (7 to 9, out of 12)
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
38. Manifesto
38
Principles (10 to 12, out of 12)
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
– Manifesto for Agile Software Development, 2001
39. Manifesto
39
And talking about Simplicity...
There are two ways of constructing a software
design
One way is to make it so simple that there are
obviously no deficiencies
And the other way is to make it so complicated that
there are no obvious deficiencies
The first method is far more difficult
– Sir Charles Antony Richard Hoare, 1960
Inventor of the Quicksort algorithm