Agile Development with Scrum.pptx

AGILE DEVELOPMENT
WITH SCRUM
9/13/2012

Checkpoint
 Foundations of Scrum
 High Level Scrum Overview
 Roles in Scrum
 Sprints and the Definition of Done
 Agile Engineering Techniques
 Agile Requirements with User Stories
 Agile Estimating
 Release Planning and tracking

Official Scrum Definition
A development framework
wherein cross functional,
self managing teams deliver
working software every thirty
days.

Unofficial ‘Zen of Scrum’
 Hire Smart People
 Put them in small cross functional teams
 Trust & empower those teams
 Ask them to demonstrate working stuff once a
month

 What should we build?
 Watt’s Humphries: “Requirements cannot be fully known
until users have tried the software.”1
 Jakob Nielsen: “For 50 years, almost all experience with
traditional waterfall development methods have found that
it results in poor user experience. The reason is simple:
requirement specifications are always wrong.” 2
1Watts Humphrey's Requirements Uncertainty Principle
2Agile Usability: Best Practices for User Experience on Agile Development projects
Why Scrum?

 Simple, Definable Projects:
 Given a set of inputs, tasks
can be defined that will
generate the same outputs
every time.
 Complex, Chaotic Projects
 Tasks cannot be defined that
will generate consistent
outputs
 Axes of Certainty
 Technical and Domain are
only two…
 Team stability, capability
 Organizational agreement on
priority
6
Technical Certainty
High Low
High
Low
Domain
Certainty
Simple Complex
Chaotic
Anarchic
Complex
Why Scrum?

 Defined (predictable) projects
 Define, Estimate, Create a Plan, and Execute to Plan
 Empirical (chaotic) projects
 Define Small Portion, Estimate, Create a Plan, Execute
7
Why Scrum?

 Inspect & Adapt Plan
 Create Plan & Execute
8
Why Scrum?

 Create Plan & Execute…
Why Scrum?

What Scrum is and what it is
not:
Scrum Is Not: Scrum Is:
A development methodology that will
make us build software faster
A tool that will help us discover things we
can do to build software faster

What Scrum is and what it is
not:
Scrum Is Not: Scrum Is:
A development methodology that will
make us build software faster
A tool that will help us discover things we
can do to build software faster
A solution to development problems Something that exposes development
problems early and often

Agile Manifesto (2001)
 A set of values:
Over
Over
Over
Over
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim
Highsmith,

Product Backlog
Sprint Backlog
Daily
2-4 Weeks
Potentially
Releasable
Increment
Sprint Goal
Scrum Overview
The list of all desired work for a product, project, or team
Prioritized (1-n) by the Product Owner to ensure:
 Balanced stakeholder demands
 Alignment to corporate strategy
 Driving of profit engine
Can be added to by anyone
Ideally expressed such that each item has value to the
users or customers of the product
Frequently updated Potentially Releasable:
1. Delivers some value to users
2. High enough quality to release
Vertical Slices:

Three Roles in scrum
 Product Owner
 Scrum master
 Scrum Team

Three Roles in scrum: Product
Owner
 Product Owner
 Defines the features of the product, decides on release
date and content
 Is responsible for the profitability of the product (ROI)
 Prioritizes features according to market value
 Can change features and priority every sprint
 Owns the “What to build” decisions

The 3 responsibilities of a Product
Owner
1. Inspire The Team with your vision of what the product
can become
 Keep team focused on the Big Picture things like:
 Target users, personas
 Market opportunities
 Long term strategy & roadmaps
2. Build The Product Backlog
 Manage all stakeholder requests in a single, frequently update
list
 Present a clear, visible record of the product’s current priorities
 Decompose large user problems into smaller ones as they
approach implementation
3. Provide Feedback to the team:
 You represent the users
 Provide ongoing feedback during sprints and at sprint reviews

Three Roles in scrum: Scrum
Master
 Scrum master (1 per scrum team, initially)
 Responsible for enforcing the values and practices of the
process and the team
 Remove impediments from the team
 Remove barriers between team and others
 Educate outside groups about how the team is working
 Improve productivity in any way possible
 Shields the team from external interferences
 Owns the “Scrum Process” decisions

Three Roles in scrum: Scrum
Team
 Scrum Team
 No formal concept of “Eng vs. QE”, only team members
with individual expertise
 7 developers, +/- 2 make up a scrum team
 Scale through having multiple scrum teams
 Selects the sprint backlog
 Has the right to do everything within the boundaries of the
