Scrum Development

Overview

Fabrizio Morando
Application Development Manager

venerd 30 novembre 2012

Scrum in 100 words
Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time.
It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
The business sets the priorities. Teams self-organize
to determine the best way to deliver the highest priority
features.
Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.
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 the Agile Alliance
Scrum has been used by:
Microsoft Intuit
Yahoo Nielsen Media
Google First American Real Esta
Electronic Arts BMC Software
High Moon Studios Ipswitch
Lockheed Martin John Deere
Philips Lexis Nexis
Siemens Sabre
Nokia Salesforce.com
Capital One Time Warner
BBC Turner Broadcasting
Intuit Oce
Scrum has been used for:
Commercial software Video game development
In-house development FDA-approved, life-critical
systems
Contract development
Fixed-price projects
Satellite-control software
Financial applications
Websites
ISO 9001-certified
Handheld software
applications Mobile phones
Embedded systems Network switching applications
24x7 systems with 99.999% ISV applications
uptime requirements
Some of the largest
the Joint Strike Fighter applications in use
Characteristics
Self-organizing teams
Product progresses in a series of
month-long sprints
Requirements are captured as items in a
list of product backlog
No specific engineering practices
prescribed
Uses generative rules to create an agile
environment for delivering projects
One of the agile processes
Why Agile
Agile software developmment is a group of lightweight software
development methodologies based on iterative and incremental
development, where requirements and solutions evolve through
collaboration between self-organizing, cross functional teams.

Main elements of agile:

o Iterative
o Adaptable
o Rapid
o Cooperative
o Quality Driven
Agile: What are the benefits?
Iterative and adaptive
Customer can see quickly at what stage the development is
Every 2-4 week theres a potentially shippabile product increment
Feedback is given routinely and often
Plans are in short durations (iterations) so change can be implemented
quicker
Wasted development is reduced
Prioritized features developed as mandatory
Why working software

Working software
Working software
Working software allows product to be
encourages
helps a team gauge shipped early if
feedback when
its progress work desired the opion
users can see and
shown to be to ship early can be
touch the product
complete allows for very valuable to your
they can immediately
real progress to be customer to allow for
tell if it is what they
identified markets that change
want
rapidly
The Agile Manifesto a statement of
values

Individuals and
over Process and tools
interactions
Comprehensive
Working software over
documentation
Customer
over Contract negotiation
collaboration
Responding to
over Following a plan
change
Source: www.agilemanifesto.org
Project noise level

Far from
Agreement
Anarchy
Requirements

Complex

Source: Strategic Management and

Organizational Dynamics by Ralph
Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike
Close to Simple Beedle.

Agreement
Certainty

Certainty
Close to

Far from
Technology
What is Scrum?
Scrum employs an iterative, incremental approach to optimize
predicability and control risk

A holistic or rugby
approach where a team
tries to go to the distance as
unit, passing the ball back
and forth may better
serve todays competitive
requirements

Hirotaka Takeuchi and Ikujiro Nonaka, The

New New Product Development Game,
Harvard Business Review, January 1986.
Scrum 24 hours

Sprint
2-4 weeks
Sprint goal
Return
Sprint
Potentially shippable
Cancel
Return backlog
product increment
Coupons
Gift wrap
Gift
Cancel
wrap Coupons
Product
backlog
Putting it all together

Image available at
www.mountaingoatsoftware.com/scrum
Agile : Scrum framework

Scrum should not be viewed as a collection of

practices but rather as a culture or a set of values
- Ken Schwaber

Basic principals are:

o Define success
o Define failure
o Optimize the process for success
Agile : Scrum framework
Scrum employs an iterative, incremental approach to optimize
predicability and control risk upon three pillars of empirical process
control:

Transparency
o The aspects of the process that affect the outcome are visible
Inspection
o Frequent enaugh inspection allow the detection of unacceptable variances
Adaption
o If inspection reveals elements outside acceptable limit possible to minimize further
deviation
Agile : Scrum framework

Planning Doing

Predictive: Empirical:
All planning is JIT planning and re-
done at the planning based on
beginning frequent inspection

P D P D P D
Planning Doing
Agile : Demming cycle (PDCA)

