Ken Schwaber & Jeff Sutherland

Scrum gidas
Galutinis Scrum gidas: žaidimo taisyklės

2020 m. lapkritis

Scrum gido paskirtis
Mes sukūrėme Scrum praėjusio amžiaus paskutiniame dešimtmetyje. Mes parašėme pirmąją Scrum gido
versiją 2010 m. tam, kad padėtume visiems pasaulyje suprasti Scrum. Nuo tada mes keitėme gidąnedideliais konstruktyviais pakeitimais. Mes kartu jį atstovaujame.
Scrum gidas pateikia Scrum apibrėžimą. Kiekvienas sistemos elementas tarnauja specifiniam tikslui,būtinam įgyvendinant bendrą vertę ir rezultatus naudojant Scrum. Keičiant esmines Scrum nuostatas aridėjas, praleidžiant elementus ar nesilaikant Scrum taisyklių, gali kilti problemos ir būti apribotas Scrumnaudingumas, galimai padarant jį nenaudingu.
Mes stebime didėjantį Scrum naudojimą nuolat augančiame sudėtingame pasaulyje. Jaučiamės pagerbti
matydami, kad Scrum pritaikomas daugelyje sričių atliekant ypač sudėtingus darbus, ne tik programinės
įrangos kūrimui, nuo kurio prasidėjo Scrum. Vis plačiau plintant Scrum, juo naudojasi programinės
įrangos kūrėjai, tyrinėtojai, analitikai, mokslininkai ir kiti specialistai. Mes naudojame Scrum terminą
„kūrėjai“ ne tam, kad išskirti, o kad supaprastinti. Jei Scrum jums naudingas, galite jaustis jo kūrėjais.
Naudojantis Scrum, galima rasti, pritaikyti ir sukurti šablonus, procesus ir įžvalgas, derančias Scrum
sistemai, aprašytai šiame dokumente. Kadangi jie priklauso nuo konteksto ir ženkliai skiriasi priklausomai
nuo to, kaip naudojamas Scrum, jie nėra aprašyti Scrum gide. Tokios Scrum sistemos rėmuose taikomos
priemonės gali ženkliai skirtis, ir yra apibrėžiamos kitur.
Ken Schwaber & Jeff Sutherland, 2020 m. lapkritis© 2020 Ken Schwaber and Jeff Sutherland
This publication is 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.

1

Scrum gido paskirtis ...................................................................................................................................... 1
Scrum apibrėžimas ........................................................................................................................................ 4
Scrum teorija ................................................................................................................................................. 4
Skaidrumas ................................................................................................................................................ 4
Patikrinimas .............................................................................................................................................. 5
Pritaikymas ................................................................................................................................................ 5
Scrum vertybės ............................................................................................................................................. 5
Scrum Team .................................................................................................................................................. 6
Developers ................................................................................................................................................ 6
Product Owner .......................................................................................................................................... 7
Scrum Master ............................................................................................................................................ 7
Scrum įvykiai ................................................................................................................................................. 8
The Sprint .................................................................................................................................................. 8
Sprint Planning .......................................................................................................................................... 9
Daily Scrum ............................................................................................................................................. 10
Sprint Review .......................................................................................................................................... 10
Sprint Retrospective................................................................................................................................ 11
Scrum artefaktai .......................................................................................................................................... 11
Product Backlog ...................................................................................................................................... 11Įsipareigojimas: produkto tikslas ........................................................................................................ 12
Sprint Backlog ......................................................................................................................................... 12Įsipareigojimas: sprinto tikslas ............................................................................................................ 12
Increment ................................................................................................................................................ 13Įsipareigojimas: baigtumo apibrėžtis .................................................................................................. 13
Pabaiga ........................................................................................................................................................ 14Padėka ..................................................................................................................................................... 14Žmonės ................................................................................................................................................ 14
Scrum gido istorija .............................................................................................................................. 14Padėka vertėjams .................................................................................................................................... 14
Skirtumai taip 2017 m. ir 2020 m. Scrum gidų ........................................................................................ 15
Dar mažiau privalomų nuostatų ......................................................................................................... 152

Viena komanda, sutelkusi dėmesį į vieną produktą ........................................................................... 15Įtrauktas Produkto tikslas ................................................................................................................... 15
Vieta, skirta sprinto tikslui, baigtumo apibrėžčiai ir produkto tikslui ................................................. 15
Savivaldė virš savitvarkės .................................................................................................................... 15
Trys Sprint Planning klausimai ............................................................................................................ 15
Bendras kalbos supaprastinimas, skirtas platesnei auditorijai ........................................................... 15

3