project guidelines to reach the iteration goal
 Organizes itself and its work
 Demos work results to the Product Owner
 Owns the “How to build” decisions (including how fast)

 There are two main ways to structure teams:
 Based on Architectural Layers
 Cross-functionally
Cross Functional vs. Architectural
Layers
Lead
Architect
Backend
Programmer
Backend
Programmer
Backend
Programmer
Backend
Programmer
Tester Tester
Backend
Team
Frontend
Team UX
Designer
Frontend
Programmer
Tester Tester
Frontend
Programmer
Frontend
Programmer
Generalist
Programmer
Tester
Lead
Architect
Backend
Programmer
Backend
Programmer
Backend
Programmer
Backend
Programmer
Tester Tester
Cross Functional
Scrum Team 1
UX
Designer
Frontend
Programmer
Tester Tester
Frontend
Programmer
Frontend
Programmer
Generalist
Programmer
Tester
Cross Functional
Scrum Team 2

Overview of roles
Product Owner Scrum Master Scrum Team
What will we make?
1 per team or backlog
Prioritize the Backlog
 Provide Vision
 Answer team’s questions
 Work with all customers
 Manage stakeholders
Is the team healthy?
Following the rules?
 Ideally 1 per scrum team
Team functioning highly
 Team protected within
sprints
 Information team needs
is readily available
The oil that keeps the
team running.
How will we make it?
How Fast?
 ~7 people per team
 Creative engineering
solutions to customer
problems
 Architecture
 Code Quality
 Sprint Backlog
 Commitments for the
sprint

Working on product backlog
Role Time spent on sprint Time spent on Product
Backlog
Product Owner 10-20% 80-90%
Scrum Team
member
90% 10%
UX, Architect, etc. 50% 50%
 Product Owner
 Prioritize the backlog items
 Work with stakeholders to add new items as they are requested
 Ensure that high priority items are being decomposed to an appropriate
size
 Scrum Team
 Provide estimates
 Provide technical backlog items necessary to reach product vision
 Help the P.O. decompose items

Checkpoint
 Foundations of Scrum
 High Level Scrum Overview
 Roles in Scrum
 Sprints and the Definition of Done
 Agile Engineering Techniques
 Agile Requirements with User Stories
 Agile Estimating
 Release Planning and tracking
 Debrief

Sprints
 Two to four week iteration
 Deliver working software
 Deadline is sacred
 Drop scope to meet the deadline
 Product Owner can’t add new stuff once they’ve started
 Team Can
 Product Owner can abnormally terminate

Scrum Meetings
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting
Scrum of
Scrums
Meeting

Purpose of sprint planning
 What is the primary goal of the sprint
planning meeting?
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting

Purpose of sprint planning
 Arrive at a commitment to a sprint goal
or set of product backlog items
 Not “come up with a list of tasks”
 Tasks and estimates are a tool to ensure
we can commit
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting

Sprint Planning
 Day 1 of sprint
 Sometimes broken into two parts:
 Part 1 (4 hours):
 Product Owner describes user stories
 Clarifying discussion with the team
 Sprint Goal is chosen
 Initial Commitment from team
 Part 2 (4 hours):
Determine Capacity for sprint
Break down stories into tasks (code, test,
etc.)
 Estimate tasks in hrs or days (1/2–2 days)
 Final commitment for sprint
 These two can be combined:
 Discuss first backlog item,
 Break it down into tasks
 Task estimates
 Team commits
 Repeat with item 2
Product Backlog
Sprint 1
Sprint 2
Sprint 3
Sprints 4-5
Sprints 6-10

Breakdown a story/feature into
tasks
Product
Backlog Sprint Backlog
At the end of the sprint planning
meeting you have:
 a set of estimated tasks
 a team commitment to complete the
product backlog items represented by the
sprint backlog
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting

Sprint Burndown Chart
1 0 9 8 7 6 5 4 3 2 1 0
50
40
30
20
10
0
Y: Stuff Left To Do:
X: Time Left in Sprint:

What if we discover we’re over-
committed?
 Two options (team chooses):
0
200
400
600
800
1000
1200
1400
28 26 24 22 20 18 16 14 12 10 8 6 4 2 0
 Work overtime to meet the
commitment
 But: sustainable pace?
 Remove work as soon as they
think they’re over committed
 This is a discussion with the
product owner.