Sprint Sprint
Retrospective Planning

Act Plan

Check Do
Daily Scrum
Burndown Sprint
charts
Impediments
Sprints
Scrum projects make progress in a series of sprints
Analogous to Extreme Programming iterations
Typical duration is 24 weeks or a calendar month at most
A constant duration leads to a better rhythm
Product is designed, coded, and tested during the sprint
Sequential vs. overlapping
development

Requirements Design Code Test

Rather than doing all of one

thing at a time...

...Scrum teams do a little of

everything all the time

Source: The New New Product Development Game by

Takeuchi and Nonaka. Harvard Business Review,
January 1986.
No changes during a sprint

Change

Plan sprint durations around how long you can commit to keeping
change out of the sprint
Scrum framework
Roles
Product owner
ScrumMaster
Team Ceremonies
Sprint planning
Sprint review
Sprint retrospective
Daily scrum meeting
Artifacts
Product backlog
Sprint backlog
Burndown charts
Scrum framework
Roles
Product owner
ScrumMaster
Team Ceremonies
Sprint planning
Sprint review
Sprint retrospective
Daily scrum meeting
Artifacts
Product backlog
Sprint backlog
Burndown charts
Product owner
Define the features of the product
Decide on release date and content
Be responsible for the profitability of the product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as needed
Accept or reject work results

Owns the Product Backlog

Accepts work as completed (Done)
Negotiates priorities with team
Get stakeholders to define roadmap
Manage relationship with stakeholders
The ScrumMaster
Represents management of SCRUM
(not a team leader)
Responsible for enacting Scrum values and
practices
Removes impediments
Ensure that the team is fully functional and
productive
Enable close cooperation across all roles
and functions
Shield the team from external interferences
The ScrumMaster
Ensures the SCRUM process is followed and understood
No formal authority over dev team (except on following
the process)
FACILITATOR
Works with PO to maximize ROI and meet objectives
Improve the engineering practices and tools so that each
increment of functionality is potentially shipped
Handling time in sprint planning meetings to ensure the
sprint contains non productive time

Ensure Definiton of Done (DoD) agreed

Does not assign tasks to team members
Does not make decisions for team without their
authority
The team

Typically 5-9 people

Cross-functional:
Programmers, testers, user experience designers, etc.
Members should be full-time
May be exceptions (e.g., database administrator)

The development team consists of developers

with all the skills to turn the POs requirements into
a potentially releasable slice of the product by the
end of a sprint
The team

Teams are self-organizing

o Ideally, no titles but rarely a possibility

Membership should change only between sprints

Testers are part of the cross functional
development team:
o Interfacing with devs and PO to make sure stories are understood
and acceptance test track desired functionality
o Writing acceptance test code while code is written
o Develop ongoing test automation to integrate acceptance and
feature tests into C.I. environment
Scrum framework
Roles
Product owner
ScrumMaster
Team
Ceremonies
Release planning
Sprint planning & Sprint
Sprint review
Sprint retrospective
Daily scrum meeting
Artifacts
Product backlog
Sprint backlog
Burndown charts
Release Planning meeting
Purpose is to decide: HOW WHAT WHEN

HOW can we trun the vision into a winning product

HOW HOW can we meet or exceed the desired customers

satisfaction
HOW can we make the ROI

MOSCOW Mst,Should,Could,Would

WHAT Risk \ Goal

Re-estimating and re-prioritising

WHEN Probabile delivery date

Number of sprints based on what is known
Requirements Management

C
75% of the estimated S
Effort
(more is a risk)

Its a negotiation
M With customer
Release Planning meeting
Four Variables

Resources: Time: Quality:

Scope:
How many When will it How good
How much is
people are be and how it
to be done
available completed well is tested

DoD
Sprint Planning Meeting
Team
Sprint planning meeting
capacity
Sprint prioritization

Product Analyze and evaluate product Sprint

backlog backlog goal
Select sprint goal

Business
conditions Sprint planning
Decide how to achieve sprint
Current goal (design)
Sprint
product Create sprint backlog (tasks) backlog
from product backlog items
(user stories / features)
Technology Estimate sprint backlog in hours
Sprint Planning Meeting
The team decide how it will turn what was selected during the
1 first half of the meeting (sprint prioritization) into a done
increment