Scrum apibrėžimas
Scrum – tai paprasta sistema, padedanti žmonėms, komandoms ir organizacijoms kurti vertę pritaikant
sprendimus sudėtingoms problemoms.
Kalbant trumpai, Scrum reikalauja, kad Scrum Master padėtų kurti aplinką, kurioje:
1.
2.
3.
4.

Product Owner sutvarko darbus sudėtingos problemos sprendimui Product Backlog‘e
Scrum Team per Sprint paverčia pasirinktus darbus į turintį vertę Increment
Scrum Team ir jos suinteresuotosios šalys patikrina rezultatus ir priima pataisymus kitam Sprint
Kartojama

Scrum – paprastas. Išbandykite jį ir nustatykite, ar jo filosofija, teorija bei struktūra padeda siekti tikslų ir
kurti vertę. Scrum sistema yra sąmoningai nepilna, apibrėžianti tik tas dalis, kurios būtinos diegiant
Scrum teoriją. Scrum sukurtas remiantis kolektyvinėmis ją naudojančių žmonių žiniomis ir įgūdžiais.
Vietoje detalių instrukcijų, Scrum gido taisyklės pateikia žmonių santykių ir bendradarbiavimo gaires.
Sistema leidžia taikyti įvairius procesus, technikas ir metodus. Scrum apgaubia egzistuojančias praktikas,arba padaro jų nereikalingumą. Scrum parodo santykinį dabartinio valdymo, aplinkos ir darbo technikų
efektyvumą, taip sudarydamas sąlygas nuolat juos gerinti.

Scrum teorija
Scrum remiasi empirizmu ir į taupumą orientuotu mąstymu. Empirizmas teigia, kad žinios yra įgaunamos
iš patirties, ir priimant sprendimus remiantis tuo, kas stebima. Į taupumą orientuotas mąstymas mažina
švaistymą ir sutelkia dėmesį į svarbiausius dalykus.
Scrum pritaiko iteracinį prieaugio požiūrį prognozių optimizavimui ir rizikos valdymui. Scrum įtraukia
grupes žmonių, kurie drauge turi visus reikalingus įgūdžius ir ekspertines žinias tam, kad atliktų darbą,bei esant poreikiui dalinasi žiniomis ar gauna jas.
Scrum apjungia keturis formalius įvykius, skirtus patikrinimui ir pritaikymui, esančius Sprint įvykio
sudėtyje. Šie įvykiai yra veiksmingus, kadangi jie įgyvendina Scrum empirinius ramsčius – skaidrumą,patikrinimą ir pritaikymą.

Skaidrumas
Besiformuojantis procesas ir darbas turi būti matomas tiems, kurie atlieka darbą, ir tiems, kurie darbą
priima. Scrum svarbūs sprendimai priimami remiantis trijų formalių artefaktų būsenos suvokimu.
Neskaidrūs artefaktai gali sukelti sprendimus, dėl kurių gali sumažėti vertė ir padidėti rizika.

4

Skaidrumas įgalina patikrinimą. Patikrinimas be skaidrumo yra klaidinantis ir sukelia nereikalingas
išlaidas.

Patikrinimas
Scrum artefaktai ir eiga sutartų tikslų atžvilgiu turi būti patikrinta dažnai ir kruopščiai tam, kad nustatyti
galimus nuokrypius ar problemas. Tam, kad padėtų atlikti patikrinimą, Scrum pateikia ciklą, kurį sudaro
penki įvykiai.
Patikrinimas įgalina pritaikymą. Patikrinimas be pritaikymo neturi prasmės. Scrum įvykiai sukurti taip,
kad provokuotų pokytį.

Pritaikymas
Jeigu bet kurio proceso rodiklio nuokrypis viršija priimtinas ribas, arba galutinis produktas yra
nepriimtinas, taikomas procesas arba kuriamas produktas turi būti pakoreguotas. Korekcija turi būti
atlikta kuo anksčiau, kad būtų sumažinti tolimesni nuokrypiai.
Pritaikymas tampa dar sudėtingesnis, kuomet įtraukti žmonės nėra įgalinti ar savivaldžiai. Tikimasi, kad
Scrum Team prisitaikys iš karto, kai tik patikrinimo metu sužinos ką nors naujo.

