Chapter 3

 Agile Development
Software Engineering: A Practitioner’s
Approach,
by Roger S. Pressman

1
Other Agile Process
Models

Core

Auxiliary

2
What is Scrum?
It’s about common sense
 Scrum:
 Is an agile, lightweight process
 Can manage and control software and product
development
 Uses iterative, incremental practices
 Has a simple implementation
 Increases productivity
 Reduces time to benefits
 Embraces adaptive, empirical systems
development
 Is not restricted to software development
projects

 Embraces the opposite of the waterfall

approach…
 SCRUM FRAMEWORK
The Agile:SCRUM Framework at a Glance
Scrum at a Glance

24 hours
Daily Scrum
Meeting

Backlog tasks 30 days

expanded
Sprint Backlog by team

Potentially Shippable
Product Backlog Product Increment
As prioritized by Product Owner
Source: Adapted from Agile Software
Development with Scrum by Ken
Schwaber and Mike Beedle.
 Scrum Origins
 Jeff Sutherland
 Initial scrums at Easel Corp in 1993
 IDX and 500+ people doing Scrum

 Ken Schwaber
 ADM
 Scrum presented at OOPSLA 96 with Sutherland
 Author of three books on Scrum

 Mike Beedle
 Scrum patterns in PLOPD4

 Ken Schwaber and Mike Cohn

 Co-founded Scrum Alliance in 2002, initially within
Agile Alliance
 Sequential vs. Overlap
Requirements Design Code Test

Rather than doing all of one

thing at a time...

...Scrum teams do a little of

everything all the time
 Scrum Framework
Roles
•Product owner
•Scrum Master
•Team Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts
Scrum Roles
 Product Owner
• Possibly a Product Manager or Project Sponsor
• Decides features, release date, prioritization, $$$

 Scrum Master
• Typically a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Remove impediments / politics, keeps everyone
productive

 Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• Membership should change only between sprints
 "Pigs" and "Chickens"
 Pig: Team member committed to success of
project
 Chicken: Not a pig; interested but not
committed

A pig and a chicken are walking down a road. The

chicken looks at the pig and says, "Hey, why don't we
open a restaurant?" The pig looks back at the chicken
and says, "Good idea, what do you want to call it?"
The chicken thinks about it and says, "Why don't we
call it 'Ham and Eggs'?" "I don't think so," says the
pig, "I'd be committed but you'd only be involved."
 Sprint Planning Mtg.

Team Sprint planning meeting

Team
capacity
capacity Sprint prioritization
Product
Product • Analyze/evaluate product Sprint
Sprint
backlog goal
backlog
backlog
• Select sprint goal
goal
Business
Business
conditions Sprint planning
conditions
• Decide how to achieve sprint goal
Current (design) Sprint
Current
• Create sprint backlog (tasks) from
Sprint
product
product backlog
product backlog items (user stories backlog
/ features)
Technolo
Technolo • Estimate sprint backlog in hours
gy
gy
 Daily Scrum Meeting
 Parameters
 Daily, ~15 minutes, Stand-up
 Anyone late pays a $1 fee

 Not for problem solving

 Whole world is invited
 Only team members, Scrum Master, product owner,
can talk
 Helps avoid other unnecessary meetings

 Three questions answered by each team member:

1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?
Scrum's Artifacts
 Scrum has remarkably few artifacts
 Product Backlog
 Sprint Backlog
 Burndown Charts

 Can be managed using just an Excel

spreadsheet
 More advanced / complicated tools exist:
• Expensive
• Web-based – no good for Scrum
Master/project manager who travels
• Still under development
Product Backlog
 The requirements

 A list of all desired work

on project

 Ideally expressed as a
list of user stories along
with "story points", such
that each item has value
This
This is
is the
the to users or customers of
the product
product
product backlog
backlog
 Prioritized by the product
owner

 Reprioritized at start of
each sprint
User Stories
 Instead of Use Cases, Agile project
owners do "user stories"
 Who (user role) – Is this a customer,
employee, admin, etc.?
 What (goal) – What functionality must be
achieved/developed?
 Why (reason) – Why does user want to
accomplish this goal?

As a [user role], I want to [goal], so I

can [reason].
User Stories
 Example:
 "As a user, I want to log in, so I can
access subscriber content."

 story points: Rating of effort needed

to implement this story
 common scales: 1-10, shirt sizes (XS, S, M,
L, XL), etc.
 Sample Product
Backlog
Backlog item Estimate

Allow a guest to make a reservation 3 (story points)

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-

8
per-available-room)

Improve exception handling 8

... 30

... 50
Sample Product Backlog 2
Sprint Backlog
 Individuals sign up for work of their own
choosing
 Work is never assigned
 Estimated work remaining is updated daily

 Any team member can add, delete change

sprint backlog
 Work for the sprint emerges
 If work is unclear, define a sprint backlog item
with a larger amount of time and break it down
later
 Update work remaining as more becomes
known
 Sample Sprint backlog
Tasks
Tasks Mon
Mon Tue
Tue Wed
Wed Thu
Thu Fri
Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 4
Test the middle tier 8 16 16 11 8
Write online help 12
Write the Foo class 8 8 8 8 8
Add error logging 8 4
Sample Sprint Backlog
 Sprint Burndown Chart
 A display of what work has been
completed
and what is left to complete
 one for each developer or work item
 updated every day
 (make best guess about hours/points
completed each day)

 variation: Release burndown chart

 shows overall progress
 updated at end of each sprint
 Sample Burndown
Chart
Hours
 Tasks
Tasks Mon
Mon Tue
Tue Wed
Wed Thu
Thu Fri
Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50
40
30
Hours

20
10
0
Mon Tue Wed Thu Fri
 Burndown Example 1
No work being performed
Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
 Burndown Example 2
Work being performed, but not fast enough
Sprint 1 Burndown

49

48

47

46
Hours remaining

45

44

43

42

41

40
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
 Burndown Example 3
Work being performed, but too fast!
Sprint 1 Burndown

60

50

40
Hours remaining

30

20

10

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Days in Sprint
The Sprint Review
 Team presents what it accomplished
during the sprint
 Typically takes the form of a demo of
new features or underlying
architecture
 Informal
 2-hour prep time rule
 No slides
 Whole team participates
 Invite the world
Scalability
 Typical individual team is 7 ± 2 people
 Scalability comes from teams of teams

 Factors in scaling
 Type of application
 Team size
 Team dispersion
 Project duration

 Scrum has been used on multiple

500+ person projects
Scaling: Scrum of
Scrums
Scrum vs. Other
Models
Credits, References
 Mike Cohn, Mountain Goat Software
[Link]
 Scrum and The Enterprise by Ken Schwaber
 Succeeding with Agile by Mike Cohn
 Agile Software Development Ecosystems by Jim
Highsmith
 Agile Software Development with Scrum by K. Schwaber
and M. Beedle
 User Stories Applied for Agile Software Development by
Mike Cohn

 [Link]/
 [Link]
 [Link]/
 [Link]/[Link]
 [Link]/articles/articles/[Link]