Scrum -Abhijit Mahajan -Neelam Agrawal an agile - - PowerPoint PPT Presentation

ì ¡

Scrum ¡

an ¡agile ¡development ¡process ¡methodology ¡

• ­‑Abhijit ¡Mahajan ¡ ¡
• ­‑Neelam ¡Agrawal ¡

¡

Introduction ¡

ì Scrum ¡is ¡an ¡agile ¡so<ware ¡development ¡methodology ¡ ì It ¡is ¡an ¡itera>ve ¡and ¡incremental ¡methodology ¡ ¡

ì

for ¡so<ware ¡projects ¡and ¡product-­‑ ¡or ¡applica>on-­‑ development ¡ ì Projects ¡progress ¡via ¡a ¡series ¡of ¡itera>ons ¡ ¡

ì

called ¡sprints ¡ ¡

ì which ¡are ¡usually ¡2-­‑4 ¡weeks ¡long ¡

ì A ¡typical ¡scrum ¡team ¡has ¡between ¡five ¡and ¡nine ¡people ¡ ¡

ì

but ¡Scrum ¡projects ¡can ¡easily ¡scale ¡into ¡the ¡hundreds ¡

History ¡

History ¡

ì

1993-­‑Jeff ¡Sutherland, ¡John ¡Scumniotales ¡and ¡Jeff ¡McKenna, ¡ came ¡up ¡with ¡an ¡approach ¡at ¡Easel ¡Corpora>on ¡

ì

first ¡to ¡refer ¡it ¡using ¡the ¡single ¡word ¡Scrum. ¡

ì

In ¡1996, ¡Sutherland ¡and ¡Schwaber ¡jointly ¡presented ¡a ¡paper ¡ describing ¡the ¡Scrum ¡method ¡at ¡the ¡Business ¡Object ¡Design ¡ and ¡Implementa>on ¡Workshop ¡ ¡

ì

held ¡as ¡part ¡of ¡OOPSLA ¡’95 ¡in ¡Aus>n, ¡Texas. ¡

ì