Scrum vertybės
Sėkmingas Scrum naudojimas priklauso nuo to, kaip žmonės vadovaujasi šiomis penkiomis vertybėmis:Įsipareigojimas, dėmesio sutelkimas, atvirumas, pagarba ir drąsa
Scrum Team įsipareigoja siekti jos tikslų ir palaikyti vienas kitą. Jų pagrindinis dėmesys sutelktas į Sprintdarbų atlikimą, kad būtų pasiektas geriausias rezultatas siekiant tikslo. Scrum Team ir jos suinteresuotosšalys atvirai aptaria darbus ir iššūkius. Scrum Team nariai gerbia vienas kitą kaip sugebančius,nepriklausomus žmones, ir yra gerbiami žmonių, su kuriais jie dirba. Scrum Team nariai turi drąsos atlikti
reikalingus darbus ir dirbti su sudėtingomis problemomis.
Šios vertybės parodo kryptį Scrum Team jos darbų, veiksmų ir elgesio atžvilgiu. Priimti sprendimai, atlikti
veiksmai ir tai, kaip Scrum yra naudojamas turi sustiprinti šias vertybes, o ne mažinti ar griauti. Scrum
Team nariai mokosi ir tyrinėja šias vertybes dirbdami su Scrum įvykiais ir artefaktais. Kuomet Scrum
Team ir žmonės, su kuriais dirbama, šias vertybes įgyvendina, Scrum skaidrumo, patikrinimo ir
pritaikymo empiriniai ramsčiai padeda kurti pasitikėjimą.

5

Scrum Team
Pagrindinis Scrum vienetas – tai nedidelė žmonių komanda, Scrum Team. Scrum Team sudaro vienas
Scrum Master, vienas Product Owner ir Developers. Scrum Team neturi mažesnių grupių ar hierarchijos.
Tai yra glaudi profesionalų grupė, susitelkusi į vieną tikslą vienu metu – produkto tikslą.
Scrum Teams yra daugiafunkcės, tai reiškia, kad jos nariai turi visus įgūdžius, reikalingus sukuriant vertę
kiekvieną Sprint. Jos taip pat yra ir savivaldės, vadinasi, savarankiškai nusprendžia, kas ką daro, kada ir
kaip.
Scrum Team yra pakankamai maža, kad išliktų lanksti, ir pakankamai didelė, kad galėtų atlikti ženklų
darbą Sprint metu, paprastai 10 ar mažiau žmonių. Bendru atveju, mes atradome, kad mažesnės
komandos geriau komunikuoja ir yra produktyvesnės. Jeigu Scrum Teams pasidaro per didelės, josturėtų apsvarstyti galimybę reorganizuotis į keletą glaudesnių Scrum Teams, kur kiekviena sutelkiadėmesį į tą patį produktą. Todėl jos turėtų turėti tą patį produkto tikslą, Product Backlog ir Product
Owner.
Scrum Teams yra atsakinga už visus su produktu susijusius veiksmus, pradedant nuo bendradarbiavimo
su suinteresuotosiomis šalimis, patikrinimo, priežiūros, naudojimo, eksperimentų, tyrimų ir kūrimo, bei
bet kas kita, kas gali būti reikalinga. Organizacijos sukuria Scrum Teams struktūrą ir įgalioja jas pačias
organizuoti ir valdyti savo darbą. Darbas Sprints tvariu tempu gerina Scrum Team dėmesio sutelkimą ir
darnumą.
Visa Scrum Team yra atsakinga už vertingo ir naudingo Increment sukūrimą kiekviename Sprint. Scrum
apibrėžia tris specifines Scrum Team atsakomybės sritis: Developers, Product Owner ir Scrum Master.

Developers
Developers – tai Scrum Team nariai, įsipareigoję sukurti bet kurį tinkamo naudoti Increment aspektą per
kiekvieną Sprint.
Developers reikalingi specifiniai įgūdžiai paprastai yra platūs ir skirsis priklausomai nuo darbo srities. Bet
kuriuo atveju, Developers visada yra atsakingi už:●●●●

Sprint Backlog, t.y. Sprint plano sukūrimą
Kokybės, atitinkančios baigtumo apibrėžtį, diegimą
Kasdienį jų plano pritaikymą siekiant sprinto tikslo, ir
Tarpusavio atsakomybę kaip profesionalai

6Product Owner
Product Owner yra atsakingas už maksimalią Scrum Team atliktu darbu sukurto produkto vertę. Kaip tai
atliekama, gali ženkliai skirtis priklausomai nuo organizacijos, Scrum Teams ir individų.
Product Owner taip pat yra atsakingas už efektyvų Product Backlog valdymą, apimantį:●●●●Produkto tikslo sukūrimą ir aiškią jo komunikaciją
Product Backlog įrašų sukūrimą ir aiškią jų komunikaciją
Product Backlog įrašų sutvarkymą, irUžtikrinimą, kad Product Backlog yra skaidrus, matomas ir suprantamas

Product Owner aukščiau išvardintą darbą gali atlikti pats arba pavesti šią atsakomybę kitiems.
Nepriklausomai nuo to, atsakingas lieka Product Owner.
Tam, kad Product Owners sėkmingai atliktų savo funkcijas, visa organizacija turi gerbti jų sprendimus. Tie
sprendimai matomi Product Backlog turinyje ir eiliškume, bei patikrinant Increment per Sprint Review.
Product Owner – vienas asmuo, o ne grupė. Product Owner Product Backlog gali atstovauti daugelio
suinteresuotų asmenų lūkesčius. Norintys pakeisti Product Backlog gali tai padaryti įtikindami Product
Owner.