2 Team design work

3 Breakdown work into tasks

4 Task list is detailed pieces of work (sprint backlog)

5 Task should be less than one day work

6 Team can assing work here or JIT during a sprint

Sprint Planning Meeting
Sprint backlog is product backlog decomposition

o PBIs are often decomposed by acceptance tests

o Depending on time, sprint work for the next several days is less than
one day in lenght, larger sprint work can be decomposed during the
sprint
o Development team members sign up for work they are not assigned
o Work for the sprint emerges
o Work remaining is re-esitmated and updated daily
Sprint
A time-boxed period of software development
An iteration
A given list of goals
Typically 2-4 weeks in lenght
Team work on the set of features defined in the sprint planning
meeting

This may lead to

some critical
questions
Sprint
Scrum master facilitates
1

Team work without interruptions

2

No additions to User Stories are allowed

3

Tasks may be re-estimated \ created \ cancelled on

4 the way

Team choose what they want to work on from sprint

5 backlog
Definition of Done
Needs to be defined in advance
Clearly stated
Agreed by PO and team
Conditions of satisfaction

Dod must be
understood by
everyone in the
scrum team !!!
Sprint: Abnormal Termination
Sprints can be terminated or abandones before the timebox
PO is the only one who can cancel a sprint
Termination can happen for variuos reasons: changes in competition,
technology, business
It is time consuming to cancel a sprint because you have to have a
sprint review for work that has been completed, understand what to
do with the unone work, hold a retrospective and re-plan for another
sprint
Sprint planning meeting
Team selects items from the product backlog they
can commit to completing
Sprint backlog is created
Tasks are identified and each may be estimated (1-16
hours)
Collaboratively, not done alone by the ScrumMaster
High-level design is considered
As a vacation planner, I want to
see photos of the hotels. Code the middle tier (8 hours)
Code the user interface (4)
Write test fixtures (4)
Code the foo class (6)
Update performance tests (4)
The daily scrum
Parameters
Daily
15-minutes
Stand-up
Not for problem solving
Whole world is invited
Only team members, ScrumMaster, product owner, can
talk
Helps avoid other unnecessary meetings
Everyone answers 3 questions
1
What did you do yesterday?

2
What will you do today?

3
Is anything in your way?

These are not status for the ScrumMaster

They are commitments in front of peers
Daily Scrum : Why
To enable communication and collaboration between team members
To give focus and ensure sprint is still on track
Used a the smallest tightest feedback loop
To enable understanding of impediments or problems that may arise
and that are hindering current sprint
Facilitates actions for discussion later
Show ability for self organization and task sharing
Ability to identify quickly any issues arising
Daily Scrum: Who
Attendees:

Chickens:
Pigs: committed members
Involved members

Scrum master, Product Customer, Management,

Owner, Team Stakeholders, etc..

Only mandatory attendees speak to each other

Chickens are there to observe
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
Sprint review
Held at the end of every sprint to assess progress
against the sprint goal and for everyone involved
including customers, management and stakeholders to
inspect what was produced in the last sprint, to see
progress and to give acceptance or feedback.

Show how Review

team have Show overall functionality Review product
delivered on its progess that has been backlog
committments completed
Sprint review
Show how team have delivered on its committments

Scrum Master should Scrum Master should then

review and summarize the present a summary of the work
sprint goal accomplished on the sprint

How many stories did we plan? How many stories are done
Haw many points did we plan How many story points
Dod completed
Effort to be invested Effort: planned vs actual
Sprint review
Show overall progess

Show the update Release Burndown

chart

Look at quality
Number of unit & acceptance tests
defined ad passed, Number of bugs

Review cost against the project

Sprint review
Review functionality that has been completed

Demonstrate Do they fulfil Discuss

1

3
Finished the agreed what has
functionality conditions of been seen
satisfaction? and what to
do next

Do not show partially completed work !

Sprint review
Review product backlog
Discuss what has been seen and what to do next
Reprioritize product backlog if necessary

That should be easy: best practice is to detail forecast

