Udhëzuesi i Scrum™
Udhëzuesi definitiv për Scrum:
Rregullat e Lojës

Nëntor 2017

Zhvilluar dhe mbështetur nga krijuesit e Scrum: Ken Schwaber dhe Jeff Sutherland

Shqip | AlbanianPërmbajtjaQëllimi i Udhëzuesit ......................................................................................................................... 3Përcaktimi i Scrum............................................................................................................................ 3Përdorimet e Scrum-it ...................................................................................................................... 3
Teoria e Scrum.................................................................................................................................. 4
Vlerat e SCRUM ................................................................................................................................ 5
Scrum Team (Ekipi Scrum) ............................................................................................................... 5
Product Owner ............................................................................................................................. 6
Ekipi Zhvillues ............................................................................................................................... 6
Scrum Master ............................................................................................................................... 7
Ngjarjet e Scrum-it ........................................................................................................................... 8
Sprint ............................................................................................................................................ 8
Planifikimi i Sprint-it (Sprint Planning) ......................................................................................... 9
Daily Scrum ................................................................................................................................. 11
Sprint Review ............................................................................................................................. 12
Sprint Retrospective ................................................................................................................... 13
Artifaktet e Scrum .......................................................................................................................... 13
Product Backlog.......................................................................................................................... 14
Sprint Backlog ............................................................................................................................. 15
Inkrementi .................................................................................................................................. 16
Transparenca e artifakteve ............................................................................................................ 16Përkufizimi i "Përfunduar" ( Definition of “Done”) .................................................................... 16Shënim i fundit ............................................................................................................................... 17Mirënjohje ...................................................................................................................................... 17Njerëzit ....................................................................................................................................... 17
Historia ....................................................................................................................................... 18
Translator Acknowledgement .................................................................................................... 18
Ndryshimet ndërmjet udhëzuesve të 2016 dhe 2017 ............................................................ 18©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 2Qëllimi i Udhëzuesit
Scrum është një framework për të zhvilluar, dorëzuar dhe mirëmbajtur produkte komplekse. Kyudhëzues përmban përcaktimin e Scrum. Ky përcaktim përbëhet nga rolet, ngjarje dhe artifaktet
e Scrum si dhe nga rregullat që i lidhin bashkë. Ken Schwaber (Shuaber) dhe Jeff Sutherland(Sadhërlend) kanë zhvilluar Scrum-in; Udhëzuesi i Scrum-it është shkruar dhe mundësuar prej
tyre. Së bashku, ata qëndrojnë pas tij.

Përcaktimi i Scrum
Scrum (emër, Skram): Një framework nëpërmjet të cilit njerëzit mund të adresojnë probleme
komplekse dhe të adaptueshme, ndërkohë që në mënyrë produktive dhe kreative dorëzojnë
produkte me vlerën më të lartë të mundur.
Scrum është:•••I lehtë
I thjeshtë për tu kuptuar
I vështirë për tu përvetësuar

Scrum është një strukturë procesi që është përdorur për të menaxhuar zhvillimin e produkteve
komplekse që prej 1990. Scrum nuk është një proces apo teknikë për të ndërtuar produkte; nëfakt është një framework nëpërmjet të cilit mund të vendosen në punë procese dhe teknika të
ndryshme.
Scrum qartëson efikasitetin relativ të menaxhimit të produktit dhe teknikave të punës, në mënyrë
që ju të përmirësoni vazhdimisht produktin, ekipin dhe mjedisin e punës.
Struktura e Scrum-it përbëhet nga Scrum Team (Ekipi/et Scrum) dhe rolet, ngjarjet, artifaktet dherregullat që e shoqërojnë. Çdo komponent i strukturës ka një qëllim specifik dhe është thelbësor
për suksesin dhe përdorimin e Scrum-it.
Rregullat e Scrum-it lidhin së bashku ngjarjet, rolet dhe artifaket, duke mbikëqyrur kështu
marrëdhëniet dhe ndërveprimet midis tyre. Rregullat e Scrum-it përshkruhen përgjatë këtij
dokumenti.
Taktika specifike për përdorimin e strukturës së Scrum-it variojnë dhe janë të përshkruara dikutjetër.

Përdorimet e Scrum-it
Scrum fillimisht u ndërtua për të zhvilluar dhe menaxhuar produkte. Duke filluar që nga 1990,
Scrum është përdorur gjerësisht në të gjithë botën, për të:
1. Kërkuar dhe identifikuar tregje, teknologji dhe kapacitete produktesh ku mund të
zbatohet.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 3

2. Zhvilluar produkte dhe përmirësime.
3. Publikuar produkte dhe përmirësime të shpeshta në një ditë.
4. Zhvilluar dhe mirëmbajtur ambiente operacionale në Cloud (online, secure, on-demand)
dhe të tjera që i shërbejnë për produktet.
5. Mirëmbajtur dhe rinovuar produktet.
Scrum është përdorur për të zhvilluar softuer, harduer, softuer të brendshëm, rrjete të
funksioneve të ndërveprueshme, automjete autonome, shkolla, qeveri, marketing, menaxhimin e
funksionimit të organizatave dhe pothuajse çdo gjë që ne përdorim në jetën tonë të përditshme,
si individë dhe shoqëri.
Teksa teknologjia, tregu, kompleksiteti i mjedisit dhe ndërveprimet mes tyre janë rritur me
shpejtësi, përdorimi i Scrum-it në trajtimin e këtij kompleksiteti vërtetohet çdo ditë.
Scrum është veçanërisht efektiv në transferimin e njohurive në mënyrë iterative dheinkrementale. Scrum tashmë përdoret gjerësisht për produktet, shërbimet dhe menaxhimin eorganizatës prind.
Thelbi i Scrum është një ekip i vogël njerëzish. Ekipi individual është shumë fleksibël dhe adaptiv.
Këto pika të forta vazhdojnë të funksionojnë në një ekip, disa ekipe apo dhe rrjet ekipesh që
zhvillojnë, nxjerrin, operojnë dhe mbështesin punën dhe produktet e punës së mijëra njerëzve.
Ata bashkëpunojnë dhe ndërveprojnë përmes zhvillimit të sofistikuar të arkitekturave dhemjediseve të publikimit final (release) të synuar.
Kur fjalët "zhvillo" dhe "zhvillim" përdoren në udhëzuesin e Scrum-it, ato i referohen një pune
komplekse, siç janë ato lloje të identifikuara më sipër.

Teoria e Scrum
Scrum ka në themelet e tij teorinë e procesit empirik të kontrollit, ose i thënë ndryshe empirizmi.
Empirizmi pohon se dija vjen nga eksperienca dhe marrja e vendimeve bazohet në atë që është enjohur. Scrum përdor një qasje iterative, inkrementale për të optimizuar parashikueshmërine dhepër të kontrolluar riskun. Tre shtyllat që mbështesin çdo implementim të një procesi empirik të
kontrollit, janë: transparenca, inspektimi, dhe adaptimi.

Transparenca
Aspekte domethënëse të procesit duhet të jenë të dukshme për ata që janë përgjegjës për
rezultatet. Vetë transparenca kërkon që këto aspekte të jenë te përcaktuara nga një standard ipërbashkët kështu që vëzhguesit të mund të kuptojnë njësoj atë që po shohin.
Për shembull:-Një gjuhë e përbashkët që i referohet procesit duhet të përdoret nga të gjithë aktorët;dhe
Ata të cilët e kryejnë punën dhe ata të cilët e pranojnë duhet të ndajnë një definicion tëpërbashkët të “Definition of Done”.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 4