Scrum MasterScrum Master yra atsakingas už Scrum diegimą taip, kaip apibrėžta Scrum gide. Jie tai pasiekia padėdami
kiekvienam suprasti Scrum teoriją ir praktiką, tiek Scrum Team, tiek organizacijoje.
Scrum Master yra atsakingas už Scrum Team efektyvumą. Jie tai pasiekia padedami Scrum Team gerinti
savo praktikas Scrum sistemos rėmuose.
Scrum Masters yra tikrieji lyderiai, tarnaujantys Scrum Team ir visai organizacijai.
Scrum Master padeda Scrum Team skirtingais būdais, įskaitant:●●●●

Mokydamas komandos narius būti savivaldžiais ir daugiafunkciaisPadėdamas Scrum Team telkti dėmesį į aukštos vertės Increments, atitinkantį baigtumo
apibrėžtį, kūrimą
Inicijuodamas kliūčių, kylančių Scrum Team dirbant, pašalinimą, irUžtikrindamas, kad visi Scrum įvykiai įvyksta ir yra pozityvūs, produktyvūs ir išlaikant trukmės
apribojimą

Scrum Master padeda Product Owner skirtingais būdais, įskaitant:

7

●
●
●
●

Padėdamas rasti metodus efektyviai nustatyti produkto tikslą ir valdyti Product Backlog
Padėdamas Scrum Team suprasti aiškių ir glaustų Product Backlog įrašų naudą
Padėdamas sukurti empirinį produkto planavimą sudėtingoje aplinkoje, ir
Pagal poreikį dalyvaudamas bendradarbiavime su suinteresuotomis šalimis

Scrum Master padeda organizacijai skirtingais būdais, įskaitant:●●●●

Vesdamas ir mokydamas organizaciją, kai joje diegiamas Scrum
Planuodamas ir patardamas apie Scrum diegimus organizacijojePadėdamas darbuotojams ir suinteresuotosioms šalims suprasti ir naudoti empirinį požiūrį įsudėtingą darbą;Šalindamas kliūtis tarp suinteresuotųjų šalių ir Scrum Teams

Scrum įvykiai
Visi kiti įvykiai patenka į Sprint. Kiekvienas Scrum įvykis yra formali galimybė patikrinti ir pritaikyti Scrum
artefaktus. Šie įvykiai specialiai sukurti tam, kad būtų užtikrintas reikalingas skaidrumas. Negebėjimas
tinkamai naudoti bet kurį įvykį tampa prarasta galimybe pasinaudoti patikrinimu ir pritaikymu. Scrum
naudojami įvykiai įdiegia reguliarumą ir minimizuoja Scrum neapibrėžtų susitikimų poreikį. Geriausia kai
visi įvykiai vyksta tuo pačiu metu ir toje pačioje vietoje, kad būtų sumažintas sudėtingumas.

The Sprint
Sprints – tai Scrum pulsas, kuriuose idėjos paverčiamos verte.
Siekiant pastovumo, jie yra fiksuotos trukmės – vieno mėnesio arba trumpesni. Naujas Sprint prasideda
nedelsiant po to, kai užbaigiamas ankstesnis.
Visas darbas, reikalingas pasiekti produkto tikslą, įskaitant Sprint Planning, Daily Scrums, Sprint Review,
ir Sprint Retrospective, vyksta per Sprints.
Sprint metu:●●●●

Neleidžiami jokie pakeitimai, kurie galėtų kelti grėsmę sprinto tiksluiNemažinama kokybė
Product Backlog esant poreikiui tinkamai tvarkomas, ir
Apimtis gali būti patikslinta ir papildomai derinama su Product Owner, kuomet sužinoma
daugiau

Sprints kuria numatymo galimybę, panaudojant progreso patikrinimą ir pritaikymą bei palyginant su
produkto tikslu bent kartą per kalendorinį mėnesį. Jeigu Sprint trukmė per ilga, sprinto tikslas gali tapti
8klaidinančiu, išaugti sudėtingumas ir rizika. Trumpesni Sprints gali būti naudojami siekiant sukurti
daugiau mokymosi ciklų, dėl trumpesnių intervalų siekiant sumažinti sąnaudų ir pastangų riziką.
Kiekvienas Sprint gali būti laikomas trumpu projektu.
Eigos prognozei egzistuoja įvairios praktikos, tokios kaip eigos, prieaugio ar kaupiamosios diagramos.
Nors jų efektyvumas įrodytas, tai nesumažina empirizmo svarbos. Sudėtingose aplinkose nežinoma, kasnutiks vėliau. Tik tai, kas jau įvyko, gali būti naudojama kaip pagrindas priimti ateities sprendimus.
Sprint gali būti atšauktas, jeigu sprinto tikslas tampa nebereikalingu. Tik Product Owner turi įgaliojimus
atšaukti Sprint.

