SCRUM Tutorial Common Sense

Scrum TutoriuI
Advanced Development Methods 2003 All Rights Reserved

1
Scrum
If Depends on
Common Sense
http://www.controlchaos.com
http://www.agilealliance.org
Ken.schwaberverizon.net
Scrum TutoriuI
2
Reud this Progect uckground
Today's date is December 7, 2003. You have been selected to be part of a team for a complex
project with a compressed schedule. Although the general nature of what is wanted is
known, the specific functionality that will implement it will have to be determined as the
project progresses.
Background:
Overall attendance at baseball games has increased over the last ten years. n some cities, such
as Boston, almost all games are sold out and obtaining tickets through normal channels is
nearly impossible. Major League Baseball (MLB) rules prohibit the resale of tickets at a
profit. Scalping is illegal and has been recently limited. The primary distribution channel for
buying tickets is eBay. Although all auctions for tickets on eBay are supposed to be capped
at the retail price plus expenses, MLB has learned that, through a variety of workarounds,
these tickets are being scalped for prices of up to 1000% of the retail price.
Project:
The MLB Commissioner's office has commissioned a project to control the resale of baseball
tickets. Through recent legislation, as of the 2004 baseball season, all ticket resale can only
take place through facilities authorized by MLB. MLB has decided to develop such a facility
solely for its own purposes, through the presence of a dedicated website. The site will be
known as MLBTix
Through functionality similar to eBay, but specific to MLB, buyers and sellers will be able to sell
and buy tickets online. Sellers will auction the tickets to the highest bidder through an
auction capability. The seller sets an initial bidding price of their own choice without floor or
ceiling conditions established by MLBTix. The seller can also limit the duration of the
auction, setting a start and end date and time. f the ticket(s) are successfully sold, the buyer
pays the seller through MLBTix credit card facilities.. Then the seller will mail or express the
tickets to the seller. MLBTix will have a facility for the buyer to notify it when the tickets have
been received, at which time MLBTix will mail a check for the proceeds (less 25% MLB fee
that is deducted) to the seller.
The Commissioner will be announcing MLBTix at a news conference on January 15. He hopes for
some functionality to be available by opening day on March 30, 2004, and for the site to be
fully functional by the All Star break on July 18, 2004. The anticipated release schedule is:
Scrum TutoriuI
3
1. March 30, 2004 MLBtix site is up. Buyers and sellers can register. Sellers can make
tickets available at a fixed price, which buyers can pay in full via credit card. MLBTix is a
middleman, all transfer of tickets is between buyer and seller. MLBTix receives 25%
commission for all transactions.
2. June 30, 2004 same as March 30 release except full-functioning auction capability is
present.
3. August 30, 2004 - same as June 30, except buyers are able to get groups of collocated
tickets, view the locations in parts, check inventory.
Funds for the project are ample and should not be considered an unreasonable constraint.. The
date and functionality are the deliverables. Facilities or packaged software to support
MLBTix can be either bought or developed, whichever supports meeting the date. The
Commissioner needs a heads up on the likelihood that the MLBTix will be available by the
above dates prior to his press conference.
Scrum TutoriuI
4
Functional Requirements:
Register as a potential seller of tickets and be assigned a userid and password.
Register as a potential buyer of tickets and be assigned a userid and password.
Maintain a profile under the userid, including email, addresses, preferences, and credit card
information.
Place tickets up for auction, declaring a floor price, start of auction time/date, and end of
auction time/date. ndicate sufficient information so that buyers can ascertain that the tickets
meet their requirements (for the right days, right teams, right number of seats located next to
each other, and the seat locations in the ball park).
Conduct an auction for the tickets to registered buyers.
Successfully conclude the auction by awarding the tickets to the highest bidder by the end
date and, at the same time, debiting the buyers credit card and placing the funds in a
MLBTix account.
Notifying the seller of the successful sale of the tickets and the delivery information for the
buyer.
Providing the buyer with a mechanism for indicating that the tickets were not successfully
received by the selling date plus a specified period of time (a week?).
Transferring the funds for the ticket sale less 25% to the seller at the end of the specified
delivery time, unless the buyer has indicated otherwise.
Transferring the 25% plus any interest to a corporate MLB account from the MLBTix account
automatically.
Providing inventory and inventory search capabilities for teams, tickets, dates, and seats
within park.
Providing for promotions on MLBTix.
Ability to identify and ban abusers of MLBTix.
Scrum TutoriuI
5
Nonfunctional Requirements:
250,000 simultaneous users with subsecond response time.
Secure for the level of financial activity envisioned (2,000 tickets per day at an
average selling price of $50).
Scalable to 1,000,000 simultaneous users as needed.
99% availability 24x7.
Development Context:
1. A development environment for building Microsoft .Net products is ready for you.
The system will be built using ntel technology and .Net software running on SQL
Server.
2. The development team members all live within easy commuting distance of the
development site.
3. There are currently cubicles in the development site.
4. The development environment is wireless and has all power and networking
capabilities already operating.
5. The development environment uses Microsoft development tools such as Visual
Studio.
6. You are required to use a source code library, check in code every time it's
changed, built the software at least daily, and unit and acceptance test the software
every time that it is built.
7. Scrum will be used as the development practice. Aspects of Extreme Programming
or any other engineering practices, such as coding standards, are up to the team.
8. All of the developers have excellent engineering skills, but they have only heard of
Scrum and Extreme Programming, or used them sparsely so far.
9. The team consists of all development engineers with excellent design and coding
skills. However, they are still responsible for all testing and user documentation.
They may acquire contractors to assist with this. The engineers on the team
average 10 years of progressive experience on software projects using complex
technology and Microsoft products.
10. All team members are baseball aficionados.
11. A QA environment already exists.
12. There are no adequate testing tools, continuous build tools, refactoring tools, and
VSS is perhaps not adequate for the job.
Scrum TutoriuI
6
Scrum
I. Speoker infroducfion - b min
Z. AgiIe fheory ond fromework - 30 min
3. Scrum Process - 30 min
4. Exercise I ond 8reok - 30 min
b. Scrum Meefings - 30 min
o. Exercise Z - 30 min
7. ScoIing ogiIe projecfs - 30 min
Scrum TutoriuI
7
AgiIe
Theory
And
Fromework
Scrum TutoriuI
8
"If is fypicoI fo odopf fhe defined
(fheoreficoI) modeIing opprooch when fhe
underIying mechonisms by which o process
operofes ore reosonobIy weII undersfood.
When fhe process is foo compIicofed for fhe
defined opprooch, fhe empiricoI opprooch is
fhe oppropriofe choice."
Process Dynomics, ModeIing, ond ConfroI,
Ogunnoike ond Poy, Oxford Universify
Press, I99Z
Scrum TutoriuI
9
Commond ond ConfroI for simpIe
projecfs
PIon whof you expecf fo hoppen
Enforce fhof whof hoppens is fhe
some os whof is pIonned
Use chonge confroI fo monoge chonge
Defined Processes
Scrum TutoriuI
10
EmpiricoI Processes
When you con'f define fhings enough so
fhof fhey run unoffended ond produce
repeofobIe, occepfobIe quoIify oufpuf,
EmpiricoI modeIs ore used when fhe
ocfivifies ore nof predicfobIe, ore non-
Iineor, ond ore foo compIex fo define in
repeofobIe defoiI, ond
ConfroI is fhrough inspecfion ond
odopfofion.
Scrum TutoriuI
11
AgiIe
SkeIefon
Product
BackIog:
Doing the
Doing the
Right
Right
Thing
Thing
Eosy fo
impIemenf
wifhin I doy
Improves POI
SoIves
cusfomer
invoIvemenf
Pemoves
fIoundering
ond poIifics
Scrum
Scrum TutoriuI
12
BuiIding the Thing Right
BuiIding the Thing Right
More fime fo impIemenf
SoIid engineering procfices
SoIid engineering infrosfrucfure
XP
Scrum TutoriuI
13
AgiIe Heorf
Lef peopIe figure
ouf fhe righf fhing
fo do, ond fhen do if.
Lef peopIe be
creofive.
OOPSLA'0Z
Doing the
Doing the
Right Thing
Right Thing
the Right
the Right
Way
Way
Hordesf fo
impIemenf
Improves
producfivify
Work becomes
o pIeosure
Scrum
Scrum TutoriuI
14
AgiIe Procfices
AgiIe Ioys ouf o vision ond fhen nurfures
projecf resources fo do fhe besf
possibIe fo ochieve fhe pIon.
AgiIe is fhe "orf of fhe possibIe."
AgiIe empIoys fhe foIIowing procfices:
Frequenf inspecfion
Emergence of requiremenfs,
fechnoIogy, ond feom copobiIifies
SeIf-orgoni;ofion ond odopfofion in
response fo whof emerges
IncremenfoI emergence
DeoIing wifh reoIify, nof orfifocfs
CoIIoborofion
Scrum TutoriuI
15
SCPUM
Scrum TutoriuI
16
Scrum Overview
EmpiricoI monogemenf ond confroI process
for deveIopmenf efforfs,
Used of producf componies ond IT
orgoni;ofions since I990,
Wrops exisfing engineering procfices,
ExfremeIy simpIe buf very hord,
Common sense,
CMM LeveI/Z ond LeveI/3 compIionf,
DeIivers business funcfionoIify in 30 doys,
ScoIobIe, ond
Scrum feeIs compIefeIy differenfl
Scrum TutoriuI
17
every 24 every 24
hours hours
30 30
days days
Scrum: 15 minute daily meeting.
Teams member respond to basics:
1) What did you do since last Scrum
Meeting?
2) Do you have any obstacles?
3) What will you do before next
meeting?
Product Backlog:
Prioritized product features desired by the customer
Sprint Backlog:
Feature(s)
assigned
to sprint
Backlog
items
expanded
by team
New functionaIity
is demonstrated
at end of sprint
Scrum TutoriuI
18
Activity Owner Responsibilities
Manage
the
vision
Product
Owner
The Product Owner establishes, nurtures and communicates the
product vision. He achieves initial and on-going Iunding Ior the
project by creating initial release plans and the initial Product
Backlog.
Manage
the ROI
Product
Owner
The Product Owner monitors the project against its ROI goals and
an investment vision. He updates and prioritizes the Product
Backlog to ensure that the most valuable Iunctionality is produced
Iirst and built upon. He prioritizes and reIines the Product Backlog
and measures success against expenses.
Manage
the
develop
ment
iteration
Team
During an iteration the team selects and develops the highest-
priority Ieatures on the Product Backlog. Collectively, the team
expands Product Backlog items into more explicit tasks on a Sprint
Backlog and then manages its own work and selI-organizes around
how it desires to complete the iteration. The team manages itselI to
its commitments.
Manage
the
process
Scrum
Master
The Scrum Master is responsible Ior setting the team up Ior success
by ensuring the project and organizational culture are optimized Ior
meeting the ROI goals oI the project. This involves organizing a
Sprint Planning Meeting (during which the team expands Product
Backlog into Sprint Backlog), a Sprint Review Meeting (during
which the newly developed Iunctionality is demonstrated), shielding
the team Irom outside disturbances, holding brieI Daily Scrum
meetings, and removing obstacles to progress.
Manage
the
release
Product
Owner
The Product Owner makes decisions about when to create an oIIicial
release. For a variety oI reasons it may not be desirable to release at
the conclusion oI every increment. Similarly, iI an oIIicial release is
planned Ior aIter the IiIth increment it may be released (with Iewer
Ieatures) aIter the Iourth increment in order to respond to
competitive moves or capture early market share. The Product
Owner makes these decisions in a manner consistent with the
investment vision that has been established Ior the project.
PoIes
Scrum TutoriuI
19
PoIes - Producf Owner
DeveIops ond moinfoins fhe
Producf 8ockIog
Priorifi;es fhe Producf
8ockIog
Empowered fo moke decisions
for oII cusfomers ond users
Affends Sprinf pIonning
meefing ond Sprinf review
meefing
Presenfs ond expIoins
Producf 8ockIog fo feom
Scrum TutoriuI
20
Lisf of funcfionoIify, fechnoIogy,
issues
Issues ore pIocehoIders fhof ore
Iofer defined os work
Emergenf, priorifi;ed, esfimofed
More defoiI on higher priorify
bockIog
One Iisf for muIfipIe feoms
Producf Owner responsibIe for
priorify
Anyone con confribufe
Moinfoined ond posfed visibIy
Derived from 8usiness PIon or
Vision Sfofemenf, which somefimes
hove fo be creofed wifh cusfomer.
Producf 8ockIog
Scrum TutoriuI
21
Producf 8ockIog wifh Esfimofes
Scrum TutoriuI
22
JIkdla;IjkdlajI;ds
Ijdkla
Idjklad;
Idjkla;s
Ijdk
Ijkdla;Ijkdal;I
jIkdlsj;a
Ijdkla;
Ijdklas;
Idjkld
Idkjla;
Idjklsa;
IjkIjdkjdkIjkdla;
Ijkdl
Ijkdl;aj
Idjklas;
Ijdklas;kd
Ijkdlas;
Idjkl;a
Ijdklas;
IdjkalIjdask;
jIkdla;
Ijdkla;
Idkjal;
Idjkal;
Idjksla;;daId
Idjkla;
Ijdkla;;asl
Idjksal;
Ijdkl
IdjskIal;Ijkdasl;jI
Ijdklas;I
Ijdkals;
Ijdksal;
IdjsaklIjdslkjIdl
Ijdkla;
Idjkals;dIdjkl
Ijdkla;jId
IdjkaIl;adjI
IdjksIl
Idjkdla;sIdjaskI
IdjkaslI;dI
Idjkasl;j
Ijdksla;I;dsal
Ijdksal;I
Idjsakl;Id
Idjkal;IdIddjIkdl
jIkdal;Ijkdasl;Id
This Sprint : well defined work that can
be done is <30 days & produce executable
Probable next sprint : backlog next in
priority, depends on results from prior
Sprint
During a Sprint, that Sprint's
backlog is fixed and can only be
changed as a result of the work
being performed in that Sprint.
Backlog outside the current
Sprint is always changing,
evolving, and being reprioritized.
Planned
Release
Producf 8ockIog
Scrum TutoriuI
23
SeIf-orgoni;ing,
Cross-funcfionoI wifh no roIes,
Seven pIus or minus fwo,
PesponsibIe for commiffing fo
work,
Aufhorify fo do whofever is
needed fo meef commifmenf,
Synchroni;es of DoiIy Scrum, ond
FuII oufonomy ond oufhorify during
o Sprinf.
PoIes - Scrum Teoms
Scrum TutoriuI
24
Sprinf 8ockIog
Tosks fo furn producf bockIog info working
producf funcfionoIify
Tosks ore esfimofed in hours, usuoIIy I-Io
Tosks wifh more fhon Io hours ore broken
down Iofer
Teom members sign up for fosks, fhey
oren'f ossigned
Esfimofed work remoining is updofed doiIy
Any feom member con odd, deIefe or
chonge fhe Sprinf 8ockIog (fheirs or new)
Work for fhe Sprinf emerges
If work is uncIeor, define o Sprinf 8ockIog
wifh o Iorger omounf of fime , breok if
down Iofer.
Updofe work remoining os more is known, os
os ifems ore worked
Scrum TutoriuI
25
Sprint Backlog
Scrum TutoriuI
26
PoIes - ScrumMosfer
Projecf Monoger
Cooch
PesponsibIe for fhe process
PesponsibIe for moximi;ing
feom producfivify
Sefs up meefings
Conducfs meefings
Pepresenfofive fo
monogemenf
Pepresenfofive fo feom
Chorocferisfics of o border
coIIie or sheepdog.
Scrum TutoriuI
27
Exercise I ond 8reok 30 min
Defermine whof Producf 8ockIog
musf be deveIoped fo meef fhe firsf
reIeose gooI ond dofe. Add Producf
8ockIog os necessory. Then esfimofe
fhe Producf 8ockIog ifems. Con your
feom meef fhe firsf reIeose gooIs ond
dofe7 If nof, whof con be done so
fhof you con moke fhis gooI ond dofe7
Moke specific recommendofions.
Scrum TutoriuI
28
Scrum Meefings
DoiIy Scrum
Sprinf PIonning
Sprinf Peview
Scrum TutoriuI
29
The Product Owner, ScrumMaster, and development team meet prior
to every Sprint to determine what product Iunctionality the team will
work on. The Product Owner presents the product backlog and the
team selects what it believes it can build during the Sprint.
Customers, management, users and other interested parties, also
known as 'stake holders, are also welcome to this presentation.
Regardless, the prioritization oI the product backlog remains the
exclusive responsibility oI the product owner.
The Sprint planning meeting actually consists oI two meetings.
During the Iirst meeting, the product backlog Ior the next Sprint is
selected by the team. During the second meeting, the team identiIies
the Sprint backlog necessary to turn the product backlog into the
increment oI product Iunctionality.
Activity: 7 Sprinf PIonning Meefing
Chickens 7.o Affend fhe Sprinf PIonning
Meefing
Teom 7.b Consfrucf Sprinf 8ockIog
Producf Owner 7.4 Define Sprinf 0ooI
Teom 7.3 SeIecf Producf 8ockIog for
Sprinf
Producf Owner 7.Z Presenf Producf 8ockIog
ScrumMosfer 7.I FociIifofe Sprinf PIonning Meefing
Scrum TutoriuI
30
Sprinf PIonning Meefing
Producf
8ockIog
Teom
CopobiIifies
8usiness
Condifions
TechnoIogy
SfobiIify
ExecufobIe
Producf
Incremenf
Peview,
Consider,
Orgoni;e
Mexf Sprinf
0ooI
Producf
8ockIog
Sprinf 8ockIog
Scrum TutoriuI
31
Sprinf PIonning Meefing
I doy
I
sf
- 4 hours feom seIecfs Producf
8ockIog ond sefs gooI wifh producf
owner
Z
nd
- 4 hours feom defines Sprinf
8ockIog fo buiId funcfionoIify
Anyone con offend, buf primory
conversofion ond work is befween
feom ond Producf Owner
Scrum TutoriuI
32
Connof be odded fo or chonged
during Sprinf
Is fro;en from Producf 8ockIog for
durofion of Sprinf
Sprinf 0ooI is consfrucfed fo
describe objecfive if successfuIIy
furned info working funcfionoIify
Producf 8ockIog SeIecfed for Sprinf
Scrum TutoriuI
33
Each Scrum Team meets daily Ior a 15-minute status meeting
called the Daily Scrum. During the meeting, the team explains
what it has accomplished since the last meeting, what it is going to
do beIore the next meeting, and what obstacles are in its way. The
Daily Scrum meeting gets people used to team-based, rapid,
intense, co-operative, courteous development. Daily Scrums
improve communications, eliminate other meetings, identiIy and
remove impediments to development, highlight and promote quick
decision-making, and improve everyone`s level oI project
knowledge. That`s a lot oI beneIit Irom just 15 minutes a day!
The Daily Scrum is the only Iormal communication between the
team and the people outside the team during a Sprint. II anyone
wants to assess the progress oI the team prior to the end oI Sprint
Review meeting, they can attend the daily Scrum meeting (as a
'chicken) or inspect the Sprint Backlog. Nobody outside oI the
team is allowed to interIere with the team`s time by calling any
other type oI review meeting, such as a 'design review. The
ScrumMaster should view such a meeting as an interIerence and
remove the need Ior any team member to attend.
The Daily Scrum has three purposes:
1. The team members share status with each other.
2. The team members report any impediments or decisions that
they can`t make to the ScrumMaster so that the ScrumMaster can
resolve them.
3. Team members and the ScrumMaster get to assess the team
through observation.
Activity: 10 Daily Scrum
Scrum TutoriuI
34
Chickens I0.4 Affend fhe DoiIy Scrum
Teom,
ScrumMosfer,
Producf Owner
I0.3 Decisions
Teom I0.Z Commif ond Sfofus
ScrumMosfer I0.I Conducf fhe DoiIy Scrum
Scrum TutoriuI
35
DoiIy Ib minufe sfofus meefing,
Some pIoce ond fime every doy,
Meefing room,
Chickens ond pigs,
Three quesfions,
- Whof hove you done since Iosf
meefing7
- Whof wiII you do before nexf
meefing7
- Whof is in your woy7
Impedimenfs, ond
Decisions
DoiIy Scrums
Scrum TutoriuI
36
Chickens und Pigs
A chicken ond o pig ore fogefher
when fhe chicken soys, "Lefs
sforf o resfouronfl"
The pig fhinks if over ond soys,
"Whof wouId we coII fhis
resfouronf7"
The chicken soys, "Hom n Eggsl"
The pig soys, "Mo fhonks. Id be
commiffed, buf youd onIy be
invoIvedl"
Scrum TutoriuI
37
Activity: 11 Sprint Review Meeting
Chickens II.7 Affend fhe Sprinf Peview
ScrumMosfer,
Teom, Producf
Owner
II.o Sprinf Pefrospecfive
ScrumMosfer,
Producf Owner
II.b Projecf Peporfing
Producf 8ockIog II.4 Adjusf fhe Producf 8ockIog
Producf Owner II.3 EvoIuofe fhe FuncfionoIify
Teom II.Z Presenf fhe Producf Incremenf
ScrumMosfer II.I Conducf Sprinf Peview Meefing
Scrum TutoriuI
38
End-of-Sprinf Peview
Scrum TutoriuI
39
Sprinf Peview Meefing
4 hours,
Moximum I hour preporofion,
Done on equipmenf where soffwore
wos deveIoped ond fesfed,
Presenfed by feom fo Producf Owner
ond cusfomers/users,
8osis for pIonning nexf Sprinf, ond,
Musf represenf pofenfioIIy shippobIe
incremenf of producf funcfionoIify.
Scrum TutoriuI
40
VoIue Driven PeIeoses
business voIue ~ f(cosf, fime,
funcfionoIify, quoIify)
807 of fhe business voIue con be
derived from Z07 of fhe funcfionoIify.
A successfuI projecf meefs business
objecfives ond deIivers voIue, nof
funcfionoIify.
Monoging o PeIeose
Scrum TutoriuI
41
I. PeIeose depends on progress of
burning down bockIog
Z. 8urning down bockIog dependenf
on
Pequired funcfionoIify ond
quoIify
Producfivify of feom(s)
JIkdla;IjkdlajI;ds
Ijdkla
Idjklad;
Idjkla;s
Ijdk
Ijkdla;Ijkdal;I
jIkdlsj;a
Ijdkla;
Ijdklas;
Idjkld
Idkjla;
Idjklsa;
IjkIjdkjdkIjkdla;
Ijkdl
Ijkdl;aj
Idjklas;
Ijdklas;kd
Ijkdlas;
Idjkl;a
Ijdklas;
IdjkalIjdask;
jIkdla;
Ijdkla;
Idkjal;
Idjkal;
Idjksla;;daId
Idjkla;
Ijdkla;;asl
Idjksal;
Ijdkl
IdjskIal;Ijkdasl;jI
Ijdklas;I
Ijdkals;
Ijdksal;
IdjsaklIjdslkjIdl
Ijdkla;
Idjkals;dIdjkl
Ijdkla;jId
IdjkaIl;adjI
IdjksIl
Idjkdla;sIdjaskI
IdjkaslI;dI
Idjkasl;j
Ijdksla;I;dsal
Ijdksal;I
Idjsakl;Id
Idjkal;IdIddjIkdl
jIkdal;Ijkdasl;Id
This Sprint : well defined work that can
be done is <30 days & produce executable
Probable next sprint : backlog next in
priority, depends on results from prior
Sprint
During a Sprint, that Sprint's
backlog is fixed and can only be
changed as a result of the work
being performed in that Sprint.
Backlog outside the current
Sprint is always changing,
evolving, and being reprioritized.
Planned
Release
Monoging o PeIeose
Scrum TutoriuI
42
Projecf sIope of work remoining fo
defermine probobIe reIeose dofe
8y ninfh monfh, nof enough
producfivify fo hif desired reIeose
dofe in Z0fh monfh
Cusfomer reduced expecfed
funcfionoIify in reIeose which roised
fhe Iine for reIeose dofe.
ReIease with reduced functionaIity
0
1000
2000
3000
4000
5000
6000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Series1
Monoging o PeIeose
Scrum TutoriuI
43
Exercise Z
t is the end of the third Sprint, February 28. At the end of the Sprint review meeting on
February 28, and the team has conducted the Sprint review with George
Steinbrenner, who is representing the Commissioner, and Mo Vaughan. The team
is well on its way to bringing up all of the desired functionality for the first release
at the end of March, but raises the following concerns:
1. During the Sprint, the team contacted several ecommerce retailers and determined
that there were on average 100 visits for every sale.
2. The team is unable to estimate the exact number of hits that will occur the when the
website first comes up. However, there are 40million avid baseball fans in the
world. A major marketing campaign for MLBTix has been conducted after the
commissioner's press conference in Mid-January, and the impact of the site has
been the rage of all the sports pages and sports magazines.
3. Based on the MLB commissioner's research, the site is expected to sell 2000
tickets per day in April, 3000 per day in April and 5000 per day thereafter for the
rest of the season. The average price that will be charge by a seller above retail is
$30, of which 25% will go to the MLBTix.
4. As you had previously alerted the Commissioner, SQL Server scaling is an iffy
proposition. Scaling tests to date have proven that the application is data base
intensive. Even with all tuning efforts from consultants that have been brought in
and running SQL Server on the fastest RAD devices possible, the maximum
simultaneous transaction that can be served with sub-three second response time
is 100 per second. Given that peak loads are expected at lunch time and after
dinner, the team is concerned that peak volumes during normal production may
overwhelm the server and that the knee of the performance curve is very close to
the 110 per second rate.
5. You have determined that Oracle will readily support the scaling requirements
predicted by the Commissioner, but it will take one more Sprint to trade out SQL
Server and implement Oracle. The application can't come up until a month after
the season opener.
What should you advise the commissioner based on the above risk/reward model and
your best gut feel? Please quantify.
Scrum TutoriuI
44
ScoIing
I. Jusf doesn'f "scoIe"
Z. Mof oppropriofe for mission
crificoI ond Iife crificoI sysfems
becouse of fheir rigor, precision
ond quoIify requiremenfs.
3. InoppIicobIe fo Iorger projecfs.
4. Mof sufficienf when fhe risk is
high ond fhe degree of confroI
needed is high.
b. Doesn'f oddress fixed-price,
fixed-dofe projecfs.
o. Mof rigorous enough fo meef fhe
requiremenfs of o mofure process,
such os defined by fhe Soffwore
Engineering Insfifufe's CopobiIify
Mofurify ModeI.
Scrum TutoriuI
45
How AgiIe MefhodoIogies ScoIe
Scrum TutoriuI
46
Initial Product
Backlog
- Functional requirement
- Non-Iunctional
requirements
- Staged, scalability
requirements
- the rest oI the Iunctional
and non-Iunctional
requirements
Product Backlog
- Functional requirements
- Non-Iunctional
requirements
Single Team
Many Teams
How AgiIe MefhodoIogies ScoIe
Scrum TutoriuI
47
Lorge Projecf, MuIfipIe Teoms
I. For smoIIer projecfs fhe vision
sfofemenf coupIed wifh emergence ond
refocforing is odequofe.
Z. Some orchifecfure ond design needed
when muIfipIe feoms ore used..
9:00AM
9:15AM
9:15AM
9:30AM
9:30AM
9:45AM
9:45AM
10:00AM
Daily Scrums
per Sprint
Sprint 1
Sprint 2
Sprint 3
Coordinofing
Scrum of Scrums
Scrum TutoriuI
48
Whof Comprises o PofenfioIIy
ShippobIe Producf Incremenf
efc. efc.
Tesfed, debugged execufobIe,
froining moferioIs, documenfofion,
requiremenfs froceobiIify,
performonce modeIs
Mission
CrificoI
Soffwore
Tesfed, debugged execufobIe,
froining moferioIs, documenfofion,
requiremenfs froceobiIify, FDA
required documenfofion
FDA
Approved
Soffwore
Tesfed, debugged execufobIe, heIp,
froining moferioIs, documenfofion
CommercioI
Soffwore
Tesfed, debugged execufobIe ond
documenfofion
SingIe Use
Soffwore
Scrum TutoriuI
49
Moximi;ed ConfroI Through
Inspecfion ond Adopfofion
Scrum TutoriuI
50
DeveIop vision, voIue sfofemenf wifh
prospecf.
Creofe producf bockIog of funcfionoI
ond non-funcfionoI requiremenfs.
Priorifi;e producf bockIog ond review
wifh cusfomer in Iighf of vision ond
voIue sfofemenfs.
Creofe enough orchifecfure ond design
fo deveIop producf bockIog esfimofes,
more occurocy on funcfionoIify fhof
moximi;es voIue.
Discuss wifh cusfomer how voIue wiII
be deIivered incremenfoIIy ond fhof
fhey ore free fo chonge producf
bockIog confenf ond priorify , os Iong
os esfimofes sfoy fhe some.
Submif bid bosed on producf bockIog.
Fixed Price, Fixed Dofe
Scrum TutoriuI
51
Confrocf provisions:
I. Any requiremenf fhof hosn'f oIreody been
worked on con be swopped ouf for
onofher of equoI voIue,
Z. Priorify of requiremenfs con be chonged,
3. Cusfomer moy requesf oddifionoI
reIeoses of ony fime of prevoiIing fime
ond moferioI fees,
4. Cusfomer moy ferminofe confrocf eorIy
if voIue hos been sofisfied for Z07 of
remoining unbiIIed confrocf voIue
Fixed Price, Fixed Dofe
Or
Lofesf Dofe, Moximum Cosf
Scrum TutoriuI
52
Scrum CompIionce wifh CMM
Soffwore Fromework
LeveI key Pructice Areu
Ruting
Z Pequiremenfs monogemenf
Z Soffwore projecf pIonning
Z Soffwore projecf frocking
ond oversighf

Z Soffwore subconfrocf
monogemenf

Z Soffwore quoIify ossuronce
Z Soffwore configurofion
monogemenf

3 Orgoni;ofion process focus
3 Orgoni;ofion process
definifion

3 Troining progrom
3 Infegrofed soffwore
monogemenf
3 Soffwore producf
engineering

3 Infergroup coordinofion
3 Peer review
Scrum TutoriuI
53
Scrum ond XP Comporison
Engineering process fhof hos
borrowed some wropping
monogemenf procfices, buf is
of odds wifh mony
orgoni;ofionoI procfices
Monogemenf process fhof
wrops ony exisfing business
processes ond mefhodoIogies
ImpIemenfs in o-8 monfhs,
depending on exisfing
engineering procfices
ImpIemenfs in Z doys, fhen
groduoIIy improves everyfhing
Cusfomer inferreIofes of
specificofion IeveI
Cusfomer inferreIofes of POI
IeveI
Efforf is mode fo increose
precision of esfimofes
Esfimofes groduoIIy gef beffer
os o moffer of course
I-Z week iferofion required fo
creofe soffwore incremenf (no
onoIysis, jusf design)
30 doy iferofion required fo
compIefe incremenf (sforfs
wifh onoIysis)
Sfories of Specificofions -
more gronuIor
Producf 8ockIog of
requiremenfs - Iess gronuIor
XP Scrum
Scrum TutoriuI
54
Questions?
www.controlchaos.com/certifiiedscrum

SCRUM Tutorial Common Sense

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SCRUM Tutorial Common Sense

Hochgeladen von

Copyright:

Verfügbare Formate

Scrum TutoriuI

Advanced Development Methods 2003 All Rights Reserved

Das könnte Ihnen auch gefallen