Inspektimi
Përdoruesit e Scrum duhet të inspektojnë shpesh artifaktet e Scrum-it dhe progresin drejt një“Sprint Goal” për të zbuluar varianca të padëshirueshme. Inspektimi i tyre nuk duhet të jetë aq i
shpeshtë sa të pengoj punën. Inspektimet janë të dobishme kur kryhen nga inspektor me aftësi
të mira dhe kompetencat e duhura në momentet e duhura gjatë punës.

AdaptimiNëse një inspektor ka arritur në konkluzionin që një ose më shumë aspekte të procesit po
devijojnë jashtë limiteve të pranueshëm, dhe si pasojë produkti do të jetë i papranueshëm,procesi ose materialet të cilat po procesohen duhet të rregullohen. Një rregullim duhet të behetsa më shpejt qe të jetë e mundur për të minimizuar vazhdimin e devijimit.
Scrum përshkruan 4 ngjarje formale që duhet të ndodhin në kuadër të inspektimit dhe adaptimit:-

Planifikimi i Sprint-it (Sprint Planning)
Takimi ditor (Daily Scrum)
Kontrolli i Sprint (Sprint Review)
Retrospektiva e Sprint-it (Sprint Retrospective)

Vlerat e SCRUM
Kur vlerat e angazhimit, kurajës, fokusit, sinqeritetit dhe respektit janë mishëruar dhe përjetohen
nga Ekipi Scrum (Scrum Team); shtyllat e transparencës, inspektimit dhe adaptimit lulëzojnë dhendërtojnë besimin te të gjithë. Anëtarët e Ekipit Scrum i mësojnë dhe i eksplorojnë këto vlerandërkohë që punojnë me ngjarjet, rolet dhe artifaktet e Scrum.
Përdorimi me sukses i Scrum varet nga njerëzit të cilët bëhen të zotë të jetojnë këto pesë vlera.
Njerëzit vetë angazhohen për të arritur qëllimet e Ekipit Scrum. Anëtarët e Ekipit Scrum kanëkurajën për të bërë gjënë e duhur dhe të punojnë për të zgjidhur probleme të vështira. Të gjithë
fokusohen tek puna e përcaktuar në Sprint dhe qëllimet e Ekipit Scrum. Ekipi Scrum dhe palët etjera të interesuara bien dakord që të jenë të hapur për të gjithë punën dhe sfidat e kryerjes sësaj. Anëtarët e Ekipit Scrum e respektojnë njeri tjetrin si njerëz të aftë dhe të pavarur.

Scrum Team (Ekipi Scrum)
Ekipi Scrum përbëhet nga Product Owner, Development Team (Ekipi Zhvillues) dhe Scrum Master.
Ekipet e Scrum janë vetorganizuese dhe ndërfunksionale. Ekipet vetorganizuese zgjedhin se si tëkryejnë më mirë punën e tyre, në vend që të drejtohen nga të tjerët jashtë ekipit. Ekipetndërfunksionale kanë të gjitha aftësitë e nevojshme për të kryer punën pa u varur nga të tjerët që
nuk janë pjesë e ekipit. Modeli i ekipit në Scrum është projektuar për të optimizuar fleksibilitetin,kreativitetin dhe produktivitetin. Ekipi Scrum e ka provuar veten në të qënurit gjithnjë e më
efektiv në të gjitha përdorimet e Scrum te cituara më sipër, dhe çdo pune komplekse.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 5

Ekipet e Scrum dorëzojnë produkte në mënyrë iterative dhe inkrementale, duke maksimizuarmundësitë për të marrë feedback. Dorëzime inkrementale të një produkti "Done" (“Përfunduar”)
sigurojnë një version potencialisht të përdorshëm të produktit të punës që është gjithmonë në
dispozicion.

Product Owner
Product Owner-i është përgjegjës për maksimizimin e vlerës së produktit që rezulton nga puna e
Ekipit të Zhvillimit. Mënyra si bëhet kjo, mund të ndryshojë shumë ndër organizata, Ekipet e Scrum
dhe individë.
Product Owner-i është i vetmi person përgjegjës për menaxhimin e Product Backlog. Menaxhimi
i Product Backlog përfshin:-

Shprehjen sa më të qartë të elementeve të listuara në Product Backlog;
Renditjen e elementeve në Product Backlog për të arritur sa më mirë qëllimet dhe
misionet;
Optimizimin e vlerës së punës të realizuar nga Ekipi Zhvillues;Të sigurojë që Product Backlog është i dukshëm, transparent, dhe i qartë për të gjithë dhegjithashtu të tregojë se me çfarë do të punojë Ekipi i Scrum;Të sigurojë që Ekipi Zhvillues kupton të gjitha kërkesat e listuara në Product Backlog nënivelin e kërkuar.

Product Owner-i mund të bëjë punën e mësipërme, ose ja lë Ekipit Zhvillues që ta bëjë. Sido që tëjetë, Product Owner është përgjegjës.
Product Owner-i është një person, jo një grup apo komitet. Product Owner-i mund të përfaqësoj
dëshirën e një grupi apo komiteti në Product Backlog, por ata që duan të ndryshojnë prioritetin e
një kërkesë në Product Backlog duhet të drejtohen tek Product Owner-i.
Që Product Owner-i të arrijë sukses e gjithë kompania duhet të respektojë vendimet e tij.
Vendimet e Product Owner-it reflektohen në përmbajtjen dhe renditjen e Product Backlog-ut.
Nuk i lejohet askujt që t’i kërkojë Ekipit Zhvillues të punojë me një bashkësi kërkesash të
ndryshme, dhe as Ekipit Zhvillues nuk i lejohet të veprojë mbi bazën e fjalëve të çdokujt tjetër.

Ekipi Zhvillues
Ekipi Zhvillues përbëhet nga profesionistë të cilët kryejnë punën për të dorëzuar një inkrementtë përfunduar (“Done”) dhe potencialisht të lëvrueshëm të produktit në fund të çdo Sprint-i.
Vetëm anëtarët e Ekipit Zhvillues krijojnë Inkrementin.
Ekipet Zhvilluese strukturohen dhe fuqizohen nga kompania për të organizuar dhe menaxhuarpunën e tyre. Si rrjedhim sinergjia që krijohet e optimizon eficencën dhe efektivitetin epërgjithshëm të Ekipit Zhvillues.
Ekipet Zhvilluese kanë karakteristikat e mëposhtme:©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 6--Janë vetorganizues. Asnjë (as vetë Scrum Master) nuk mund ti tregojë Ekipit Zhvillues sesi të kthejë Product Backlog-un ne Inkremente të funksionaliteteve potencialisht tëlëvrueshme;
Ekipet Zhvilluese janë ndërfunksional. Kanë të gjitha aftësitë e nevojshme si ekip për të
krijuar një Inkrement të produktit;
Scrum nuk njeh tituj të tjerë për anëtarët e Ekipit Zhvillues përveçse Zhvillues,
pavarësisht punës që do të kryhet nga anëtari; nuk ka përjashtime nga ky rregull;Scrum nuk njeh nën ekipe në Ekipin Zhvillues, pavarësisht fushave të ndryshme që duhettë adresohen si testimi apo analiza e biznesit; nuk ka përjashtime nga ky rregull;Anëtarët e Ekipit Zhvillues mund të kenë aftësi individuale të specializuara dhe te jenë të
fokusuar në fusha të caktuara, por përgjegjësia i përket Ekipit Zhvillues si i tërë.