Sprint Planning
Sprint Planning pradeda Sprint nustatydamas darbą, kuris turi būti atliktas per Sprint. Šis planas
sukuriamas bendru visos Scrum Team darbu.
Product Owner užtikrina, kad dalyviai yra pasirengę diskutuoti svarbiausius Product Backlog įrašus ir kaip
jie siejasi su produkto tikslu. Scrum Team taip pat gali pakviesti dalyvauti Sprint Planning kitus asmenistam, kad šie patartų.
Sprint Planning atsako į tokius klausimus:

Pirmas klausimas: kodėl šis Sprint vertingas?
Product Owner pasiūlo, kaip šiame Sprint galima padidinti produkto vertę ir naudingumą. Tuomet visa
Scrum Team bendradarbiauja tam, kad nustatyti sprinto tikslą, nusakantį, kodėl Sprint yra vertingas
suinteresuotiems asmenims. Sprinto tikslas turi būti užbaigtas iki Sprint Planning pabaigos.

Antras klausimas: kas gali būti atlikta šiame Sprint?
Diskutuodami su Product Owner, Developers pasirenka įrašus iš Product Backlog tam, kad įtraukti juos įšį Sprint. Proceso metu Scrum Team gali tvarkyti šiuo įrašus, taip gerinant supratimą ir pasitikėjimą.
Pasirinkimas, kiek gali būti užbaigta per Sprint, gali būti sudėtingas. Bet kuriuo atveju, kuo daugiau
Developers žino apie jų darbo spartą praeityje, jų ateinančio laikotarpio pajėgumus ir jų baigties
apibrėžimą, tuo labiau jie pasitikės savo Sprint prognozėmis.

Trečias klausimas: kaip bus atliktas pasirinktas darbas?
Kiekvienam pasirinktam Product Backlog įrašui, Developers planuoja darbą, reikalingą sukurti Increment,
kuris atitinka baigtumo apibrėžimą. Tai dažnai atliekama padalinant Product Backlog įrašus į vienos
dienos ar mažesnės trukmės užduotis. Tik Developers pasirenka kaip tai padaryti. Niekas jiems
nenurodo, kaip Product Backlog įrašus paversti parengtais vertės Increments.

9Sprinto tikslas, Sprint pasirinkti Product Backlog įrašai kartu su jų kūrimo ir išleidimo planu vadinami
Sprint Backlog.
Sprint Planning turi aštuonių valandų trukmės apribojimą vieno mėnesio trukmės Sprint. Trumpesniems
sprintams jo trukmė atitinkamai trumpesnė.

Daily Scrum
Daily Scrum paskirtis – patikrinti eigą sprinto tikslo atžvilgiu ir jeigu reikalinga pritaikyti Sprint Backlog,
patikslinant artimiausius suplanuotus darbus.
Daily Scrum – 15 minučių trukmės Scrum Team Developers įvykis. Tam, kad būtų sumažintassudėtingumas, jis vyksta kiekvieną Sprint darbo dieną tuo pačiu laiku ir toje pačioje vietoje. Jeigu Product
Owner ar Scrum Master aktyviai dirba su Sprint Backlog irašais, jie dalyvauja kaip Developers.
Developers gali pasirinkti bet kurią pageidaujamą struktūrą ar technikas, tol, kol jų Daily Scrum sutelkiadėmesį į eigą sprinto tikslo atžvilgiu ir sukuria įvykdomą planą kitai darbo dienai. Tai padeda telktidėmesį ir gerinti savivaldą.
Daily Scrums gerina komunikaciją, identifikuoja ir pašalina kūrimo kliūtis, pabrėžia ir skatina greitą
sprendimų priėmimą bei dėl to panaikina kitų susitikimų poreikį.
Developers leidžiama pataisyti savo planą ne tik Daily Scrum metu. Jie dažnai susitinka dienos eigoje
detalesnėms diskusijoms apie likusio Sprint darbo pritaikymą arba perplanavimą.