1998-­‑ ¡Ken, ¡Jeff, ¡et ¡al ¡came ¡up ¡with ¡“Scrum ¡a ¡pa[ern ¡language ¡ for ¡hyperproduc>ve ¡so<ware ¡development” ¡

ì

In ¡2001, ¡Schwaber ¡worked ¡with ¡Mike ¡Beedle ¡to ¡describe ¡the ¡ method ¡in ¡the ¡book ¡Agile ¡with ¡Scrum ¡

SCRUM ¡Methodology ¡

Scrum ¡& ¡Rugby ¡

ì The ¡SCRUM ¡methodology ¡shares ¡many ¡characteris>cs ¡

with ¡the ¡sport ¡of ¡Rugby ¡: ¡

ì

The ¡context ¡is ¡set ¡by ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡playing ¡field ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡(environment) ¡and ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡rugby ¡rules ¡(controls). ¡

ì

The ¡primary ¡cycle ¡is ¡moving ¡the ¡ball ¡forward. ¡

ì

Rugby ¡evolved ¡from ¡breaking ¡soccer ¡rules ¡-­‑ ¡adap>ng ¡to ¡ the ¡environment. ¡

ì

The ¡game ¡does ¡not ¡end ¡un>l ¡environment ¡dictates ¡ (business ¡need, ¡compe>>on, ¡func>onality, ¡>metable). ¡

Scrum ¡phase ¡list ¡

ì Pregame ¡

ì

Planning ¡

ì

System ¡Architecture/High ¡Level ¡Design ¡ ì Game ¡

ì

Sprints ¡(Concurrent ¡Engineering) ¡

ì

Develop ¡(Analysis,Design,Develop) ¡

ì

Wrap ¡

ì

Review ¡

ì

Adjust ¡ ì Postgame ¡

ì

Closure ¡

SCRUM ¡Phases ¡(1) ¡

ì Pregame ¡

ì

Planning ¡: ¡ ¡

ì Defini>on ¡of ¡a ¡new ¡release ¡based ¡on ¡currently ¡known ¡

backlog, ¡along ¡with ¡an ¡es>mate ¡of ¡its ¡schedule ¡and ¡cost. ¡ ¡

ì If ¡a ¡new ¡system ¡is ¡being ¡developed, ¡this ¡phase ¡consists ¡of ¡

both ¡conceptualiza>on ¡and ¡analysis. ¡ ¡

ì If ¡an ¡exis>ng ¡system ¡is ¡being ¡enhanced, ¡this ¡phase ¡

consists ¡of ¡limited ¡analysis. ¡

ì

Architecture ¡: ¡ ¡

ì Design ¡how ¡the ¡backlog ¡items ¡will ¡be ¡implemented. ¡ ¡ ì This ¡phase ¡includes ¡system ¡architecture ¡modifica>on ¡and ¡

high ¡level ¡design. ¡

SCRUM ¡Phases ¡(2) ¡

ì Game ¡

ì

Development ¡Sprints ¡: ¡ ¡

ì Development ¡of ¡new ¡release ¡func>onality, ¡with ¡constant ¡

respect ¡to ¡the ¡variables ¡of ¡>me, ¡requirements, ¡quality, ¡ cost, ¡and ¡compe>>on. ¡

ì Interac>on ¡with ¡these ¡variables ¡defines ¡the ¡end ¡of ¡this ¡

• phase. ¡ ¡

ì There ¡are ¡mul>ple, ¡itera>ve ¡development ¡sprints, ¡or ¡

cycles, ¡that ¡are ¡used ¡to ¡evolve ¡the ¡system. ¡

ì Postgame ¡

ì

Closure ¡: ¡ ¡

ì Prepara>on ¡for ¡release, ¡including ¡final ¡documenta>on, ¡

pre-­‑release ¡staged ¡tes>ng, ¡and ¡release. ¡

Planning ¡(1) ¡

ì Development ¡of ¡a ¡comprehensive ¡backlog ¡list. ¡ ì Defini>on ¡of ¡the ¡delivery ¡date ¡and ¡func>onality ¡of ¡one ¡

• r ¡more ¡releases. ¡

ì Selec>on ¡of ¡the ¡release ¡most ¡appropriate ¡for ¡immediate ¡

• development. ¡

ì Mapping ¡of ¡product ¡packets ¡(objects) ¡for ¡backlog ¡items ¡

in ¡the ¡selected ¡release. ¡

ì Defini>on ¡of ¡project ¡team(s) ¡for ¡the ¡building ¡of ¡the ¡new ¡

• release. ¡

Planning ¡(2) ¡

ì Assessment ¡of ¡risk ¡and ¡appropriate ¡risk ¡controls. ¡ ì Review ¡and ¡possible ¡adjustment ¡of ¡backlog ¡items ¡

and ¡packets. ¡

ì Valida>on ¡or ¡reselec>on ¡of ¡development ¡tools ¡and ¡

• infrastructure. ¡

ì Es>ma>on ¡of ¡release ¡cost, ¡including ¡development, ¡

collateral ¡material, ¡marke>ng, ¡training, ¡and ¡rollout. ¡

ì Verifica>on ¡of ¡management ¡approval ¡and ¡funding. ¡

Architecture/High ¡Level ¡Design ¡(1) ¡

ì Review ¡assigned ¡backlog ¡items. ¡ ì Iden>fy ¡changes ¡necessary ¡to ¡implement ¡backlog ¡

• items. ¡

ì Perform ¡domain ¡analysis ¡to ¡the ¡extent ¡required ¡to ¡

build, ¡enhance, ¡or ¡update ¡the ¡domain ¡models ¡to ¡ reflect ¡the ¡new ¡system ¡context ¡and ¡requirements. ¡

ì Refine ¡the ¡system ¡architecture ¡to ¡support ¡the ¡new ¡

context ¡and ¡requirements. ¡

Architecture/High ¡Level ¡Design ¡(2) ¡

ì Iden>fy ¡any ¡problems ¡or ¡issues ¡in ¡developing ¡or ¡

implemen>ng ¡the ¡changes ¡

ì Design ¡review ¡mee>ng, ¡each ¡team ¡presen>ng ¡

approach ¡and ¡changes ¡to ¡implement ¡each ¡backlog ¡

• item. ¡ ¡

ì Reassign ¡changes ¡as ¡required. ¡

Sprint ¡(1) ¡

ì A ¡sprint ¡is ¡the ¡basic ¡unit ¡in ¡Scrum ¡

ì

lasts ¡between ¡one ¡week ¡and ¡one ¡month ¡ ì Each ¡sprint ¡is ¡preceded ¡by ¡a ¡mee>ng ¡

ì

where ¡the ¡tasks ¡for ¡the ¡sprint ¡are ¡ini>ated ¡for ¡the ¡sprint ¡ goal ¡ ì The ¡work ¡items ¡come ¡from ¡the ¡product ¡backlog ¡

ì

which ¡is ¡a ¡priori>zed ¡list ¡of ¡requirements ¡ ì During ¡the ¡sprint ¡planning ¡mee>ng, ¡the ¡Product ¡Owner ¡

informs ¡the ¡group ¡of ¡the ¡items ¡in ¡the ¡product ¡backlog ¡ that ¡needs ¡to ¡be ¡completed ¡ ¡

ì

the ¡ones ¡with ¡the ¡highest ¡priority ¡ ¡

Sprint ¡(2) ¡

ì The ¡group ¡then ¡determines ¡how ¡much ¡of ¡this ¡they ¡

can ¡commit ¡to ¡complete ¡during ¡the ¡next ¡sprint ¡

ì ¡and ¡records ¡this ¡in ¡the ¡sprint ¡backlog ¡

ì During ¡a ¡sprint, ¡no ¡one ¡is ¡allowed ¡to ¡change ¡the ¡

sprint ¡backlog ¡

ì ¡which ¡means ¡that ¡the ¡requirements ¡are ¡frozen ¡for ¡

that ¡sprint ¡

ì ¡if ¡requirements ¡are ¡not ¡completed ¡for ¡any ¡reason ¡

they ¡are ¡le< ¡out ¡and ¡returned ¡to ¡the ¡product ¡ backlog ¡

More ¡Game ¡phase(1) ¡

ì Develop: ¡ ¡

ì Defining ¡changes ¡needed ¡for ¡ ¡

ì the ¡implementa>on ¡of ¡backlog ¡requirements ¡into ¡packets, ¡

• pening ¡the ¡packets, ¡performing ¡domain ¡analysis ¡

ì designing, ¡developing, ¡implemen>ng, ¡tes>ng, ¡and ¡

documen>ng ¡the ¡changes. ¡ ¡ ì Development ¡consists ¡of ¡the ¡micro ¡process ¡of ¡discovery, ¡

inven>on, ¡and ¡implementa>on. ¡ ì Wrap: ¡ ¡

ì Closing ¡the ¡packets, ¡crea>ng ¡an ¡executable ¡version ¡of ¡

changes ¡and ¡how ¡they ¡implement ¡backlog ¡

• requirements. ¡

More ¡Game ¡phase ¡(2) ¡

ì Review: ¡ ¡

ì All ¡teams ¡mee>ng ¡to ¡present ¡ ¡

ì work ¡and ¡review ¡progress ¡ ì raising ¡and ¡resolving ¡issues ¡and ¡problems ¡ ¡ ì adding ¡new ¡backlog ¡items ¡ ¡

ì Risk ¡is ¡reviewed ¡and ¡appropriate ¡responses ¡defined. ¡

ì Adjust: ¡

ì Consolida>ng ¡the ¡informa>on ¡gathered ¡from ¡the ¡review ¡

mee>ng ¡into ¡affected ¡packets, ¡including ¡different ¡look ¡ and ¡feel ¡and ¡new ¡proper>es. ¡

Closure ¡

ì When ¡the ¡management ¡team ¡feels ¡that ¡the ¡

variables ¡of ¡>me, ¡compe>>on, ¡requirements, ¡cost, ¡ and ¡quality ¡concur ¡for ¡a ¡new ¡release ¡to ¡occur, ¡they ¡ declare ¡the ¡release ¡“closed” ¡and ¡enter ¡this ¡phase. ¡ ¡

ì This ¡phase ¡prepares ¡the ¡developed ¡product ¡for ¡

general ¡release. ¡

ì Integra>on, ¡system ¡test, ¡user ¡documenta>on, ¡

training ¡material ¡prepara>on, ¡and ¡marke>ng ¡ material ¡prepara>on ¡are ¡among ¡closure ¡tasks. ¡

Roles ¡

The ¡various ¡roles ¡in ¡Scrum ¡team ¡

ì Core ¡Roles ¡

ì Product ¡Owner ¡ ì Development ¡Team ¡ ì Scrum ¡Master ¡

ì Ancillary ¡roles ¡

ì Stakeholders ¡(customers, ¡vendors) ¡ ì Managers ¡

Product ¡Owner ¡

ì The ¡Product ¡Owner ¡represents ¡the ¡voice ¡of ¡the ¡

customer ¡ ¡

ì is ¡accountable ¡for ¡ensuring ¡that ¡the ¡Group ¡delivers ¡

value ¡to ¡the ¡business ¡ ì Writes ¡customer-­‑centric ¡items ¡(user ¡stories), ¡ ¡

ì priori>zes ¡them ¡ ¡ ì and ¡adds ¡them ¡to ¡the ¡product ¡backlog ¡

ì Scrum ¡groups ¡should ¡have ¡one ¡Product ¡Owner ¡

ì She ¡may ¡also ¡be ¡a ¡member ¡of ¡the ¡Management ¡Group ¡ ì ¡It ¡is ¡recommended ¡that ¡this ¡role ¡not ¡be ¡combined ¡

with ¡ScrumMaster ¡

Development ¡Team ¡

ì Responsible ¡for ¡delivering ¡poten>ally ¡shippable ¡

product ¡increments ¡at ¡the ¡end ¡of ¡each ¡Sprint. ¡

ì It ¡is ¡made ¡up ¡of ¡people ¡with ¡cross-­‑func>onal ¡skills ¡ ¡

ì who ¡do ¡the ¡actual ¡work ¡ ¡

ì analyze, ¡design, ¡develop, ¡test, ¡technical ¡communica>on, ¡

document, ¡etc ¡ ¡

ì It ¡is ¡self-­‑organizing ¡

ì ¡even ¡though ¡they ¡may ¡interface ¡with ¡project ¡

management ¡organiza>ons ¡(PMOs). ¡

Scrum ¡Master ¡

ì Scrum ¡Master ¡is ¡accountable ¡for ¡removing ¡

impediments ¡to ¡the ¡ability ¡of ¡the ¡group ¡to ¡deliver ¡ the ¡sprint ¡goal/deliverables. ¡ ¡

ì She ¡acts ¡as ¡a ¡buffer ¡between ¡the ¡group ¡and ¡any ¡

distrac>ng ¡influences. ¡ ¡

ì The ¡Scrum ¡Master ¡is ¡the ¡enforcer ¡of ¡rules. ¡ ¡ ì A ¡key ¡part ¡of ¡the ¡role ¡is ¡to ¡protect ¡the ¡Development ¡

Team ¡and ¡keep ¡it ¡focused ¡on ¡the ¡tasks ¡at ¡hand. ¡

Ancillary ¡Roles ¡

ì

The ¡ancillary ¡roles ¡in ¡Scrum ¡groups ¡are ¡those ¡with ¡no ¡formal ¡ role ¡and ¡infrequent ¡involvement ¡in ¡the ¡Scrum ¡process ¡

ì

but ¡nonetheless, ¡must ¡be ¡taken ¡into ¡account. ¡

ì

Stakeholders ¡(customers, ¡vendors): ¡ ¡

ì

People ¡who ¡enable ¡the ¡project ¡and ¡for ¡whom ¡the ¡project ¡ produces ¡the ¡agreed-­‑upon ¡benefit[s] ¡ ¡

ì that ¡jus>fy ¡its ¡produc>on ¡

ì

¡They ¡are ¡only ¡directly ¡involved ¡in ¡the ¡process ¡during ¡the ¡ sprint ¡reviews ¡

ì

Managers: ¡ ¡

ì

People ¡who ¡control ¡the ¡environment ¡

Meetings ¡Overview ¡

Meetings ¡

The ¡following ¡is ¡a ¡list ¡of ¡meeCngs ¡in ¡Scrum ¡development ¡

ì Daily ¡Scrum ¡ ì Backlog ¡grooming: ¡storyCme ¡ ì Scrum ¡of ¡Scrums ¡ ì Sprint ¡planning ¡meeCng ¡ ì Sprint ¡review ¡meeCng ¡ ì Sprint ¡retrospecCve ¡

Daily ¡Scrum ¡(1) ¡

ì Happens ¡each ¡day ¡during ¡the ¡sprint ¡

ì ¡is ¡a ¡project ¡status ¡mee>ng ¡ ¡

ì This ¡mee>ng ¡has ¡specific ¡guidelines: ¡

ì The ¡mee>ng ¡starts ¡precisely ¡on ¡>me ¡ ì All ¡are ¡welcome, ¡but ¡normally ¡only ¡the ¡core ¡roles ¡

speak ¡

ì The ¡mee>ng ¡length ¡is ¡set ¡to ¡15 ¡mins ¡ ì The ¡mee>ng ¡should ¡happen ¡at ¡the ¡same ¡loca>on ¡

and ¡same ¡>me ¡every ¡day ¡

Daily ¡Scrum ¡(2) ¡

ì During ¡the ¡mee>ng, ¡each ¡group ¡member ¡answers ¡

three ¡ques>ons ¡

ì What ¡have ¡you ¡done ¡since ¡yesterday? ¡ ì What ¡are ¡you ¡planning ¡to ¡do ¡today? ¡ ì Any ¡impediments/stumbling ¡blocks? ¡

ì Scrum ¡Master ¡should ¡facilitate ¡resolu>on ¡of ¡these ¡

impediments, ¡although ¡the ¡resolu>on ¡should ¡occur ¡

• utside ¡the ¡Daily ¡Scrum ¡itself ¡to ¡keep ¡it ¡under ¡15 ¡
• minutes. ¡

Backlog ¡grooming: ¡storytime ¡

ì This ¡is ¡the ¡process ¡of ¡

ì es>ma>ng ¡the ¡exis>ng ¡backlog ¡using ¡effort/points ¡ ì refining ¡the ¡acceptance ¡criteria ¡for ¡individual ¡stories ¡ ì ¡and ¡breaking ¡larger ¡stories ¡into ¡smaller ¡stories ¡

ì Mee>ngs ¡should ¡not ¡be ¡longer ¡than ¡an ¡hour ¡ ì Mee>ng ¡does ¡not ¡include ¡breaking ¡stories ¡into ¡

tasks ¡

ì Group ¡can ¡decide ¡how ¡many ¡mee>ngs ¡are ¡needed ¡

per ¡week. ¡

Scrum ¡of ¡scrums ¡

ì

Each ¡day ¡normally ¡a<er ¡the ¡Daily ¡Scrum. ¡

ì

These ¡mee>ngs ¡allow ¡clusters ¡of ¡groups ¡to ¡discuss ¡their ¡work, ¡ focusing ¡especially ¡on ¡areas ¡of ¡overlap ¡and ¡integra>on. ¡

ì

A ¡designated ¡person ¡from ¡each ¡group ¡a[ends. ¡

ì

The ¡agenda ¡will ¡be ¡the ¡same ¡as ¡the ¡Daily ¡Scrum, ¡plus ¡the ¡ following ¡four ¡ques>ons: ¡

ì

What ¡has ¡your ¡group ¡done ¡since ¡we ¡last ¡met? ¡

ì

What ¡will ¡your ¡group ¡do ¡before ¡we ¡meet ¡again? ¡

ì

Is ¡anything ¡slowing ¡your ¡group ¡down ¡or ¡gemng ¡in ¡their ¡way? ¡

ì

Are ¡you ¡about ¡to ¡put ¡something ¡in ¡another ¡group’s ¡way? ¡

Sprint ¡planning ¡meeting(1) ¡

ì

Takes ¡place ¡at ¡the ¡beginning ¡of ¡the ¡sprint ¡cycle ¡

ì

The ¡Sprint ¡Planning ¡Mee>ng ¡is ¡a[ended ¡by ¡ ¡

ì

the ¡product ¡owner ¡

ì

Scrum ¡Master ¡

ì

the ¡en>re ¡Scrum ¡Team. ¡ ¡ ì

There ¡are ¡two ¡defined ¡ar>facts ¡resul>ng ¡from ¡this ¡mee>ng: ¡

ì

A ¡sprint ¡goal ¡ ¡

ì

A ¡sprint ¡backlog ¡ ì

A ¡sprint ¡goal ¡is ¡a ¡short, ¡one-­‑ ¡or ¡two-­‑sentence, ¡descrip>on ¡of ¡what ¡ the ¡team ¡plans ¡to ¡achieve ¡during ¡the ¡sprint. ¡ ¡

ì

It ¡is ¡wri[en ¡collabora>vely ¡by ¡the ¡team ¡and ¡the ¡product ¡owner ¡

Sprint ¡planning ¡meeting(2) ¡

ì

The ¡team ¡asks ¡enough ¡ques>ons ¡so ¡that ¡they ¡can ¡turn ¡a ¡high-­‑ level ¡user ¡story ¡of ¡the ¡product ¡backlog ¡into ¡the ¡more ¡detailed ¡ tasks ¡of ¡the ¡sprint ¡backlog. ¡

ì

Sprint ¡Backlog ¡is ¡prepared ¡with ¡details ¡of ¡the ¡>me ¡it ¡will ¡take ¡ to ¡do ¡a ¡par>cular ¡work ¡

ì

Iden>fy ¡and ¡communicate ¡how ¡much ¡of ¡the ¡work ¡is ¡likely ¡to ¡ be ¡done ¡during ¡the ¡current ¡sprint ¡

ì

Eight ¡hour ¡>me ¡limit ¡

ì

(1st ¡four ¡hours) ¡Product ¡Owner ¡+ ¡Group: ¡dialog ¡for ¡ priori>zing ¡the ¡Product ¡Backlog ¡

ì

(2nd ¡four ¡hours) ¡Group ¡only: ¡hashing ¡out ¡a ¡plan ¡for ¡the ¡ Sprint, ¡resul>ng ¡in ¡the ¡Sprint ¡Backlog ¡

Sprint ¡review ¡meeting(1) ¡

ì Held ¡at ¡the ¡end ¡of ¡each ¡sprint ¡during ¡which ¡the ¡Scrum ¡

team ¡shows ¡what ¡they ¡accomplished ¡during ¡the ¡sprint. ¡ ¡

ì Typically ¡this ¡takes ¡the ¡form ¡of ¡a ¡demo ¡of ¡the ¡new ¡

• features. ¡

ì It ¡is ¡inten>onally ¡kept ¡very ¡informal, ¡typically ¡with ¡rules ¡

forbidding ¡the ¡use ¡of ¡PowerPoint ¡slides. ¡

ì A ¡sprint ¡review ¡mee>ng ¡should ¡not ¡become ¡a ¡distrac>on ¡

• r ¡significant ¡detour ¡for ¡the ¡team ¡

ì

rather, ¡it ¡should ¡be ¡a ¡natural ¡result ¡of ¡the ¡sprint ¡

Sprint ¡review ¡meeting(2) ¡

ì Par>cipants ¡in ¡the ¡sprint ¡review ¡typically ¡include ¡ ¡

ì the ¡Product ¡Owner ¡ ì the ¡Scrum ¡team ¡ ¡ ì the ¡ScrumMaster ¡ ì management, ¡customers, ¡and ¡developers. ¡

ì The ¡project ¡is ¡assessed ¡against ¡the ¡sprint ¡goal ¡

determined ¡during ¡the ¡Sprint ¡planning ¡mee>ng. ¡ ¡

ì It ¡is ¡important ¡that ¡the ¡team ¡has ¡achieved ¡the ¡

• verall ¡goal ¡of ¡the ¡sprint. ¡

Sprint ¡Review ¡Meeting ¡(3) ¡

Sprint ¡retrospective ¡

ì

The ¡sprint ¡retrospec>ve ¡is ¡usually ¡the ¡last ¡thing ¡done ¡in ¡a ¡

• sprint. ¡ ¡

ì

Many ¡teams ¡do ¡it ¡immediately ¡a<er ¡the ¡sprint ¡review. ¡

ì

This ¡is ¡a ¡period ¡at ¡the ¡end ¡of ¡each ¡sprint ¡to ¡deliberately ¡reflect ¡

• n ¡how ¡the ¡team ¡is ¡doing ¡and ¡to ¡find ¡ways ¡to ¡improve. ¡ ¡

ì

The ¡en>re ¡team, ¡including ¡both ¡the ¡ScrumMaster ¡and ¡ the ¡product ¡owner ¡par>cipate ¡in ¡this ¡mee>ng. ¡

ì

It ¡has ¡three ¡hour ¡>me ¡limit ¡

ì

Two ¡main ¡ques>ons ¡asked ¡in ¡the ¡sprint ¡retrospec>ve ¡are: ¡ ¡

ì

What ¡went ¡well ¡during ¡the ¡sprint? ¡ ¡

ì

What ¡could ¡be ¡improved ¡in ¡the ¡next ¡sprint? ¡

Artifacts ¡

ì Product ¡Backlog ¡ ì Sprint ¡Backlog ¡ ì Burndown ¡Charts ¡

Product ¡Backlog(1) ¡

ì It ¡is ¡an ¡ordered ¡list ¡of ¡"requirements” ¡maintained ¡

for ¡a ¡product. ¡

ì These ¡items ¡are ¡ordered ¡by ¡the ¡Product ¡Owner ¡

based ¡on ¡considera>ons ¡like ¡risk, ¡business ¡value, ¡ dependencies, ¡date ¡needed, ¡etc. ¡ ¡

ì The ¡values ¡in ¡product ¡backlog ¡are ¡o<en ¡stated ¡in ¡

story ¡points ¡using ¡a ¡rounded ¡Fibonacci ¡sequence. ¡ ¡

Product ¡Backlog(2) ¡

ì Those ¡es>mates ¡help ¡the ¡Product ¡Owner ¡to ¡gauge ¡

the ¡>meline ¡and ¡may ¡influence ¡ordering ¡of ¡backlog ¡

• items. ¡

ì The ¡Product ¡Backlog, ¡and ¡business ¡value ¡of ¡each ¡

listed ¡item ¡is ¡the ¡responsibility ¡of ¡the ¡Product ¡

• Owner. ¡ ¡

ì The ¡es>mated ¡effort ¡to ¡complete ¡each ¡backlog ¡item ¡

is ¡determined ¡by ¡the ¡Development ¡Team. ¡

Product ¡Backlog ¡

Sprint ¡Backlog(1) ¡

ì It ¡is ¡the ¡list ¡of ¡work ¡the ¡Development ¡Team ¡must ¡

address ¡during ¡the ¡next ¡sprint. ¡ ¡

ì The ¡list ¡is ¡derived ¡by ¡selec>ng ¡stories/features ¡from ¡

the ¡top ¡of ¡the ¡product ¡backlog. ¡ ¡

ì The ¡Development ¡Team ¡should ¡keep ¡in ¡mind ¡the ¡

velocity ¡of ¡its ¡previous ¡Sprints ¡when ¡selec>ng ¡ stories/features ¡for ¡the ¡new ¡sprint. ¡

Sprint ¡Backlog(2) ¡

ì The ¡stories/features ¡are ¡broken ¡down ¡into ¡tasks ¡by ¡the ¡

Development ¡Team ¡

ì

should ¡normally ¡be ¡between ¡four ¡and ¡sixteen ¡hours ¡of ¡ work ¡ ì Tasks ¡on ¡the ¡sprint ¡backlog ¡are ¡never ¡assigned; ¡ ¡

ì

rather, ¡tasks ¡are ¡signed ¡up ¡for ¡by ¡the ¡group ¡members ¡as ¡ needed ¡during ¡the ¡daily ¡scrum. ¡ ì O<en ¡an ¡accompanying ¡task ¡board ¡is ¡used ¡to ¡see ¡and ¡

change ¡the ¡state ¡of ¡the ¡tasks ¡of ¡the ¡current ¡sprint, ¡ ¡

ì

like ¡“not ¡checked ¡out”, ¡“checked ¡out” ¡and ¡“done”. ¡

Sprint ¡Backlog ¡

Burndown ¡Charts ¡

ì Sprint ¡burndown ¡chart ¡

ì

It ¡is ¡a ¡publicly ¡displayed ¡chart ¡(updated ¡daily)showing ¡ remaining ¡work ¡in ¡the ¡sprint ¡backlog. ¡ ¡

ì

It ¡gives ¡a ¡simple ¡view ¡of ¡the ¡sprint ¡progress. ¡ ¡ ì Release ¡burndown ¡chart ¡ ¡

ì

shows ¡the ¡amount ¡of ¡work ¡le< ¡to ¡complete ¡the ¡target ¡ commitment ¡for ¡a ¡Product ¡Release ¡ ì Alterna>ve ¡release ¡burndown ¡chart ¡

ì

which ¡basically ¡does ¡the ¡same, ¡but ¡clearly ¡shows ¡scope ¡ changes ¡to ¡Release ¡Content, ¡by ¡resemng ¡the ¡baseline. ¡

Burndown ¡Charts ¡

Modifications: ¡Scrum-­‑ban(1) ¡

ì Scrum-­‑ban ¡is ¡a ¡produc>on ¡model ¡based ¡on ¡Scrum ¡and ¡

• Kanban. ¡ ¡

ì It ¡is ¡suited ¡for ¡maintenance ¡projects ¡or ¡(system) ¡projects ¡

with ¡frequent ¡and ¡unexpected ¡user ¡stories ¡or ¡ programming ¡errors. ¡ ¡

ì In ¡such ¡cases ¡the ¡>me-­‑limited ¡sprints ¡of ¡the ¡Scrum ¡

model ¡are ¡of ¡no ¡appreciable ¡use, ¡but ¡Scrum’s ¡daily ¡ mee>ngs ¡and ¡other ¡prac>ces ¡can ¡be ¡applied. ¡ ¡

ì Visualiza>on ¡of ¡the ¡work ¡stages ¡and ¡limita>ons ¡for ¡

simultaneous ¡unfinished ¡user ¡stories ¡and ¡defects ¡are ¡ familiar ¡from ¡the ¡Kanban ¡model. ¡ ¡

Modifications: ¡Scrum-­‑ban(2) ¡

ì Using ¡these ¡methods, ¡the ¡group’s ¡workflow ¡is ¡

directed ¡in ¡a ¡way ¡ ¡

ì

that ¡allows ¡for ¡minimum ¡comple>on ¡>me ¡for ¡each ¡user ¡ story ¡or ¡programming ¡error, ¡ ¡

ì

and ¡on ¡the ¡other ¡hand ¡ensures ¡each ¡group ¡member ¡is ¡ constantly ¡employed. ¡

ì The ¡major ¡differences ¡between ¡Scrum ¡and ¡Kanban ¡

are ¡

ì

in ¡Scrum, ¡work ¡is ¡divided ¡into ¡sprints ¡that ¡last ¡a ¡certain ¡ amount ¡of ¡>me ¡

ì

whereas ¡in ¡Kanban ¡the ¡workflow ¡is ¡con>nuous. ¡

Advantages ¡(1) ¡

ì

The ¡SCRUM ¡methodology ¡is ¡designed ¡to ¡be ¡quite ¡flexible ¡

• throughout. ¡

ì

It ¡provides ¡control ¡mechanisms ¡for ¡planning ¡a ¡product ¡release ¡ and ¡then ¡managing ¡variables ¡as ¡the ¡project ¡progresses. ¡ ¡

ì

This ¡enables ¡organiza>ons ¡to ¡change ¡the ¡project ¡and ¡deliverables ¡ at ¡any ¡point ¡in ¡>me, ¡delivering ¡the ¡most ¡appropriate ¡release. ¡

ì

The ¡SCRUM ¡methodology ¡frees ¡developers ¡to ¡devise ¡the ¡most ¡ ingenious ¡solu>ons ¡throughout ¡the ¡project, ¡as ¡learning ¡occurs ¡ and ¡the ¡environment ¡changes. ¡

ì

Small, ¡collabora>ve ¡teams ¡of ¡developers ¡are ¡able ¡to ¡share ¡tacit ¡ knowledge ¡about ¡development ¡processes. ¡ ¡

Advantages ¡(2) ¡

ì Object ¡Oriented ¡technology ¡provides ¡the ¡basis ¡for ¡the ¡

SCRUM ¡methodology. ¡ ¡

ì Objects, ¡or ¡product ¡features, ¡offer ¡a ¡discrete ¡and ¡

manageable ¡environment. ¡ ¡

ì Procedural ¡code, ¡with ¡its ¡many ¡and ¡intertwined ¡

interfaces, ¡is ¡inappropriate ¡for ¡the ¡SCRUM ¡

• methodology. ¡ ¡

ì SCRUM ¡may ¡be ¡selec>vely ¡applied ¡to ¡ ¡ procedural ¡systems ¡with ¡clean ¡interfaces ¡ ¡ and ¡strong ¡data ¡orienta>on. ¡

Some ¡difficulties ¡

Get ¡set ¡go! ¡

References ¡

ì Ken ¡Schwaber. ¡“SCRUM ¡Development ¡Process” ¡ <h[p://home.hib.no/ai/data/master/mod251/2009/ ar>cles/scrum.pdf> ¡ ì h[p://en.wikipedia.org/wiki/Scrum_(development) ¡ ì h[p://www.crisp.se/henrik.kniberg/presenta>ons/

Scrum-­‑Intro-­‑Brief-­‑Henrik-­‑Kniberg.pdf ¡