Madhësia e Ekipit ZhvilluesMadhësia optimale e Ekipit Zhvillues është aq e vogël sa të mund të qëndrojnë të zhdërvjellët
dhe aq e madhe sa të mund të përfundojnë punë të rëndësishme dhe domethënëse brenda një
Sprint-i. Më pak se tre anëtarë e ulin nivelin e ndërveprimit duke rezultuar kështu në përfitimemë të vogla të produktivitetit. Ekipet Zhvilluese të vogla mund të përballen me kufizime në aftësitë
teknike te nevojshme gjatë Sprint-it, si rrjedhojë Ekipi Zhvillues mund të mos arrijë të dorëzojë
një Inkrement potencialisht të lëvrueshëm.
Ndërkohë që më shumë se 9 anëtarë kërkon shumë koordinim. Ekipet Zhvilluese të mëdha
gjenerojnë shumë kompleksitet për të menaxhuar një process empirik. Rolet e Product Owner-it
dhe Scrum Master-it nuk janë përfshirë te numrat e ekipit, në mos edhe ata kryejnë punë nga
Sprint Backlog-u.

Scrum MasterScrum Master-i është përgjegjës për të promovuar dhe suportuar Scrum ashtu siç është ipërcaktuar në udhëzuesin Scrum. Scrum Master e realizon këtë gjë duke ndihmuar të gjithë të
kuptojnë teorinë e Scrum, praktikat, rregullat dhe vlerat.
Scrum Master-i është një lider-shërbyes për Ekipin Scrum ( Scrum Team). Scrum Master-i
ndihmon ata jashtë Ekipit Scrum të kuptojnë se cilat ndërveprime me Ekipin Scrum janë ndihmëse
dhe cilat jo. Scrum Master ndihmon të gjithë të ndryshojnë këto ndërveprime në mënyrë që të
maksimizojë vlerën e krijuar nga Ekipi Scrum.

Shërbimet e Scrum Master-it ndaj Product Owner-it
Scrum Master-i i shërben Product Owner-it në disa mënyra, duke përfshirë:-Siguron që qëllimi, shtrirja dhe fusha e produktit është kuptuar nga të gjithë anëtarët e
Ekipit Scrum sa më mirë që është e mundur.
Gjetjen e teknikave për një menaxhim efektiv të Product Backlog-ut;
Ndihmon Ekipin Scrum që të kuptojë nevojën për kërkesa të qarta dhe koncize të ProductBacklog;Të kuptuarit e planifikimit në një mjedis empirik;©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 7

-Siguron që Product Owner di si të organizojë Product Backlog-un për të maksimizuarvlerën;Të kuptuarit dhe të praktikuarit të “Agile”;
Lehtëson ngjarjet e Scrum sipas nevojës apo kërkesës.

Shërbimet e Scrum Master ndaj Ekipit Zhvillues
Scrum Master i shërben Ekipit Zhvillues në disa mënyra, duke përfshirë:-Mëson Ekipin zhvillues si të vetorganizohet dhe të jetë ndërfunksional;
Ndihmon Ekipin Zhvillues të krijojë produkte me vlerë të lartë;Largon pengesat ndaj progresit të Ekipit Zhvillues;Lehtëson ngjarjet e Scrum sipas nevojës apo kërkesës;Mëson Ekipin Zhvillues në ambiente ku Scrum akoma nuk është kuptuar dhe adaptuar.

Shërbimet e Scrum Master ndaj Kompanisë
Scrum Master i shërben Kompanisë në disa mënyra, duke përfshirë:-Drejton dhe mëson kompaninë ne adaptimin e Scrum;
Planifikon implementimin e Scrum brenda kompanisë;Ndihmon punonjësit, palët e tjera të përfshira, të kuptojnë dhe të përdorin Scrum-in
dhe zhvillimin empirik të një produkti;
Shkakton ndryshime që rrisin produktivitetin e Ekipit Scrum;
Punon me Scrum Master-a të tjerë për të rritur efektivitetin e aplikimit të Scrum-it në
kompani.

Ngjarjet e Scrum-it
Ngjarje të planifikuara përdoren në Scrum për të krijuar rregullsinë dhe për të minimizuar nevojën
e takimeve ta papërcaktuara në Scrum. Të gjitha ngjarjet kanë të përcaktuar një kohëzgjatje
maksimale (time-boxed). Sapo një Sprint fillon, kohëzgjatja e tij është fikse dhe nuk mund të
shkurtohet apo të zgjatet. Ngjarjet e tjera mund të përfundojnë kurdo që qëllimi i ngjarjes është
arritur, duke siguruar kështu shpenzimin e kohës së duhur pa lejuar harxhime të tepërta në
proces.
Përveç Sprint-it, i cili është një “enë mbajtëse” për të gjitha ngjarjet e tjera, çdo ngjarje në Scrumështë një mundësi për të kontrolluar dhe adaptuar diçka. Këto evente janë ndërtuar specifikisht
për të mundësuar kritikën transparente dhe kontrollin. Moskryerja e njërës prej këtyre ngjarjeve
rezulton në ulje të transparencës dhe është një mundësi e humbur për inspektim dhe adaptim.

SprintZemra e Scrum-it është një Sprint, një ngjarje me kohëzgjatje të fiksuar një mujore ose më pak,gjatë së cilës krijohet një produkt “Done”, i përdorshëm dhe potencialisht i lëvrueshëm. E miraështë që Sprint-et të kenë një kohëzgjatje konsistente gjatë zhvillimit. Një Sprint i ri fillonmenjëherë pas përfundimit të Sprint-it të mëparshëm.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 8

Sprint-et përmbajnë dhe përbëhen nga Sprint Planning, Daily Scrum, punën zhvilluese, Sprint
Review dhe Sprint Retrospective.
Gjatë Sprint-it:-

Nuk bëhet asnjë ndryshim që vë në rrezik Qëllimin e Sprint (Sprint Goal);Qëllimet për cilësinë nuk reduktohen;
Shtrirja (Scope) mund të qartësohet dhe të rinegociohet ndërkohë që mësohet mëshumë, ndërmjet Product Owner-it dhe Ekipit Zhvillues.

Çdo Sprint mund të konsiderohet një projekt me një kohëzgjatje jo më të madhe se një muaj.
Ashtu si projektet, Sprint-et përdoren për të arritur diçka. Çdo Sprint ka një qëllim mbi punën që
do kryhet, një dizajn dhe plan fleksibël që do të drejtojë në realizimin e qëllimit, punën, dheproduktin rezultat.
Sprint-et janë të limituar në një muaj kalendarik. Kur shtrirja e një Sprint-i është shumë e gjatë
përcaktimi i asaj që do të ndërtohet mund të ndryshojë, kompleksiteti rritet dhe risqet shtohen.
Sprint-et mundësojnë parashikueshmërinë duke siguruar inspektimin dhe adaptimin e progresit
drejt Qëllimit të Sprintit (Sprint Goal) të paktën cdo muaj kalendarik. Gjithashtu, Sprint-et
reduktojnë kostot e risqeve të një muaji kalendarik.