Sprint Review
Sprint Review tikslas yra patikrinti Sprint rezultatus ir apibrėžti pritaikymus ateityje. Scrum Team parodo
savo darbo rezultatus svarbiausiems suinteresuotiesiems asmenims ir aptaria eigą produkto tiksloatžvilgiu.
Įvykio metu Scrum Team ir suinteresuotieji asmenys peržiūri kas buvo atlikta Sprint metu ir kas pasikeitė
jų aplinkose. Remiantis šia informacija, dalyviai aptaria, kas turėtų būti atlikta toliau. Tam, kad atitiktų
naujas galimybes, gali būti peržiūrėtas ir visas Product Backlog. Sprint Review yra darbinis susitikimas ir
Scrum Team turėtų vengti apriboti jį kaip pristatymą.
Sprint Review yra priešpaskutinis Sprint įvykis, jis turi keturių valandų trukmės apribojimą vieno mėnesio
trukmės sprintui. Trumpesnių sprintų įvykiui paprastai skiriama mažiau laiko.

10

Sprint Retrospective
Sprint Retrospective paskirtis yra suplanuoti būdus, kaip pagerinti kokybę ir efektyvumą.
Scrum Team patikrina, kaip vyko pastarasis Sprint žmonių, santykių, procesų, įrankių ir jų baigtumo
apibrėžties atžvilgiu. Patikrinti elementai dažnai gali skirtis, priklausomai nuo darbo dalykinės srities.
Nustatomos prielaidos, leidusios jiems nuklysti, ir ištiriamos jų priežastys. Scrum Team aptaria, kas vykosėkmingai Sprint metu, su kokiomis problemomis susidūrė ir kaip tas problemas išsprendė (arba
neišsprendė).
Scrum Team identifikuoja naudingiausius pakeitimus, galinčius pagerinti jos efektyvumą. Pagerinimai,turėsiantys didžiausią įtaką, įgyvendinami kaip galima greičiau. Jie netgi gali būti pridėti prie Sprint
Backlog kitam Sprint.
Sprint Retrospective užbaigia Sprint. Jis turi trijų valandų trukmės apribojimą vieno mėnesio trukmės
sprintui. Trumpesnių sprintų įvykiui paprastai skiriama mažiau laiko.

Scrum artefaktai
Scrum artefaktai parodo darbą arba vertę. Jie yra sukurti tam, kad būtų maksimizuotas svarbiausios
informacijos skaidrumas. Todėl kiekvienas juos tikrinantis turi tokį patį pagrindą pritaikymui.
Kiekvieną artefaktą sudaro įsipareigojimas užtikrinti, kad jis pateikia informaciją, kuri didina skaidrumą irsutelkia dėmesį į eigą, kurią matuoja:●●●

Product Backlog atveju tai yra produkto tikslas
Sprint Backlog atveju tai yra sprinto tikslas
Increment atveju tai yra baigtumo apibrėžtisŠie įsipareigojimai egzistuoja tam, kad sustiprintų empirizmą bei Scrum vertybes, skirtas Scrum Team ir
jos suinteresuotiesiems asmenims.

Product Backlog
Product Backlog – tai nuolat besiformuojantis, sutvarkytas visko, kas reikalinga gerinti produktą, sąrašas.
Tai – vienintelis darbo, kurį vykdo Scrum Team, šaltinis.
Product Backlog įrašai, kurie gali būti Scrum Team „užbaigti“ vieno Sprint rėmuose, laikomi „paruoštais“tam, kad būtų pasirenkami Sprint Planning susitikimo metu. Jie paprastai tampa tokie aiškūs atliekant
detalizavimo ir tvarkymo veiksmus. Product Backlog tvarkymas – tai veikla, kuomet Product Backlog
įrašai yra toliau detalizuojami ir apibrėžiami, padalinant į mažesnius ir tikslesnius įrašus. Tai – nuolatinis

11

procesas, kurio metu pridedamos detalės, tokios, kaip aprašymas, eilės tvarka ir įvertis. Atributai dažnai
skiriasi priklausomai nuo darbo srities.
Už įverčius atsako Developers, kurie atliks darbus. Product Owner gali daryti įtaką Developerspadėdamas suprasti ir pasirinkti alternatyvas.

Įsipareigojimas: produkto tikslas
Produkto tikslas apibrėžia būsimą produkto būseną, kuri tarnauja kaip tikslas Scrum Team. Produkto
tikslas randasi Product Backlog. Likęs Product Backlog vystomas tam, kad apibrėžtų „kas“ padės
įgyvendinti tą produkto tikslą.
Produktas yra priemonė sukurti vertę. Jis turi aiškias ribas, žinomus suinteresuotuosius asmenis,
gerai apibrėžtus vartotojus ar klientus. Produktas gali būti paslauga, fizinis produktas ar kas nors
abstraktesnio.
Produkto tikslas – tai ilgalaikis Scrum Team tikslas. Jie privalo pasiekti (arba atsisakyti pasiekti) vieną
tikslą prieš imantis kito.

