Microsoft Services Premier Support Orientation and …7.pdfJeff Sutherland Initial scrums at Easel...
89
Scrum Development Overview Fabrizio Morando Application Development Manager venerdì 30 novembre 2012
Transcript of Microsoft Services Premier Support Orientation and …7.pdfJeff Sutherland Initial scrums at Easel...
Scrum DevelopmentOverview
Fabrizio Morando
Application Development Manager
venerdì 30 novembre 2012
• 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 in 100 words
Scrum originsJeff 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
• Yahoo
• Electronic Arts
• High Moon Studios
• Lockheed Martin
• Philips
• Siemens
• Nokia
• Capital One
• BBC
• Intuit
• Intuit
• Nielsen Media
• First American Real Estate
• BMC Software
• Ipswitch
• John Deere
• Lexis Nexis
• Sabre
• Salesforce.com
• Time Warner
• Turner Broadcasting
• Oce
Scrum has been used for:
Commercial software
In-house development
Contract development
Fixed-price projects
Financial applications
ISO 9001-certified applications
Embedded systems
24x7 systems with 99.999% uptime requirements
the Joint Strike Fighter
•Video game development
•FDA-approved, life-critical systems
•Satellite-control software
•Websites
•Handheld software
•Mobile phones
•Network switching applications
•ISV applications
•Some of the largest 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 there’s 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
encourages
feedback – when
users can see and
touch the product
they can immediately
tell if it is what they
want
Working software
helps a team gauge
its progress – work
shown to be
complete allows for
real progress to be
identified
Working software
allows product to be
shipped early if
desired – the opion
to ship early can be
very valuable to your
customer to allow for
markets that change
rapidly
The Agile Manifesto – a statement of values
Process and toolsIndividuals and
interactionsover
Following a planResponding to
changeover
Source: www.agilemanifesto.org
Comprehensive
documentationWorking software over
Contract negotiationCustomer
collaborationover
Project noise level
Simple
Complex
Anarchy
Technology
Requirem
ents
Far from
Agreement
Close to
Agreement
Clo
se t
o
Cert
ain
ty
Far
from
Cert
ain
ty
Source: Strategic Management and
Organizational Dynamics by Ralph
Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike
Beedle.
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 today’s competitive
requirements
Hirotaka Takeuchi and Ikujiro Nonaka, “The
New New Product Development Game”, Harvard Business Review, January 1986.
Scrum
Cancel
Gift wrap
Return
Sprint
2-4 weeks
Return
Sprint goal
Sprint
backlogPotentially shippable
product increment
Product
backlog
CouponsGift wrap
Coupons
Cancel
24 hours
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
Predictive:
All planning is
done at the
beginning
Planning Doing
Planning Doing
Empirical:
JIT planning and re-
planning based on
frequent inspection
P D P D P D
Agile : Demming cycle (PDCA)
• Sprint
• Daily Scrum
• Burndowncharts
• Impediments
• Sprint Planning
• Sprint Retrospective
Act Plan
DoCheck
Sprints
Scrum projects make progress in a series of “sprints”
Analogous to Extreme Programming iterations
Typical duration is 2–4 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
Source: “The New New Product Development Game” by
Takeuchi and Nonaka. Harvard Business Review,
January 1986.
Rather than doing all of one
thing at a time...
...Scrum teams do a little of
everything all the time
Requirements Design Code Test
No changes during a sprint
Plan sprint durations around how long you can commit to keeping
change out of the sprint
Change
Scrum framework
•Product owner
•ScrumMaster
•Team
Roles
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Product owner
•ScrumMaster
•Team
Roles
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 PO’s 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 functionaldevelopment team:
o Interfacing with devs and PO to make sure stories are understoodand 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
•Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
•Release planning
•Sprint planning & Sprint
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
Release Planning meetingPurpose is to decide: HOW – WHAT – WHEN
• HOW can we trun the vision into a winning product
• HOW can we meet or exceed the desired customers satisfaction
• HOW can we make the ROIHOW
• MOSCOW – Mst,Should,Could,Would
• Risk \ Goal
• Re-estimating and re-prioritisingWHAT
• Probabile delivery date
• Number of sprints based on what is knownWHEN
Requirements Management
M
S
C
75% of the estimated
Effort
(more is a risk)
It’s a negotiation
With customer
Release Planning meeting
Four Variables
Scope:
How much isto be done
Resources:
How manypeople are available
Time:
When will itbe
completed
Quality:
How goodand how it
well is tested
DoD
Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint
goal (design)
• Create sprint backlog (tasks)
from product backlog items
(user stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Technology
Current
product
Sprint Planning Meeting
Sprint Planning Meeting• The team decide how it will turn what was selected during the
first half of the meeting (sprint prioritization) into a doneincrement1
• Team design work2
• Breakdown work into tasks3
• Task list is detailed pieces of work (sprint backlog)4
• Task should be less than one day work5
• Team can assing work here or JIT during a sprint6
Sprint Planning Meeting
Sprint backlog is product backlog decomposition
o PBI’s 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
1• Scrum master facilitates
2• Team work without interruptions
3• No additions to User Stories are allowed
4
• Tasks may be re-estimated \ created \ cancelled on the way
5
• Team choose what they want to work on from sprint 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 meetingTeam 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
These are not status for the ScrumMasterThey are commitments in front of peers
What did you do yesterday?1
What will you do today?2
Is anything in your way?3
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:
Only mandatory attendees speak to each other
Chickens are there to observe
Pigs: committed members
Scrum master, Product
Owner, Team
Chickens:
Involved members
Customer, Management,
Stakeholders, etc..
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 reviewHeld 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 howteam have
delivered on itscommittments
Show overallprogess
Reviewfunctionality
that has beencompleted
Review productbacklog
Sprint review
Show how team have delivered on its committments
Scrum Master should
review and summarize the
sprint goal
• How many stories did we plan?
• Haw many points did we plan
• Dod
• Effort to be invested
Scrum Master should then
present a summary of the work
accomplished on the sprint
• How many stories are done
• How many story points
completed
• Effort: planned vs actual
Sprint review
Show overall progess
Show the update Release Burndownchart
Look at quality
Number of unit & acceptance testsdefined ad passed, Number of bugs
Review cost against the project
Sprint review
Review functionality that has been completed
Do not show partially completed work !
1 DemonstrateFinishedfunctionality
2 Do they fulfilthe agreedconditions of satisfaction?
3 Discusswhat hasbeen seenand what to do next
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 15–30 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 they’d like to:
• What went right
• What went wrong
• What would we change
• Actions to be assigned
• Can include discussion on processes,
practices, communication, environment,
artefacts, tools, etc…
Start doing
Stop doing
Continue doing
This is just one of many ways to do a sprint retrospective.
•Product owner
•ScrumMaster
•Team
Roles
Scrum framework
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Ceremonies
•Product backlog
•Sprint backlog
•Burndown charts
Artifacts
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
Reprioritized at the start of each sprint
This is the
product backlog
A sample product backlogBacklog item Estimate
Allow a guest to make a reservation 3
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-per-available-room)8
Improve exception handling 8
... 30
... 50
Sample Product Backlog
Product Backlog: DEEP
DEEP
Detailed
Estimated
Emergent
Prioritized
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 team’s 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 pbi’s
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 PBI’s
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 two’s probable PB is actionable
The sprint goal
A short statement of what the work will be focused on during the
sprint
Database
Application
Financial services
Life Sciences
Support features necessary for
population genetics studies.
Support more technical
indicators than company
ABC with real-time,
streaming data.
Make the application run on
SQL Server in addition to
Oracle.
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
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the foo class
Mon
8
16
8
12
8
Tues
4
12
16
8
Wed Thur
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8
Features are broken into tasks
Try to break down into about one day work
Sprint Backlog
9 tips for creating a good SB (from Scrum Alliance 24-03-09)
Involve
every team
member
1
Discuss how
every SBI
should be
implemented
2
Have a DoD
3
Identify all
kinds of
tasks
4
Don’t
estimate
tasks at all
5
Don’t assign
tasks up
front
6
Review
Sprint
committmen
t
7
Don’t use
too much
time
8
Evolve the
SB during
the sprint
9
A sprint burndown chartH
ou
rs
Hours
40
30
20
10
0Mon Tue Wed Thu Fri
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Mon
8
16
8
12
Tues Wed Thur Fri
4
12
16
7
11
8
10
16 8
50
Agile: Estimating
Why do it?
Reducing \ Highlighting risk
Reducin uncertainty
Support better decision making
Estabilish trust
Conveying information
IT IS NOT
COMMITTING !!!
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>
In order to <benefit> as a <type of user> I can <feature>
OR
User stories
US’s drive the release
and sprint planning
Estimatable
Can be delivered
withing a sprint
Small
Each story must have
a condition of
satisfaction
Testable
At the library…
As a borrower, I want to
be able to take a book
out and keep it for two
weeks
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
Break down into
smaller stories
!!!
User Stories
• Are they stand aloneI - Independent
• Capture the essence but can add more over timeN - Negotiable
• Is this valuable to the customer and to the buinessV - Valuable
• Can the story be estimatedE – Estimable
• Smaller stories tend to be sized more accuratelyS – Small
• What are the acceptance testT – Testable
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 customer
language !!!
User Stories
Are in the developer
language
Are written as small discrete
items of work
Are the detailed plan for the
sprint
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
• S M LT-shirt
• Assign points independently than discuss and assign again (and again, and again…)Delphi
• 0,1,2,3,5,8,13,20 …Scale
• Each member has a set of cards with points and declares his\her handPoker cards
• Rock Paper ScissorsRPS
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 sprintDO 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
m
A Scrum reading list
Agile and Iterative Development: A Manager’s 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 Share―to copy, distribute and and transmit the work
to Remix―to 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 author’s moral rights.
For more information seehttp://creativecommons.org/licenses/by/3.0/
Contact information
Presentation by: Mike Cohn
m
www.mountaingoatsoftware.com
(720) 890-6110 (office)
Thank You