Anulimi i një Sprint-i
Një Sprint mund të anulohet përpara se të mbarojë koha e përcaktuar. Vetëm Product Owner-i ka
autoritetin për të anuluar një Sprint, edhe pse ai ose ajo mund ta bëjë këtë nën influencën e palëve
të tjera të përfshira, Ekipit Zhvillues apo Scrum Master-it.
Një Sprint mund të anulohet kur Qëllimi i Sprint-it (Sprint Goal) është i vjetruar. Kjo mund të ndodh
kur kompania ndryshon drejtimin ose kur kushtet e tregut apo të teknologjisë kanë ndryshuar. Nëpërgjithësi, një Sprint duhet të anulohet kur nuk ka më kuptim në kontekstin e rrethanave. Por,për shkak të kohëzgjatjes së shkurtër të Sprint-it, anulimi ka kuptim rrallëherë.
Kur një Sprint anulohet, çdo element i Product Backlog që është përfunduar dhe “Done”,
rishikohet. Nëse një pjesë e punës është potencialisht e lëvrueshme, Product Owner-i e pranon.
Të gjitha elementet e Product Backlog që janë të papërfunduara ri-vlerësohen dhe vendosensërish në Product Backlog. Puna e bërë në to, amortizohet shpejt dhe duhet rivlerësuar shpesh.
Anulimet e Sprint-eve konsumojnë burimet, duke qenë se të gjithë duhet të rimblidhen sërish nënjë tjetër Sprint Planning për të filluar një Sprint të ri. Anulimet e Sprint-eve shpesh janëtraumatike për Ekipin Scrum dhe janë shumë të pazakonta.

Planifikimi i Sprint-it (Sprint Planning)
Puna që do të kryhet në një Sprint, planifikohet në takimin e Planifikimit të Sprint-it (Sprint
Planning). Ky plan krijohet nga puna e përbashkët e të gjithë Ekipit Scrum.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 9

Planifikimi i Sprint-it ka një kohë të caktuar prej maksimumi 8 orësh për një Sprint me kohëzgjatjenjë muaj. Për Sprint-e më të shkurtra, kjo ngjarje është më e shkurtër. Scrum Master-i siguron që
kjo ngjarje të ndodhë dhe që pjesëmarrësit e kuptojnë qëllimin e saj. Scrum Master mëson Ekipin
Scrum që takimi të kryhet sipas kohës së përcaktuar.
Planifikimi i Sprint-it u përgjigjet pyetjeve të mëposhtme••Çfarë mund të lëvrohet në Sprint-in e radhës duke marrë parasysh Inkrementin që është
krijuar?
Si do të realizohet puna e nevojshme për lëvrimin e Inkrementit?

Çështja 1: Çfarë mund të bëhet në këtë Sprint?
Ekipi Zhvillues punon për të parashikuar funksionalitetet që do të zhvillohen gjatë Sprint-it.
Product Owner-i diskuton objektivat që Sprint duhet të arrijë dhe ato elemente të Product Backlog
të cilat kur përfundohen brenda Sprint-it arrijnë qëllimin e tij (Sprint Goal). I gjithë Ekipi Scrum
bashkëpunon për të kuptuar punën e një Sprint-i.
Informacioni i nevojshëm për të filluar këtë takim është Product Backlog, Inkrementi i fundit i
produktit, kapaciteti i Ekipit të Zhvillimit gjatë Sprint-it dhe performanca e kaluar e Ekipit të
Zhvillimit. Numri i elementeve të përzgjedhur nga Product Backlog për Sprint është përgjegjësi
vetëm e Ekipit të Zhvillimit. Vetëm Ekipi i Zhvillimit mund të vlerësojë se çfarë mund të arrijë gjatë
Sprint-it të ardhshëm.
Gjatë Planifikimit të Sprint-it, Ekipi i Scrum-it gjithashtu krijon Qëllimin e Sprint-it (Sprint Goal).
Qëllimi i Sprint-it është një objektiv që do të përmbushet brenda Sprint-it përmes implementimit
të Product Backlog dhe ofron udhëzime për Ekipin e Zhvillimit se pse po e ndërton Inkrementin.

Çështja 2: Si do të realizohet puna që është zgjedhur për tu bërë?
Pasi kanë përcaktuar Qëllimin e Sprint dhe përzgjedhur elementet e Product Backlog për Sprintin, Ekipi i Zhvillimit vendos se si do ta ndërtojë këtë funksionalitet në një produkt të "Përfunduar"(Done) gjatë Sprint. Elementet e Product Backlog të përzgjedhur për këtë Sprint si dhe plani përdorëzimin e tyre quhen Sprint Backlog.
Ekipi i Zhvillimit zakonisht fillon me dizenjimin e sistemit dhe punën e nevojshme për tëtransformuar elementët e Product Backlog në një Inkrement. Puna mund të jetë e përmasave osevlerësimeve të ndryshme. Megjithatë, gjatë Planifikimit të Sprint-it për Ekipin e Zhvillimit është
planifikuar një punë e mjaftueshme për të parashikuar atë që beson se mund të bëjë në Sprinti-n
e ardhshëm. Puna e planifikuar për ditët e para të Sprint-it nga Ekipi i Zhvillimit dekompozohet
nga fundi i këtij takimi, shpesh në njësi të një dite ose më pak. Ekipi i Zhvillimit vetorganizohet përtë realizuar punën në Sprint Backlog, si gjatë Planifikimit të Sprint ashtu edhe gjatë Sprint-it.
Product Owner-i mund të ndihmojë për të sqaruar dhe qartësuar elementet e zgjedhur të ProductBacklog dhe për të bërë negocime. Nëse Ekipi i Zhvillimit përcakton se ka shumë punë ose shumë
pak punë, mund të rinegociojë me Product Owner-in elementët e zgjedhur nga Product Backlog.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 10

Ekipi i Zhvillimit mund të ftojë gjithashtu njerëz të tjerë që të marrin pjesë në takim për dhënë
këshilla teknike ose të fushës së biznesit.
Në fund të Planifikimit të Sprint-it, Ekipi i Zhvillimit duhet të jetë në gjendje t'i shpjegojë Product
Owner-it dhe Scrum Master-it se si mendon të punojë si një ekip vetorganizues për të përmbushurQëllimin e Sprint-it dhe për të krijuar Inkrementin e parashikuar.

Qëllimi i Sprint-it (Sprint Goal)Qëllimi i Sprint-it është një objektiv i vendosur për sprintin që mund të arrihet përmes
implementimit të Product Backlog. Ai jep udhëzime për Ekipin e Zhvillimit se pse po ndërton
Inkrementin. Është krijuar gjatë takimit të Planifikimit të Sprint-it. Qëllimi i Sprintit i jep Ekipit të
Zhvillimit njëfarë fleksibiliteti sa i përket funksionaliteteve qe do implementohen brenda sprintit.
Elementet e përzgjedhur të Product Backlog ofrojnë një funksion koherent, i cili mund të jetë vetëQëllimi i Sprint-it. Qëllimi i Sprint-it mund të jetë çdo koherencë tjetër që bën Ekipin e Zhvillimit
të punojë më shumë së bashku se në nisma të veçanta.
Gjatë gjithë kohës qe Ekipi i Zhvillimit punon, mban në mendje Qëllimin e Sprint-it. Për tëpërmbushur Qëllimin e Sprint-it, ekipi implementon funksionalitetet dhe teknologjinë. Nëse punarezulton të jetë e ndryshme nga ajo që Ekipi i Zhvillimit priste, ata bashkëpunojnë me Product
Owner-in për të negociuar elementet e Sprint Backlog brenda Sprint.