Sprint Backlog
Sprint Backlog sudaro sprinto tikslas (kodėl), rinkinys Product Backlog įrašų pasirinktų Sprint (kas) beiįvykdomas Increment kūrimo ir išleidimo planas (kaip).
Sprint Backlog yra planas, kurį Developers kuria sau. Tai yra gerai matomas darbo, kurį Developers
planuoja užbaigti Sprint metu siekiant sprinto tikslo, atvaizdavimas realiu laiku. Atitinkamai, Sprint
Backlog yra atnaujinamas Sprint eigoje, kuomet sužinoma daugiau. Jis turi būti pakankamai detalus tam,kad jie galėtų patikrinti savo eigą per Daily Scrum.

Įsipareigojimas: sprinto tikslas
Sprinto tikslas – tai vienintelis tikslas, kurio bus siekiama Sprint metu. Nežiūrint į tai, kad sprinto tikslas
yra Developers įsipareigojimas, jis suteikia jiems lankstumo, koks tiksliai darbas reikalingas atlikti kad jį
pasiekti. Sprinto tikslas taip pat kuria sąsajas ir sutelkia dėmesį, padrąsindamas Scrum Team dirbti kartu,
o ne prie skirtingų iniciatyvų.
Sprinto tikslas sukuriamas per Sprint Planning įvykį ir tada pridedamas prie Sprint Backlog. Developers
dirbdami Sprint metu, nuolat turi omenyje sprinto tikslą. Jeigu darbas pasirodo esąs skirtingas nuo to, ko
jie tikėjosi, jie Sprint metu bendradarbiauja su Product Owner ir derasi dėl Sprint Backlog apimties,
nedarydami įtakos sprinto tikslui.

12Increment
Increment – tai konkretus tarpinis žingsnis link produkto tikslo. Kiekvienas Increment papildo visus
ankstesnius Increment ir yra kruopščiai ištestuotas, taip užtikrinant, kad visi Increment veikia kartu.
Siekiant sukurti vertę, Increment turi būti tinkamas naudoti.
Sprint metu gali būti sukurti daugelis Increment. Increments visuma pristatoma per Sprint Review taippalaikant empirizmą. Vis dėlto, Increment gali būti pristatomas suinteresuotiesiems asmenims ir
nepasibaigus Sprint. Todėl Sprint Review niekada neturi būti vertinama kaip vieninteliai vartai, skirti
išleisti vertę.
Darbas, neatitinkantis baigtumo apibrėžties reikalavimų, nelaikomas Increment dalimi.

Įsipareigojimas: baigtumo apibrėžtis
Baigtumo apibrėžtis – tai formalus Increment būsenos aprašymas, kada jis atitinka produktui nustatytus
kokybinius reikalavimus.
Increment atsiranda tada, kai Product Backlog įrašas pradeda atitikti baigtumo apibrėžties reikalavimus.
Baigtumo apibrėžtis kuria skaidrumą pateikdama kiekvienam vienodą supratimą, kas vadinama užbaigtu
darbu kaip Increment dalimi. Jeigu Product Backlog įrašas neatitinka baigtumo apibrėžties reikalavimų,jis negali būti išleidžiamas ar net pristatomas per Sprint Review. Vietoje to, jis grįžta į Product Backlog
tolimesniam vertinimui.
Jeigu Increment baigtumo apibrėžtis yra organizacijos standartų dalis, visos Scrum Teams privalo jų
laikytis kaip minimalių reikalavimų. Jeigu nėra tokio organizacijos standarto, Scrum Teams privalo
nustatyti produktą atitinkančią baigtumo apibrėžtį.
Iš Developers reikalaujama laikytis baigtumo apibrėžties reikalavimų. Jeigu produktą drauge kuria
keletas Scrum Teams, jos visos baigtumo apibrėžtį turi nustatyti ir jo laikytis drauge.

13

Pabaiga
Scrum yra nemokamas ir pateikiamas šiame gide. Čia pateikiama Scrum sistema yra nekeičiama. Nors
galima taikyti tik atskiras Scrum dalis, toks pritaikymas nelaikomas Scrum. Scrum egzistuoja tik visumoje,
tuo pačiu jis gerai veikia kartu su kitomis technikomis, metodikomis ir praktikomis.

PadėkaŽmonėsTarp tūkstančių žmonių, kurie įnešė indėlį į Scrum vystymą, mes turime išskirti tuos, kurie buvo svarbūspradžioje: Jeff Sutherland, dirbusį drauge su Jeff McKenna ir John Scumniotales, ir Ken Schwaber, dirbusį
su Mike Smith ir Chris Martin, ir juos visus dirbusius drauge. Daugelis kitų vėlesniais metais įnešė savoindėlį ir be jų pagalbos Scrum nebūtų toks ištobulintas, koks yra dabar.