Daily Scrums
15 Minutes
 Three Questions
What have you done?
What will you do?
What’s in your way?
 Goal 1: commit in front of peers.
 Goal 2: ensure we’re on track to meet our commitments for the
sprint.
 Not for problem solving
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting

Scrum of Scrums
 Each team sends a representative
 Rotate attendance based on whose
skills are needed most
 Usually 2-3 times per week
 Four Questions
What has your team done?
What will your team do?
What’s in your team’s way?
What are you about to put in
another team’s way?
 These are problem solving meetings
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting
Scrum of
Scrums
Meeting

Definition of Done
 General Definition of Done: the template of
development steps that all features should go through,
determined by the team and the product owner at the
beginning of the cycle.
 Typically includes things like:
 designed, coded, automated tests created, unit tests created,
functional testing completed, unit tests passing, integration
testing completed, documented.
 Whatever your team agrees that EVERY feature must
do to be considered done.
 The more mature & disciplined the team, the more
complete this list, including things like localization & loc
testing complete, security audited, code peer-reviewed,
etc.

Sprint Review
 “Inspect” product
 Team presents what was
accomplished during the sprint
 Typically a demo of new features
 Informal
No slides
Minimal prep
 Whole team participates
 Invite the world
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting

Sprint Retrospective
Sprint
Planning
Meeting
Daily
Scrum
Meeting
Sprint
Review
Meeting
Sprint
Retrospectiv
e Meeting
 “Inspect” process
 Periodically take a look at what
is and what isn’t working
 Can be short, sometimes long
 Done after every sprint
 Whole team participates

Retrospectives & Self
Management: A Tale of Three
Sprints
Sprint 7
Sprint 8
Sprint 9

Sprint 8 Retrospective
 Team frustrated that work is not getting all done
in a sprint
 We’ve tried deferring earlier, now what?
 Team agreed:
 Decompose larger stories into much smaller stories for the next sprint
 Each story needs to be testable
 Mantra for next sprint planning: “and how will we test this?”
 Be very careful with check-ins approaching end of sprint
Before: After:
Uh Oh! No Problem

Team “discovered” TDD, further
vertical slicing
Sprint 7
Sprint 8 Sprint 9
 Sprint 9:
 Team broke features down smaller
 We could defer small stories at any time
 Sprint planning meeting was test driven
 Completed all work in the sprint!

Goals of Agile Engineering
Techniques
 Remove defects as early as possible
 Improve code health, eliminate technical
debt
 Promote collective ownership &
understanding
 Deliver razor thin slices as frequently as
possible
 Work at a sustainable pace

Agile Engineering Practices
 Test Driven Development
 Pair Programming
 Peer Reviews
 Continuous Integration
 Automated Acceptance Testing

Example Requirement
Requirement 1.05a:
The application should automatically
save open documents at regular
intervals

User Stories
I want <some function>
 User Stories add two pieces of information
to a typical requirement:

Creating a Product Backlog using
User Stories
 User Stories:
As a <type of user>,
so that <some goal>.

Example
Requirement 1.05a:
The application should automatically
save open documents at regular
intervals
Why?
Who needs this functionality?

Create a Product Backlog using
User Stories
 User Stories:
As a <type of user>,
so that <some goal>.
 Example: Auto-save document

Where are the details?
 The product owner’s conditions of satisfaction
can be added to the back
 These are essentially tests

Where are the details?
 The larger story can be broken into
multiple smaller stories

Stories, Themes, and Epics
User story
A description of
functionality told
from the users
perspective
Theme
A collection of
related stories
Epic
A really big story

Ideas for splitting stories
 Focus on “vertical slices”
 Tracer Bullet
 Break into Acceptance Tests/Conditions of
Satisfaction
 Then turn those into smaller stories
 20 ways to split stories
 http://xp123.com/xplor/xp0512/

Attributes of a good story
 Independent
 Negotiable
 Valuable
 Estimatable
 Sized Appropriately
 Testable
 Eliminate as many dependencies as possible
 Stories aren’t contracts, leave or imply some flexibility
 To users
 Plans are based on stories, so we need to estimate
 Small enough to work on in a sprint if it’s close to
implementation
 How will we know it’s done? No partial credit

Agile Planning & Estimation
 Goal is always to be accurate
 Precision increases as project goes on
 Is more focused on planning than the plan
 Encourages changes
 Results in plans that are easily changed
 Is spread throughout the project