Daily Scrum
Daily Scrum është një event me kohëzgjatje(time boxed) 15 minuta për Ekipin e Zhvillimit. Daily
Scrum mbahet çdo ditë të Sprint-it. Në të, Ekipi i Zhvillimit planifikon punën për 24 orët eardhshme. Kjo gjë optimizon bashkëpunimin e ekipit dhe performancën duke inspektuar punën
që nga Daily Scrum i fundit dhe duke parashikuar punën që vijon në Sprint. Daily Scrum mbahetçdo ditë, në të njëjtën kohë dhe në të njëjtin vend, për të reduktuar kompleksitetin.
Ekipi i Zhvillimit (Development Team) përdor Daily Scrum për të inspektuar progresin përkundrejtQëllimit të Sprint (Sprint Goal) dhe për të inspektuar trendin e progresit përkundrejt përfundimittë punës në Sprint Backlog. Daily Scrum optimizon probabilitetin që Ekipi i Zhvillimit të arrijë
Qëllimin e Sprint-it (Sprint Goal). Çdo ditë Ekipi i Zhvillimit duhet të kuptojë se si kanë ndërmend
të punojnë sëbashku si një ekip i vetorganizuar për të përmbushur Sprint Goal dhe të krijojnë
inkrementin e pritur në fundin e Sprint-it.
Struktura e mbledhjes vendoset nga Ekipi i Zhvillimit dhe mund të kryhet në mënyra të ndryshmenëse fokusohet në progresin përkundrejt Sprint Goal. Disa Ekipe zhvillimi do të përdornin
pyetjet, disa të tjera do të ishin më shumë të bazuara në diskutime. Më poshtë jepet një shembull
mbi çfarë mund të përdoret:•••Çfarë bëra dje që ndihmoi Ekipin e Zhvillimit që të arrijë Sprint Goal?
Çfarë do të bëj sot për të ndihmuar Ekipin e Zhvillimit të arrijë Sprint Goal?
A shoh ndonjë pengesë që më privon mua ose Ekipin e Zhvillimit për përmbushjen e SprintGoal?

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 11

Ekipi i Zhvillimit ose anëtarë të ekipit, shpesh, takohen menjëherë pas Daily Scrum për diskutimemë të hollësishme, ose për të adaptuar, ose për të riplanifikuar, pjesën e mbetur të punës së
Sprint.
Scrum Master siguron që Ekipi i Zhvillimit të mbajë takimin, por Ekipi i Zhvillimit është përgjegjës
për kryerjen e Daily Scrum. Scrum Master i mëson Ekipit të Zhvillimit të zbatojnë rregullin e
mbajtjes së Daily Scrum brenda kohëzgjatjes ( time-box ) prej 15-minutave.
Daily Scrum është një mbledhje e brendshme për Ekipin e Zhvillimit. Nëse të tjerë janë prezent,
Scrum Master siguron që ata/ato të mos ndërpresin mbledhjen.
Daily Scrum përmirëson komunikimin, eliminon takime të tjera, identifikon pengesat për tu hequrpër zhvillimin, nxjerr në pah dhe promovon vendimmarrjen e shpejtë dhe përmirëson nivelin enjohurive të Ekipit të Zhvillimit. Ky është një takim kyç, inspektues dhe adaptues.

Sprint Review
Një Sprint Review mbahet në fund të Sprint për të inspektuar Inkrementin dhe të përshtasë
Product Backlog nëse është e nevojshme. Gjatë mbledhjes së Sprint Review, Ekipi i Scrum (ScrumTeam) dhe grupet e interesit bashkëpunojnë rreth asaj që është “Përfunduar”(“Done”) në Sprint.
Bazuar në të dhe në çdo ndryshim të Product Backlog gjatë Sprint, pjesëmarrësit bashkëpunojnë
për gjërat e ardhshme që mund të bëhen për të optimizuar vlerën. Ky është një takim joformal
dhe prezantimi i inkrementit ka për qëllim mbledhjen e feedback dhe nxitjen e bashkëpunimit.
Ky është më së shumti një takim katër-orësh për Sprint një mujor. Për sprintet më të shkurtra,
eventi është zakonisht më i shkurtër. Scrum Master siguron që ngjarja (event) të ndodhë dhe sepjesëmarrësit e kuptojnë qëllimin e saj. Scrum Master i mëson të gjithë për ta mbajtur atë jomë shumë se koha e përcaktuar (time-box).
Sprint Review përfshin elementët e mëposhtëm:
•
•
•
•
•
•
•

Pjesëmarrësit përfshijnë Ekipin e Scrum dhe grupet kryesore të interesit (Stakeholders) tëftuar nga Product Owner;
Product Owner shpjegon se çfarë elementesh(items) të Product Backlog janë "Përfunduar”
dhe çfarë nuk është "Përfunduar”;
Ekipi i Zhvillimit diskuton se çfarë shkoi mirë gjatë Sprint-it, cilat janë problemet e shfaqura
dhe si u zgjidhën këto probleme;
Ekipi i Zhvillimit demonstron punën që ka "Përfunduar”" dhe i përgjigjet pyetjeve rreth
Inkrementit;
Product Owner diskuton për Product Backlog siç është. Ai ose ajo projekton datat emundshme të përfundimit, bazuar në progresin e deritanishëm (nëse është e nevojshme);
I gjithë grupi bashkëpunon në atë se çfarë duhet bërë më pas, në mënyrë që Sprint Preview
të sigurojë kontribut të vlefshëm për Sprint Planning;
Rishikimi i mënyrës, se si tregu ose përdorimi potencial i produktit, mund të ketë ndryshuaratë që është gjëja më e vlefshme për tu bërë në vazhdim; dhe,©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 12

•Rishikimi i afatit kohor (timeline), buxhetit, aftësive potenciale dhe tregut për release tjetër
të parashikuar të produktit.

Rezultati i Sprint Review është një Product Backlog i rishikuar i cili përcakton elementet emundshme të Product Backlog për Sprint-in e ardhshëm. Product Backlog mund të rregullohet nëpërgjithësi për të arritur mundësi të reja.

Sprint Retrospective
Sprint Retrospective është një mundësi për Ekipin e Scrum-it që të inspektojë veten dhe të krijojë
një plan me përmirësime për tu zbatuar gjatë sprintit të ardhshëm.
Sprint Retrospective ndodh pas Sprint Review dhe para Sprint Planning të ardhshëm.
Ky është një takim tre-orësh për Sprint një mujor. Për sprintet më të shkurtra, ngjarja (event)është zakonisht më i shkurtër. Scrum Master siguron që ngjarja të ndodhë dhe që pjesëmarrësit
kuptojnë qëllimin e saj. Scrum Master i mëson të gjithë për ta mbajtur kohëzgjatjen jo më shumë
se koha e përcaktuar (time-Box).
Scrum Master merr pjesë në mbledhje si anëtar i një ekipi prej përgjegjësisë që mbart mbi
procesin e Scrum.
Qëllimi i Sprint Retrospective është të:•••

Inspektojnë se si Sprint i fundit ka ecur, në lidhje me njerëzit, marrëdhëniet, proceset dhemjetet;Identifikojë dhe rendisë elementet (items) kryesorë që kanë ecur mirë dhe përmirësime tëmundshme; dhe,Krijimi i një plani për implementimin e përmirësimeve sipas mënyrës se si Ekipi i Scrum-it bënpunën e tij.