Scrum gido istorija
Ken Schwaber ir Jeff Sutherland pirmą kartą Scrum pristatė OOPSLA konferencijoje 1995 m. Šis
pristatymas iš esmės dokumentavo žinias, kurias Ken ir Jeff įgijo per ankstesnius keletą metų ir viešai
pristatė kaip pirmąjį formalų Scrum apibrėžimą.
Scrum gidas aprašo Scrum taip, kaip jį sukūrė ir vystė per daugiau kaip trisdešimt metų Jeff Sutherland ir
Ken Schwaber. Kiti šaltiniai pateikia šablonus, procesus ir įžvalgas, papildančius Scrum sistemą. Tai gali
pagerinti produktyvumą, vertę, kūrybingumą ir pasitenkinimą rezultatais.
Išsami Scrum istorija aprašyta kitur. Pagerbdami pirmąsias įmones, kuriose Scrum buvo išbandytas irįrodytas, mes išskiriame Individual, Inc., Newspage, Fidelity Investments ir IDX (dabar – GE Medical).

Padėka vertėjams
Šis gidas buvo išverstas iš originalios versijos anglų kalba, pateiktos aukščiau paminėtų kūrėjų. Prievertimo prisidėjo Darius Juostas, Monika Juostaitė ir Lina Juostienė.
Kontaktai:● El. paštas darius.juostas@gmail.com● LinkedIn https://www.linkedin.com/in/darius‐juostas‐pmp‐csp‐b31b0622

14

Skirtumai taip 2017 m. ir 2020 m. Scrum gidųDar mažiau privalomų nuostatų
Bėgant metams, Scrum gidas pradėjo teikti vis daugiau privalomų reikalavimų. 2020 m. versija siekiagrąžinti Scrum kaip minimaliai pakankamą sistemą, atsisakant privalomų nuostatų arba jas sušvelninant,pvz., atsisakant privalomų Daily Scrum klausimų, sumažinant reikalavimus Product Backlog įrašų
atributams, Retro įrašams Product Backlog, sutrumpinant Sprint atšaukimo skyrių, ir t.t.

Viena komanda, sutelkusi dėmesį į vieną produktą
Tikslas buvo pašalinti atskiros komandos jos viduje sąvoką, kas sukeldavo „tarpininko“ ar „mes ir jie“
santykį tarp Product Owner ir kūrimo komandos. Dabar tai yra viena Scrum Team, sutelkusi dėmesį į tąpatį tikslą, kurią sudaro trys atsakomybės sritys: Product Owner, Scrum Master ir Developers.

Įtrauktas Produkto tikslas
Į 2020 m. Scrum gidą įtraukta produkto tikslo sąvoka, leidžianti Scrum Team sutelkti dėmesį į didesnį
vertingą tikslą. Kiekvienas Sprint turi vesti produktą artyn link bendro produkto tikslo.

Vieta, skirta sprinto tikslui, baigtumo apibrėžčiai ir produkto tikslui
Ankstesni Scrum gidai apibrėžė sprinto tikslą ir baigtumo apibrėžtį iš tiesų nesuteikdami jiems tapatybės.
Jie nebuvo tikri artefaktai, greičiau kažkas susijusio su artefaktais. Pridėjus produkto tikslą, 2020 m.
versija pateikia daugiau aiškumo. Kiekvienas iš šių trijų artefaktų dabar turi „įsipareigojimus“ jiems.
Product Backlog atveju tai produkto tikslas, Sprint Backlog – sprinto tikslas, o Increment – baigtumo
apibrėžtis (dabar be kabučių). Jie suteikia daugiau skaidrumo ir sutelkia dėmesį į kiekvieno artefakto
eigą.

Savivaldė virš savitvarkės
Ankstesni Scrum gidai nurodydavo, kad kūrimo komandos yra savitvarkės, renkasi kas ir kaip atliekadarbą. Fokusuojantis į Scrum Team, 2020 m. versija pabrėžia savivaldžias Scrum Teams, kurios renkasi
kas, kaip ir kokį darbą dirbs.

Trys Sprint Planning klausimai
Papildomai prie Sprint Planning klausimų „ką“ ir „kaip“, 2020 m. Scrum gido versija pabrėžia trečią
klausimą – „kodėl“, susijusį su sprinto tikslu.

Bendras kalbos supaprastinimas, skirtas platesnei auditorijai
2020 m. Scrum gidas atsisako perteklinių ir sudėtingų sakinių, taip pat pašalindamas visas likusias
nuorodas į IT darbus (pvz., testavimas, sistema, dizainas, reikalavimai ir t.t.). Scrum gidą šiuo metu
sudaro mažiau negu 13 puslapių.

15