Estimation accuracy over time
X = Time Spent
Y
=
Estimation
Accuracy
100%
1 2 3 4 5 6 7
Highest ROI
More Certainty, at higher cost

Traditional Time Estimates
How long will it take to eat all of this candy?

Traditional Time Estimates
How long will it take to eat all of this candy?
 What factors might influence the answer?
 Who is doing the work?
 Interruptions?
 What kind is it?
 Motivations?
 How tired?

Agile Estimates: Relative Size
Candy Units = X
Candy Units = 3

Orders of Magnitude
3
6 ? ?!?!

Limiting the set of possible
values
 We only estimate well within one order of
magnitude
 Difference between 3 and 6 is obvious, worth
discussing
 What about 103 and 106?
 Limit possibilities to naturally occurring sets of
increasing values:
 Fibonacci: 1,2,3,5,8,13,21,etc.
 Exponential: 1,2,4,8,16,32,etc.

Estimating Size in Story Points
 Story Points:
 The “bigness” of a backlog item
 Influenced by how hard it is, how much there is
 Unit is arbitrary, but relative
 (6 story point item) should be 2x(3 story point
item)
 Estimate of getting the story “Done”

Estimating with Planning Poker
 Iterative, team based approach
1. Each estimator has a deck of cards with
potential estimates based on set (Fibonacci,
etc.)
2. Product Owner reads a backlog item, brief
clarifying discussion occurs
3. Estimators choose a card indicating their
estimate
4. Cards are revealed all at once
5. Differences are discussed, especially outliers

Two levels of planning
Release Planning Sprint Planning
Goal Enable product level decisions such
as scope, release date, resources
required
Enable the scrum team to commit to
a specific set of work for a given
sprint
Led By Product Owner Product Owner + Scrum Team
Artifac
t
Product/Release Backlog Sprint Backlog
Items User Stories/Features Tasks
Units Story Points Task Hours
Units
over
time
Velocity Capacity
Don’t confuse the goal, items, or units from one level with the
activities of the other!

Building a Release Plan
 Create Product Backlog
 One Line Item – but can be months of work
 Product Owner leads
 Market Research, positioning, etc.
 Estimate relative sizes
 Determine team velocity
Pr
i
Story Size
1 As an editor, I want a new... 5
2 As a Sys Admin, I need a
wa...
8
3 As a novice user, I want a
pe...
13
4 As a test engineer, I want
to...
13
5 As a pro photographer, I
wa...
2
6 As an unregistered user, I
ne...
3
7 As a user that never
restarts...
8
8 As a developer, I need to
ver...
20

Velocity
 Total story points for all product backlog items
meeting the definition of done at the end of a
sprint
 Averaged over time
 Three ways to calculate:
1. Based on historical values
2. Ideally after a sprint or two
3. Forecasted when necessary

Projecting Velocity when historic
values aren’t available
Pr
i
Story Size
wa...
8
pe...
13
to...
13
wa...
2
ne...
3
restarts...
8
8 As a developer, I need to 20
 Choose a few stories
Pr
i
Story Size
wa...
8
pe...
13
to...
13
5 As a pro photographer, I 2
 Break down to tasks, estimate
Task
Hours
128
210
272
225
45
Totals: 41 880
 Compare totals to sprint capacity
Sprint Capacity = ~900 Hours
 Calculate Sprint Capacity
Projected Velocity = ~ 42 story points per sprint
 Estimate Velocity per sprint

Calculating Average Velocity
(historic)
 Average (30)
0
5
10
15
20
25
30
35
40
45
1 2 3 4 5 6 7 8 9 10 11
Velocity
Last 8 sprints
 Worst Case (23)
Lowest 3
 Best Case (38)
Highest 3

Building a Release Plan
 Create Product Backlog
 Estimate relative sizes
 Determine team velocity
Pr
i
Story Size
wa...
8
pe...
13
to...
13
wa...
2
ne...
3
restarts...
8
8 As a developer, I need to
ver...
20
 Average (30)
Sprint 1
26 points
May4-May31
Sprint 2
26 points
Jun1-Jun28
Sprint 3
30 points
Jun29-Jul26
Sprint 4
30 points
Jul27-Aug23
 Update after each sprint

Agile Development with Scrum.pptx

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Agile Development with Scrum.pptx

Ähnlich wie Agile Development with Scrum.pptx (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agile Development with Scrum.pptx

Hinweis der Redaktion