at least the next 2 sprints
Sprint retrospective
Periodically take a look at what is and is not working
Typically 1530 minutes
Done after every sprint
Whole team participates
ScrumMaster
Product owner
Team
Possibly customers and others
Start / Stop / Continue
Whole team gathers and discusses what theyd like to:
What went right
What went wrong
Start doing What would we change
Actions to be assigned

Stop doing

Continue doing
This is just one of
many ways to do a Can include discussion on processes,
sprint practices, communication, environment,
retrospective. artefacts, tools, etc
Scrum framework
Roles
Product owner
ScrumMaster
Team Ceremonies
Sprint planning
Sprint review
Sprint retrospective
Daily scrum meeting
Artifacts
Product backlog
Sprint backlog
Burndown charts
Product backlog
The requirements
A list of all desired work on
the project
Ideally expressed such that
each item has value to the
users or customers of the
product
Prioritized and owned by the
product owner
Groomed by team
This is the
Reprioritized at the start of
product backlog each sprint
A sample product backlog
Backlog item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a
5
reservation.
As a guest, I want to change the dates of
3
a reservation.
As a hotel employee, I can run RevPAR
8
reports (revenue-per-available-room)
Improve exception handling 8
... 30
... 50
Sample Product Backlog
Product Backlog: DEEP

Detailed

Prioritized DEEP Estimated

Emergent
PB: Detailed Appropriately
Higher priority items described in more detail, smaller and
more coincise, lower priority items have less detal as they
cam be detailed later in the release. This keeps the backlog
concise, as a consequence requirements are discovered
throughout the project.
Product discovery is ongoing
PB: Estimated and Emergent
Estimated
The PB items are roughly estimated in story points or
days leave detailed planning to the sprint planning
meeting
Emergent
The PB evolves throughout the project, the content
changes with user feedback and as the product is
developed new areas can be uncovered IT IS DYNAMIC
!!!
PB: Prioritised
All items are prioritised, the most important are
implemented first.
Useful factors for prioritising are:
Value, knowledge, uncertainty, risk, releasability and
dependences
Priorities direct teams work

Yes they are there !