Scrum Master inkurajon Ekipin Scrum të përmirësojë procesin e zhvillimit dhe praktikat e tij, nëkuadër të procesit Scrum si framework , për ta bërë atë më efektiv dhe më të kënaqshëm në
sprintin tjetër. Gjatë çdo Sprint Retrospective, Ekipi i Scrum-it planifikon mënyra për të rriturcilësinë e produktit duke përshtatur përkufizimin e "Përfunduar” (definition of “Done”)sipas rastit.
Deri në fund të Sprint Retrospective, Ekipi i Scrum-it duhet të ketë identifikuar përmirësimet qëdo të implementohen në Sprint tjetër. Implementimi i këtyre përmirësimeve në Sprintin eardhshëm është përshtatja (adaption) e vetë inspektimit të ekipit të Scrum-it. Megjithëse
përmirësimet mund të implementohen në çdo kohë, Sprint Retrospective ofron një mundësi
formale për t'u fokusuar te inspektimi (inspection) dhe përshtatja (adaption).

Artifaktet e Scrum
Artifaktet e Scrum-it përfaqësojnë punë ose vlerë për të siguruar transparencë dhe mundësi për
inspektim dhe përshtatje. Artifaktet e përkufizuar nga Scrum janë projektuar posaçërisht për të©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 13

maksimizuar transparencën e informacionit kyç, në mënyrë që të gjithë të kenë të njëjtin kuptim
mbi artifaktin.

Product Backlog
Product Backlog është një listë e renditur e gjithçkaje që mund të jetë e nevojshme në produkt
dhe është burimi i vetëm i kërkesave për çdo ndryshim që duhet bërë tek produkti. Product Ownerështë përgjegjës për Product Backlog, duke përfshirë përmbajtjen, disponueshmërinë dherenditjen e tij.
Product Backlog nuk është kurrë i plotë. Zhvillimi më i hershëm i tij paraqet vetëm kërkesat të
cilat njihen fillimisht dhe që kuptohen mirë. Product Backlog evoluon siç evoluon dhe produktitë cilit i referohet dhe vetë mjedisit në të cilin do të përdoret. Product Backlog është dinamik; ai
ndryshon vazhdimisht për të identifikuar se çfarë i duhet produktit për të qenë i përshtatshëm,konkurrues dhe i dobishëm. Për sa kohë ekziston një produkt, ekziston dhe Product Backlog i tij.
Product Backlog rendit të gjitha karakteristikat, funksionet, kërkesat, përmirësimet dherregullimet të cilët përbëjnë ndryshimet që duhet t'i bëhen produktit në versionet e ardhshme.
Elementet (items) të Product Backlog kanë atributet e një përshkrimi, rendi, vlerësimi dhe vlere.
Siç një produkt përdoret dhe fiton vlerë, dhe tregu ofron feedback, Product Backlog bëhet një listë
më e madhe dhe më e hollësishme. Kërkesat nuk ndalojnë kurrë së ndryshuari, kështu që një
Product Backlog është një artifakt i gjallë. Ndryshimet në kërkesat e biznesit, kushtet e tregut, ose
teknologji mund të shkaktojnë ndryshime në Product Backlog.
Ekipet e shumëfishta Scrum shpesh punojnë së bashku në të njëjtin produkt. Një Product Backlog
përdoret për të përshkruar punën e ardhshme mbi produktin. Një atribut i Produkt Backlog që
grupon elementet (items) mund të përdoret më pas.
Rafinimi i Product Backlog (Product Backlog refinement) është akti i shtimit të detajeve,estimimeve dhe renditjes së elementeve në Product Backlog. Ky është një proces i vazhdueshëmnë të cilin Product Owner dhe Ekipi i zhvillimit bashkëpunojnë në detajimin e elementeve tëProduct Backlog. Gjatë rafinimit të Product Backlog, elementet shqyrtohen dhe rishikohen. Ekipi
Scrum vendos se si dhe kur bëhet rafinimi.
Rafinimi normalisht konsumon jo më shumë se 10% të kapacitetit të Ekipit të Zhvillimit.
Sidoqoftë, elementet e Product Backlog mund të përditësohen në çdo kohë nga Product Ownerose me lejen e Product Owner.
Elementët e Product Backlog të renditur më lartë, zakonisht, janë më të qartë dhe më të detajuar
sesa ata të renditur më poshtë.
Estimimet më të sakta bëhen në bazë të shkallës së lartë të qartësisë dhe detajeve; sa më i ulëtrendi, aq më pak detaje. Elementët e Product Backlog me të cilët Ekipi i Zhvillimit do të jetë i zënëpër Sprintin e ardhshëm, janë rafinuar në mënyrë që çdo element, në mënyrë të arsyeshme, të©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 14jetë "I Përfunduar” brenda time-box të Sprint. Elementet e Product Backlog që mund të"Përfundojnë" nga Ekipi i Zhvillimit brenda një Sprinti, konsiderohen "Gati" (“Ready”) përpërzgjedhje në një Sprint Planning. Zakonisht, elementet e Product Backlog fitojnë shkallë tëtransparencës nëpërmjet aktiviteteve të rafinimit të përshkruara më sipër.
Ekipi i Zhvillimit është përgjegjës për të gjitha estimimet. Product Owner mund të ndikojë te Ekipi
i Zhvillimit duke e ndihmuar atë të kuptojë dhe të zgjedhë trade-offs, por njerëzit që do të kryejnë
punën, bëjnë vlerësimin përfundimtar.

Monitorimi i progresit drejt një qëllimi (goal)Në çdo moment në kohë, puna totale e mbetur (total work remaining) për të arritur qëllimin mundtë përmblidhet. Product Owner gjurmon këtë punë totale të mbetur, të paktën çdo Sprint Review.
Product Owner e krahason këtë shumë me punën e mbetur në Sprint Reviews të mëparshme, përtë vlerësuar progresin drejt përfundimit të punës së projektuar sipas kohës së dëshiruar për të
arritur qëllimin(goal). Ky informacion bëhet transparent për të gjithë grupet e interesit.
Praktika të ndryshme projeksionale mbi trendin janë përdorur për të parashikuar progresin, siburn downs, burn ups ose cumulative flows. Këto kanë rezultuar të dobishme. Megjithatë, këtopraktika nuk zëvendësojnë rëndësinë e empirizmit. Në mjedise komplekse, ajo që do të ndodhë
është e panjohur. Vetëm ajo që ka ndodhur mund të përdoret për vendimmarrje me vizion për të
ardhmen.

Sprint Backlog
Sprint Backlog është një bashkësi nga Product Backlog items të përzgjedhur për Sprintin, plus njëplan për të dorëzuar inkrementin e produktit dhe realizimin e Qëllimit të Sprint (Sprint Goal).
Sprint Backlog është një parashikim nga Ekipi i Zhvillimit rreth funksionalitetit që do të jetë në
inkrementin tjetër dhe punën e nevojshme për të dorëzuar atë funksionalitet në inkrement të"Përfunduar".
Sprint Backlog-u bën të dukshme të gjithë punën që Ekipi i Zhvillimit identifikon si të nevojshme
për të përmbushur qëllimin e Sprint. Për të siguruar përmirësim të vazhdueshëm, përfshin tëpaktën një përmirësim procesi me prioritet të lartë të identifikuar në mbledhjen e mëparshme të
Retrospektivës.
Sprint Backlog është një plan me detaje të mjaftueshme, që ndryshimet në progres të mund të
kuptohen në Daily Scrum. Ekipi i zhvillimit modifikon Sprint Backlog përgjatë gjithë Sprint-it, dhe
Sprint Backlog shpërfaqet gjatë Sprint. Kjo shpërfaqe ndodh ndërkohë që Ekipi i Zhvillimit punonpërmes planit dhe mëson më shumë rreth punës që nevojitet për të arritur qëllimin e Sprint.
Kur kërkohet punë e re, Ekipi i Zhvillimit ia shton atë Sprint Backlog. Ndërkohë që puna është kryerose përfunduar, puna e mbetur e estimuar (the estimated remaining work) përditësohet. Kurelementet e planit konsiderohen të panevojshme, ato hiqen. Vetëm Ekipi i Zhvillimit mund të
ndryshojë Sprint Backlogun e tij gjatë një Sprint-i. Sprint Backlog është një pamje shumë e©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 15

