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.

1. AGILE DEVELOPMENT
PROCESS + SCRUM
August 2010 Otavio Ferreira (@otaviofff)

2. Let’s meet up!
2

3. Agenda
3
 Principles
 Roles
 Rituals
 Artifacts
 Timeline
 Manifesto

4. Principles
4
 Iterative
 Incremental
 Self-management

5. Agenda
5
 Principles
 Roles
 Rituals
 Artifacts
 Timeline
 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

10. Agenda
10
 Principles
 Roles
 Rituals
 Artifacts
 Timeline
 Manifesto

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

17. Agenda
17
 Principles
 Roles
 Rituals
 Artifacts
 Timeline
 Manifesto

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>.

23. Artifacts
23
 User Story (continued)
 Structure – 3Cs
 Card
 Conversation
 Confirmation
 Writing – INVEST
 Independent
 Negotiable
 Valuable
 Estimable
 Small, or Sized Appropriately
 Testable

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

30. Agenda
30
 Principles
 Roles
 Rituals
 Artifacts
 Timeline
 Manifesto

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

33. Agenda
33
 Principles
 Roles
 Rituals
 Artifacts
 Timeline
 Manifesto

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

40. Agenda
40
 Principles
 Roles
 Rituals
 Artifacts
 Timeline
 Manifesto
Icons by David Lanham / http://dlanham.com/