PB: Rules of thumb
Try to keep PB list to less then 100 items
Group related items into 1 PBI to be managed as a group
Remove items not directly aligned with the product roadmap (the
sounds like a good idea
The top 20 to 40 highest priority items are an appropriate size to fit
into the development team upcoming sprints
Use velocity after 1 or 2 sprints
Put acceptance criteria on top 20-40 pbis
Ensure the sprint has the same lenght to bring rhythm to the team
Every PBI should have a value and a business benefit
Generate a release burndown from emergent PB
PB: Grooming
Remember to groom the PB often
Ongoing process
New requirements that are added to bottom of the PB when
discovered
Prioritise new PBIs
Hight priority requirements are deomposed and prepared for next
sprint planning
Requirements are estimated
Team reserve about 10% of their availability for grooming during
a sprint
Ensure next sprint or twos probable PB is actionable
The sprint goal
A short statement of what the work will be focused on during the
sprint

Life Sciences
Support features necessary for
Database population genetics studies.
Application
Make the application run on
SQL Server in addition to
Oracle. Financial services
Support more technical
indicators than company
ABC with real-time,
streaming data.
Sprint Backlog

Newly
Added !!!
Managing the sprint backlog
List of tasks the scrum team is committing they
will complete in the current sprint
Pulled together during the sprint planning
meeting
Team decide on the items and time required to
complete them
Scrum master updates during sprint to reflect
which tasks are completed
Managing the sprint backlog
Individuals sign up for work of their own choosing
Work is never assigned this promotes self organization

Estimated work remaining is updated daily

Any team member can add, delete or change the
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
A sprint backlog
Features are broken into tasks
Try to break down into about one day work

Tasks Mon Tues Wed Thur 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
Sprint Backlog
9 tips for creating a good SB (from Scrum Alliance 24-03-09)

Discuss how
Involve
every SBI
Identify all Dont
every team Have a DoD kinds of estimate
should be
member tasks tasks at all
implemented

1 2 3 4 5

Review
Dont assign Dont use Evolve the
Sprint
tasks up too much SB during
committmen
front time the sprint
t

6 7 8 9
A sprint burndown chart
Hours
 Tasks Mon Tues Wed Thur 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
Agile: Estimating
Why do it?

Reducing \ Highlighting risk

Reducin uncertainty
Support better decision making IT IS NOT
Estabilish trust COMMITTING !!!
Conveying information

Estimates are not set in a stone

They are a base
User Stories
These are used for describing requirements or features form the
prespective of the person or user who desires the new feature or
capability of the system

As a <type of user> I want <some goal> so that <some reason>

OR

In order to <benefit> as a <type of user> I can <feature>

User stories

Each story must have

USs drive the release Can be delivered
a condition of
and sprint planning withing a sprint
satisfaction

Estimatable Small Testable

 At the library
As a library clerk I want
to be able to check out
a book, know who has
the book and how long
they can have it before
it is due back

As a borrower, I want to
be able to take a book
out and keep it for two
weeks

Break down into

smaller stories
!!!
User Stories
I - Independent Are they stand alone

Capture the essence but can add more over

N - Negotiable time

Is this valuable to the customer and to the

V - Valuable buiness

E Estimable Can the story be estimated

Smaller stories tend to be sized more

S Small accurately

T Testable What are the acceptance test

User Stories
Acceptance tests:
Acceptance testing is the process of verifying that stories
were developed such that each works exactly the way
the customer expects it to work
These need to be completed for every user story
These are the TOOL for the PO to accept the story and
the development team to know when they are done to
enable them to get acceptance of a US
User Stories vs Tasks

Are in the developer

language
Are in the customer Are written as small discrete
language !!! items of work
Are the detailed plan for the
sprint

User Stories Tasks

User Stories : Pointing
Story points are a unit of measure for expressing the
overall size of a user story, feature or other piece of work
We assing a point value on each item
The raw values are unimportant it is the relative values
that are important: a story that is 4 points must be double
to the size of one thai is 2 points and half the size of one
that is 8 points
A good way to start pointing is to look at a medium
story\task that is easily measured, assign it a number of
points and than base all other on that choice
User Stories : Pointing
Use various methods

T-shirt SML

Assign points independently than discuss

Delphi and assign again (and again, and again)

Scale 0,1,2,3,5,8,13,20

Each member has a set of cards with points

Poker cards and declares his\her hand

RPS Rock Paper Scissors

Velocity
In an agile world, velocity is the amount of work the team is able to do
in one iteration
It can be based on experience from previous sprints or estimated for
the first couple of sprints
Prefer empirical measure to real time (using days \ hours is not
sugegested)
Calculation with story points is a statistical way to measure progress. If
you use the same prerequisite and facts each time, you get better at
measuring how many points can be delivered in a sprint DO NOT
COMPARE
VELOCITY
BETWEEN
TEAMS!!!
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 through the Scrum of scrums
Scrum of scrums of scrums
Where to go next
www.mountaingoatsoftware.com/scru
m
www.scrumalliance.org
www.controlchaos.com
scrumdevelopment@yahoogroups.co
m
A Scrum reading list
Agile and Iterative Development: A Managers Guide by Craig
Larman
Agile Estimating and Planning by Mike Cohn
Agile Project Management with Scrum by Ken Schwaber
Agile Retrospectives by Esther Derby and Diana Larsen
A Scrum reading list
Agile Software Development Ecosystems by Jim Highsmith
Agile Software Development with Scrum by Ken Schwaber
and
Mike Beedle
Scrum and The Enterprise by Ken Schwaber
Succeeding with Agile by Mike Cohn
User Stories Applied for Agile Software Development by Mike
Cohn
Copyright notice
You are free:
to Shareto copy, distribute and and transmit the
work
to Remixto adapt the work
Under the following conditions
Attribution. You must attribute the work in the
manner specified by the author or licensor (but not
in any way that suggests that they endorse you or
your use of the work).
Nothing in this license impairs or restricts the authors moral
rights.

For more information see

http://creativecommons.org/licenses/by/3.0/
Contact information
Presentation by: Mike Cohn
mike@mountaingoatsoftware.co
m
www.mountaingoatsoftware.com
(720) 890-6110 (office)
Thank You