dukshme dhe në kohë reale e punës që Ekipi i Zhvillimit planifikon të kryejë gjatë Sprint, që i përket
vetëm Ekipit të Zhvillimit.

Monitorimi i progresit të SprintitNë çdo moment në një Sprint, puna totale e mbetur në Sprint Backlog mund të përmblidhet.
Ekipi i Zhvillimit e gjurmon këtë punë totale që mbetet, të paktën për çdo Daily Scrum, për të
projektuar sa gjasa ka të arrihet qëllimi i Sprintit (Sprint Goal). Duke gjurmuar punën e mbeturpërgjatë gjithë Sprintit, Ekipi i Zhvillimit mund të menaxhojë progresin e tij.

Inkrementi
Inkrementi është shuma e të gjithë elementeve të Product Backlog të përfunduar gjatë një Sprinti
dhe vlera e inkrementeve të të gjitha sprint-eve të mëparshme. Në fund të një Sprint, Inkrementi
i ri duhet të jetë "Përfunduar", që do të thotë se duhet të jetë në gjendje të përdorshme dhe tëpërmbushë përkufizimin e Ekipit të Scrum të të qenit "Përfunduar" (definition of “Done”). Një
Inkrement është një trup punësh të inspektueshem, të përfunduar që mbështet empirizmin në
fund të Sprint. Inkrementi është një hap drejt një vizioni ose synimi. Ai duhet të jetë në gjendje tëpërdorshme pavarësisht nëse Product Owner vendos ta lëvrojë.

Transparenca e artifakteve
Scrum mbështetet në transparencë. Vendimi për të optimizuar vlerën dhe kontrollin e riskutbëhen në bazë të gjendjes të perceptuar të artifakteve. Në masën që transparenca është e plotë,këto vendime kanë një bazë të shëndoshë. Për aq sa kohë sa artifaktet nuk janë tërësisht
transparente, këto vendime mund të kenë mangësira, vlera mund të zvogëlohet dhe risku mundtë rritet.
Scrum Master duhet të punojë me Product Owner, Ekipin e Zhvillimit dhe palë të tjera tëpërfshira, për të kuptuar nëse artifaktet janë tërësisht transparente. Ekzistojnë praktika se si tëpërballesh me transparencë jo të plotë; Scrum Master duhet të ndihmojë të gjithë që të aplikojnë
praktikat e duhura në mungesë të transparencës së plotë. Një Scrum Master, duke inspektuar
artifaktet, mund të zbulojë transparencë jo të plotë, duke kuptuar patterns, duke dëgjuar nga afëratë që është thuhet, dhe duke zbuluar dallimet midis rezultateve të pritshme dhe reale.
Puna e Scrum Master është që të punojë me Ekipin Scrum dhe organizatën për të rritur
transparencën e artifakteve. Kjo punë zakonisht përfshin mësimin, bindjen dhe ndryshimin.
Transparenca nuk ndodh brenda natës, por është një rrugë.

Përkufizimi i "Përfunduar" ( Definition of “Done”)
Kur një element i Product Backlog ose Inkrementi përshkruhet si "Përfunduar", të gjithë duhet ta
kuptojnë se çfarë do të thotë "Përfunduar". Edhe pse kjo varion shumë nga një Ekip Scrum nëtjetrin, anëtarët duhet të kenë një kuptim të përbashkët se çfarë do të thotë që puna të jetë e©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 16

plotë, për t'u siguruar transparenca. Ky është përcaktimi për "Përfunduar" për Ekipin e Scrum dhepërdoret për të vlerësuar se kur puna është e plotë mbi inkrementin e produktit.
I njëjti përkufizim e udhëzon Ekipin e Zhvillimit për të ditur se sa elementë të Product Backlog
mund të zgjedhë gjatë një Sprint Planning. Qëllimi i secilit Sprint është që të japë inkremente
funksionalitetesh potencialisht të lëvrueshme që i përmbahet përkufizimit korrent të Ekipit Scrumpër "Përfunduar".
Ekipet e Zhvillimit dorëzojnë një Inkrement të funksionaliteteve të produktit në çdo Sprint. Ky
Inkrement është i përdorshëm, kështu që një Product Owner mund të zgjedhë ta lëvrojë atë. Nësepërkufizimi i "Përfunduar” për një Inkrement është pjesë e rregullave, standardeve oseudhëzimeve të organizatës së zhvillimit, të gjitha Ekipet e Scrum duhet ta ndjekin atë si minimum.
Nëse "Përfunduar" për një Inkrement nuk është pjesë e rregullave të organizatës së zhvillimit,
Ekipi i Zhvillimit, pjesë e Ekipit të Scrum-it, duhet përcaktojë një përkufizim të përshtatshëm
se çdo të thotë që produkti është “Përfunduar”. Nëse ka shumë Ekipe Scrum duke punuar në
sistemin ose inkrementin e produktit, Ekipet e zhvillimit në të gjitha Ekipet Scrum duhet tëpërcaktojnë bashkërisht përkufizimin për çfarë do të quhet e "Përfunduar".
Çdo Inkrement është shtesë për të gjitha inkrementet e mëparshme dhe të testuara tërësisht,
duke siguruar që të gjithë inkrementet punojnë së bashku.
Ndërsa Ekipet e Scrum-it maturohen, pritet që përkufizimi i tyre për "Përfunduar" të zgjerohet përtë përfshirë kritere më të rrepta për cilësi më të lartë. Çdo produkt ose sistem duhet të ketë njëpërkufizim për "Përfunduar", i cili është një standard për çdo punë të bërë në të.

Shënim i fundit
Scrum është pa pagesë dhe ofrohet në këtë Udhëzues. Rolet, artifaktet, ngjarjet dhe rregullat e
Scrum janë të pandryshueshme. Edhe pse zbatimi i vetëm disa pjesëve të Scrum është i mundur,
rezultati nuk është Scrum. Scrum ekziston vetëm në tërësinë e tij dhe funksionon mirë si një
kontenier për teknikat, metodologjitë, dhe praktika të tjera.

MirënjohjeNjerëzit
Nga mijëra njerëz që kanë kontribuar në Scrum, ne duhet të veçojmë ata që ishin thelbësorë në
dhjetë vitet e para. Së pari, ishte Jeff Sutherland i cili punonte me Jeff McKenna, dhe Ken Schwaber
duke punuar me Mike Smith dhe Chris Martin. Shumë të tjerë kontribuan në vitet që pasuan dhe
pa ndihmën e tyre Scrum nuk do të rafinohej ashtu siç është sot.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 17

Historia
Ken Schwaber dhe Jeff Sutherland bashkë-prezantuan për herë të parë Scrum në konferencënOOPSLA në 1995. Ky prezantim në thelb dokumentoi njohuritë e mësuara nga Ken dhe Jeff, duke
aplikuar Scrum, gjatë atyre pak viteve të mëparshme si dhe bëri publik prezantimin e pare formal
të Scrum.
Historia e Scrum përshkruhet në tjetër vend. Për të nderuar vendet e para ku u provua dhe u
rafinua, iu jemi mirënjohës Individual, Inc., Fidelity Investments, dhe IDX (tani GE Medical).
Udhëzuesi i Scrum dokumenton Scrum, të zhvilluar dhe mirëmbajtur për më shumë se 20 vjet nga
Jeff Sutherland dhe Ken Schwaber. Burime të tjera, japin modele, procese dhe njohuri qëplotësojnë kuadrin e Scrum (Scrum framework). E gjitha kjo, optimizon produktivitetin, vlerën,kreativitetin dhe krenarinë.

Translator Acknowledgement
Kjo guide është përkthyer nga versioni origjinal anglisht i cili është krijuar prej zhvilluesve të
specifikuar më lart. Personat që kanë kontribuar për përkthimin janë:Eleonora Qiponora.qipo@gmail.com
https://www.linkedin.com/in/eleonora-qipo-55864622/
Dorina Bebja
dorinabebja@gmail.com
https://www.linkedin.com/in/dorina-bebja-b6a0022a/

Ndryshimet ndërmjet udhëzuesve të 2016 dhe2017
1. Shtimi i një seksioni për Përdorimet e Scrum-it:
Scrum fillimisht u ndërtua për të zhvilluar dhe menaxhuar produkte. Duke filluar që nga 1990,
Scrum është përdorur gjerësisht në të gjithë botën, për të:
1. Kërkuar dhe identifikuar tregje, teknologji dhe kapacitete produktesh ku mund të
zbatohet.
2. Zhvilluar produkte dhe përmirësime.
3. Publikuar produkte dhe përmirësime të shpeshta në një ditë.
4. Zhvilluar dhe mirëmbajtur ambiente operacionale në Cloud (online, secure, on-demand)
dhe të tjera që i shërbejnë për produktet.
5. Mirëmbajtur dhe rinovuar produktet.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 18

Scrum është përdorur për të zhvilluar softuer, harduer, softuer të brendshëm, rrjete të
funksioneve të ndërveprueshme, automjete autonome, shkolla, qeveri, marketing, menaxhimin e
funksionimit të organizatave dhe pothuajse çdo gjë që ne përdorim në jetën tonë të përditshme,
si individë dhe shoqëri.
Teksa teknologjia, tregu, kompleksiteti i mjedisit dhe ndërveprimet mes tyre janë rritur me
shpejtësi, përdorimi i Scrum-it në trajtimin e këtij kompleksiteti vërtetohet çdo ditë.
Scrum është veçanërisht efektiv në transferimin e njohurive në mënyrë iterative dheinkrementale. Scrum tashmë përdoret gjerësisht për produktet, shërbimet dhe menaxhimin eorganizatës prind.
Scrum është veçanërisht efektiv në transferimin e njohurive në mënyrë iterative dheinkrementale. Scrum tashmë përdoret gjerësisht për produktet, shërbimet dhe menaxhimin eorganizatës prind.
Thelbi i Scrum është një ekip i vogël njerëzish. Ekipi individual është shumë fleksibël dhe adaptiv.
Këto pika të forta vazhdojnë të funksionojnë në një ekip, disa ekipe apo dhe rrjet ekipesh që
zhvillojnë, nxjerrin, operojnë dhe mbështesin punën dhe produktet e punës së mijëra njerëzve.
Ata bashkëpunojnë dhe ndërveprojnë përmes zhvillimit të sofistikuar të arkitekturave dhemjediseve të publikimit final (release) të synuar.
Kur fjalët "zhvillo" dhe "zhvillim" përdoren në udhëzuesin e Scrum-it, ato i referohen një pune
komplekse, siç janë ato lloje të identifikuara më sipër.

2. Ndryshim formulimi në seksionin e Scrum Master-it për tëqartësuar më mirë këtë rol. Teksti tani është:Scrum Master-i është përgjegjës për të promovuar dhe suportuar Scrum ashtu siç është ipërcaktuar në udhëzuesin Scrum. Scrum Master e realizon këtë gjë duke ndihmuar të gjithë të
kuptojnë teorinë e Scrum, praktikat, rregullat dhe vlerat.
Scrum Master-i është një lider-shërbyes për Ekipin Scrum ( Scrum Team). Scrum Master-i
ndihmon ata jashtë Ekipit Scrum të kuptojnë se cilat ndërveprime me Ekipin Scrum janëndihmëse dhe cilat jo. Scrum Master ndihmon të gjithë të ndryshojnë këto ndërveprime nëmënyrë që të maksimizojë vlerën e krijuar nga Ekipi Scrum.

3. Shtuar në seksionin Shërbimet e Scrum Master-it ndaj Product
Owner-it
Siguron që qëllimi, shtrirja dhe fusha e produktit është kuptuar nga të gjithë anëtarët e Ekipit
Scrum sa më mirë që është e mundur.
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 19

4. Përditësuar paragrafi i parë i seksionit Daily Scrum:
Daily Scrum është një event me kohëzgjatje(time boxed) 15 minuta për Ekipin e Zhvillimit. Daily
Scrum mbahet çdo ditë të Sprint-it. Në të, Ekipi i Zhvillimit planifikon punën për 24 orët eardhshme. Kjo gjë optimizon bashkëpunimin e ekipit dhe performancën duke inspektuar punën
që nga Daily Scrum i fundit dhe duke parashikuar punën që vijon në Sprint. Daily Scrum mbahetçdo ditë, në të njëjtën kohë dhe në të njëjtin vend, për të reduktuar kompleksitetin.

5. Përditësuar seksioni i Daily Scrum për të qartësuar qëllimet e Daily
Scrum duke përfshirë këtë tekst:
Struktura e mbledhjes vendoset nga Ekipi i Zhvillimit dhe mund të kryhet në mënyra të ndryshmenëse fokusohet në progresin përkundrejt Sprint Goal. Disa Ekipe zhvillimi do të përdornin
pyetjet, disa të tjera do të ishin më shumë të bazuara në diskutime. Më poshtë jepet një shembull
mbi çfarë mund të përdoret:•••Çfarë bëra dje që ndihmoi Ekipin e Zhvillimit që të arrijë Sprint Goal?
Çfarë do të bëj sot për të ndihmuar Ekipin e Zhvillimit të arrijë Sprint Goal?
A shoh ndonjë pengesë që më privon mua ose Ekipin e Zhvillimit për përmbushjen e SprintGoal?

6. Qartësime rreth kohëzgjatjeve të përcaktuara (time boxes)
Duke përdorur fjalët "më së shumti" për të hequr çdo pyetje që ngjarjet duhet të jenë me njëgjatësi të sigurtë por në vend të kësaj ato janë koha maksimale e caktuar.

7. Shtuar në seksionin e Sprint Backlog
Për të siguruar përmirësim të vazhdueshëm, përfshin të paktën një përmirësim procesi me
prioritet të lartë të identifikuar në mbledhjen e mëparshme të Retrospektivës.

8. Qartësuar më tej seksioni i Inkrementit:
Një Inkrement është një trup punësh të inspektueshem, të përfunduar që mbështet empirizmin
në fund të Sprint. Inkrementi është një hap drejt një vizioni ose synimi.

©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Faqe | 20