Kens Švābers & Džefs Sazerlands

Scrum Ceļvedis
Visaptverošs Scrum ceļvedis: Spēles noteikumi

Novembris 2020

Scrum ceļveža mērķis
Mēs izstrādājām Scrum 90‐to gadu sākumā. Pirmo Scrum ceļveža versiju mēs uzrakstījām 2010. gadā, lai
palīdzētu cilvēkiem visā pasaulē saprast Scrum. Kopš tā laika esam attīstījuši Scrum ceļvedi ar maziem,
funkcionāliem uzlabojumiem. Mēs stāvam aiz tā kopā.
Scrum ceļvedis satur Scrum definīciju. Katrs ietvara elements kalpo noteiktam mērķim, kas ir būtisks
kopējai vērtībai un Scrum sasniedzamajiem rezultātiem. Būtisku Scrum noteikumu vai ideju mainīšana,vienumu izlaišana vai Scrum noteikumu neievērošana var radīt problēmas un mazināt Scrum lietderību,
iespējams, padarot to bezjēdzīgu.
Mēs sekojam kā pieaug Scrum izmantošana arvien pieaugošajā sarežģītajā pasaulē. Mēs jūtamies
pagodināti redzēt, ka Scrum tiek piemērots daudzām sarežģīta darba jomām, ne tikai programmatūrasizstrādei, ar kuru Scrum sākās. Par cik Scrum kļūst arvien izplatītāks, to izmanto programmatūrasizstrādātāji, pētnieki, analītiķi, zinātnieki un citi profesionāļi. Terminu "izstrādātāji" Scrum mēsizmantojam nevis citu personu izslēgšanai, bet vienkāršošanai. Ja jūs gūstat vērtību no Scrum, tad varat
sevi uzskatīt par pieskaitāmu pie “izstrādātājiem”.
Izmantojot Scrum, var tikt izveidoti un pielietoti dažādi šabloni, procesi, kas nav pretrunā ar Scrum
ietvaru, kāds tas ir aprakstīts šajā dokumentā. Tā kā tie var ļoti atšķirties viens no otra un ir atkarīgi nokonteksta, kurā tiek pielietots Scrum, tad to apraksti ir ārpus Scrum ceļveža. Scrum ietvara izmantotāspieejas var būt ļoti dažādas un ir aprakstītas citur.

Kens Švābers & Džefs Sazerlands, 2020. Novembris© 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 ceļveža mērķis .................................................................................................................................... 1
Scrum Definīcija ............................................................................................................................................ 4
Scrum Teorija ................................................................................................................................................ 4
Caurskatāmība .......................................................................................................................................... 4
Pārbaude ................................................................................................................................................... 5Pielāgošana ............................................................................................................................................... 5
Scrum Vērtības .............................................................................................................................................. 5
Scrum Team .................................................................................................................................................. 5
Developers ................................................................................................................................................ 6
Product Owner .......................................................................................................................................... 6
Scrum Master ............................................................................................................................................ 7
Scrum Ceremonijas ....................................................................................................................................... 8
The Sprint .................................................................................................................................................. 8
Sprint Planning .......................................................................................................................................... 8
Daily Scrum ............................................................................................................................................... 9
Sprint Review .......................................................................................................................................... 10
Sprint Retrospective................................................................................................................................ 10
Scrum Artefakti ........................................................................................................................................... 10
Product Backlog ...................................................................................................................................... 11Apņemšanās: Product Goal ................................................................................................................. 11
Sprint Backlog ......................................................................................................................................... 11Apņemšanās: Sprint Goal .................................................................................................................... 12
Increment ................................................................................................................................................ 12Apņemšanās: Definition of Done ........................................................................................................ 12
Noslēgums................................................................................................................................................... 13
Pateicības ................................................................................................................................................ 13
Cilvēkiem ............................................................................................................................................. 13
Scrum Ceļveža Vēsture........................................................................................................................ 13
Tulkotāji .................................................................................................................................................. 132020 Scrum ceļvedī ieviestās izmaiņas attiecībā pret 2017 Scrum ceļvedi ........................................ 14
Mazāk noteikumus aprakstošs............................................................................................................ 142

Viena komanda, Koncentrējas uz vienu produktu .............................................................................. 14
Ieviests Product Goal .......................................................................................................................... 14
Sprint Goal, Definition of Done un Product Goal vieta ....................................................................... 14
Pašorganizētu vietā Pašpārvaldošas ................................................................................................... 14
Trīs Sprint Planning tēmas .................................................................................................................. 14
Vienkāršota valoda lielākas auditorijas sasniegšanai ......................................................................... 14

3

Scrum Definīcija
Scrum ir ietvars, kas palīdz cilvēkiem, komandām un organizācijām radīt vērtību, izmantojot adaptīvus
risinājumus, sarežģītām problēmām.
Īsumā, Scrum ir nepieciešams Scrum Master, lai veicinātu vidi, kurā:
1.
2.
3.
4.

Product Owner, izmantojot Product Backlog, prioritizē darbus kompleksai problēmai.
Scrum team pārvērš izvēlētos darbus Sprint ietvaros par Increment, kas nes vērtību.
Scrum team un iesaistītās puses izvērtē rezultātus un veic pielāgojumus nākošajam Sprint.
Atkārto

Scrum ir vienkāršs. Mēģiniet to piemērot tādu, kāds tas ir, un izlemiet, vai tā filozofija, teorija un
struktūra palīdz sasniegt vēlamos mērķus un radīt vērtību. Scrum ietvars nav gatava sistēma un nosaka
tikai tās daļas, kas nepieciešamas Scrum teorijas ieviešanai. Scrum pamatā ir cilvēku pieredze, kuri toizmanto. Tā vietā, lai sniegtu cilvēkiem detalizētas instrukcijas, Scrum noteikumi vada viņu attiecības un
mijiedarbību.
Ietvarā var izmantot dažādus procesus, tehnikas un metodes. Scrum apkopo esošo praksi vai uzsver tobezjēdzību. Scrum padara redzamu pašreizējās vadības, vides un darba metožu relatīvo efektivitāti, lai
varētu veikt uzlabojumus.

Scrum Teorija
Scrum pamatā ir empīrisms un Lean (projektu vadības metodes) domāšana. Empīrisms paredz, kazināšanas tiek iegūtas caur pieredzi un lēmumi tiek pieņemti balstoties uz zināmo (faktiem). Lean
domāšanas veids samazina resursu izniekošanu un fokusējas uz svarīgāko.
Scrum paredz iteratīvas, inkrementālas pieejas pielietošanu risku pārvaldībai un paredzamības
uzlabošanai. Scrum apvieno grupās cilvēkus, kuriem kolektīvi piemīt visas nepieciešamās prasmes unzināšanas, lai darītu darbu un dalītos ar zināšanām vai apgūtu jaunas, ja tas nepieciešams.
Scrum Sprint laikā tiek iekļautas četras formālas ceremonijas, lai veiktu pārbaudes un pielāgošanu. Šīs
ceremonijas darbojas, jo tās īsteno empīriskos Scrum caurskatāmības, pārbaudes un pielāgošanas pilārus

Caurskatāmība
Tekošajiem darbiem un procesiem jābūt caurskatāmiem gan priekš tiem, kas veic šo darbu, gan tiem, kaspieņem darba rezultātu. Izmantojot Scrum, svarīgi lēmumi tiek pieņemti balstoties uz šo trīs formāloartefaktu stāvokli. Artefakti ar vāju caurskatāmību var novest pie lēmumiem, kas samazina vērtību unpalielina riskus.
Caurskatāmība ļauj veikt pārbaudes. Pārbaudes bez caurskatāmības ir maldinošas un bezjēdzīgas.

4

PārbaudeBieži un rūpīgi jāpārbauda Scrum artefakti un progress virzībā uz definētajiem mērķiem, lai atklātu
potenciāli nevēlamas novirzes vai problēmas. Lai atvieglotu pārbaudes, Scrum nodrošina piecas
ceremonijas.
Pārbaude ļauj veikt pielāgošanu. Pārbaude bez pielāgošanas ir uzskatāma par bezjēdzīgu. Scrum
ceremonijas ir paredzētas, lai ierosinātu izmaiņas.

Pielāgošana
Ja kādi no procesa aspektiem ir novirzījušies ārpus pieļaujamās normas vai gala produkts ir
nepieņemams, tad jāpielāgo process vai produkts. Pielāgošana jāveic pēc iespējas ātrāk, lai samazinātu
turpmākas novirzes.
Pielāgošana kļūst grūtāka, ja iesaistītie cilvēki nav pilnvaroti to darīt vai nav spējīgi būt pašpārvaldoši.
Tiek paredzēts, ka Scrum Team pielāgo (procesu vai produktu) tiklīdz pārbaudēs ir uzzinājusi ko jaunu.

Scrum Vērtības
Veiksmīga Scrum izmantošana ir atkarīga no cilvēku prasmes ievērot piecas vērtības:Apņemšanās, Koncentrēšanās, Atvērtība, Cieņa un Drosme
Scrum Team apņemas sasniegt mērķus un palīdzēt viens otram. Viņu primārais fokuss ir uz Sprint
darbiem, lai sasniegtu labāko iespējamo progresu šo mērķu sasniegšanā. Scrum Team un iesaistītās
puses ir atklātas par veicamajiem darbiem un izaicinājumiem. Scrum Team locekļi ciena viens otru kāspējīgus un neatkarīgus cilvēkus, tāpat viņus respektē arī tie ar ko viņi strādā. Scrum Team ir drosme
rīkoties un strādāt pie sarežģītām problēmām.
Šīs vērtības dod Scrum Team norādījumus viņu darbam, rīcībai un uzvedībai. Pieņemtajiem lēmumiem,
veiktajiem soļiem un Scrum izmantošanai, vajadzētu nostiprināt šīs vērtības, nevis tās mazināt vai graut.
Scrum Team dalībnieki mācās un apgūst šīs vērtības, strādājot ar Scrum ceremonijām un artefaktiem.
Kad Scrum Team un cilvēki, ar kuriem viņi strādā, apgūst šīs vērtības, empīriskie Scrum caurskatāmības,pārbaudes un pielāgošanas pīlāri atdzīvojas, veidojot uzticību.

Scrum Team
Scrum pamatvienība ir neliela cilvēku komanda ‐ Scrum Team. Scrum Team sastāv no viena Scrum
Master, viena Product Owner un no Developers. Scrum Team nav apakškomandu vai hierarhijas. Tā irvienota profesionāļu vienība, kas vienlaikus koncentrējas uz vienu mērķi – Product Goal.

5

Scrum Team ir multi‐funkcionālas, kas nozīmē, ka dalībniekiem ir visas prasmes, kas nepieciešamas, lai
radītu vērtību katrā Sprint. Tās ir arī pašpārvaldošas, kas nozīmē, ka komanda pati iekšēji vienojas, ko unkas, kad un kā dara.
Scrum Team ir pietiekami maza, lai būtu izveicīga un pietiekami liela, lai paveiktu nozīmīgu darbu Sprint
ietvaros, parasti 10 vai mazāk cilvēku. Kopumā, mēs esam secinājuši, ka mazākās komandās ir labākakomunikācija un tās ir produktīvākas. Ja Scrum Team kļūst pārāk liela, būtu jāapsver iespēja
reorganizēties vairākās komandās, kur katra no tām koncentrējas uz vienu un to pašu produktu. Tāpēc
tām būs viens un tas pats Product Goal, Product Backlog un Product Owner.
Scrum Team ir atbildīga par visām ar produktu saistītajām aktivitātēm, sākot no ieinteresēto personu
sadarbības, verifikācijas, uzturēšanas, darbības, eksperimentiem, pētniecības un izstrādes, kā arī par visu
citu, kas var būt nepieciešams. Tā ir strukturēta un organizācija to pilnvaro pārvaldīt savu darbu.
Strādājot Sprint ietvaros vienmērīgā tempā, uzlabojas Scrum Team koncentrēšanās un patstāvīgums.
Visa Scrum Team ir atbildīga par vērtīga un lietojama Increment izveidi katrā no Sprint. Scrum definē
specifiskas atbildības trīs Scrum Team lomām: Developers, Product Owner un Scrum Master.

Developers
Developers ‐ ir tie Scrum Team cilvēki, kuri ir apņēmušies izveidot jebkura veida lietojamu inkrementu
katrā Sprint.
Developers nepieciešamās prasmes bieži vien ir ļoti plašas, un tās var atšķirties atkarībā no darba jomas.
Tomēr Developers vienmēr ir atbildīgi par:●●●●Sprint plāna izveidi ‐ Sprint Backlog;
Kvalitātes nodrošināšanu, balstoties uz Definition of Done;
Katras dienas plāna pielāgošanu, lai sasniegtu Sprint Goal; un,
Savstarpējo atbildību, kā profesionāļiem.

Product Owner
Product Owner ir atbildīgs par maksimālu produkta vērtības radīšanu, kas izriet no Scrum Team darba.
Kā tas tiek panāks var atšķirties starp organizācijām, Scrum Team un personām.
Product Owner ir atbildīgs arī par efektīvu Product Backlog pārvaldību, kas ietver:Product Goal izstrādi un nepārprotamu tā izskaidrošanu;Product Backlog izveidi un saprotamu tās vienību izskaidrošanu;Product Backlog sakārtošanu (prioritizēšanu); un,Pārliecināšanos, ka Product Backlog ir caurskatāms, pieejams un saprotams.

Product Owner var veikt iepriekš minētos darbus vai deleģēt tos citiem. Neatkarīgi no tā, atbildīgs paliek
Product Owner.

6

Lai Product Owner varētu veiksmīgi darboties, organizācijai jārespektē viņa lēmumi. Šie lēmumi ir
redzami Product Backlog saturā un noteiktajās prioritātēs, kā arī piegādātajos Increment, ko parāda
Sprint review ceremonijās.
Product Owner ir viena persona. Product Owner var pārstāvēt vairāku ieinteresēto pušu vēlmes,iekļaujot tās Product Backlog. Tie, kas vēlas mainīt Product Backlog (pievienojot darbus vai mainot
prioritātes), var to izdarīt, mēģinot pārliecināt Product Owner par tā nepieciešamību.

Scrum MasterScrum Master ir atbildīgs, lai nodrošinātu Scrum tādu, kāds tas ir definēts Scrum ceļvedī. Viņš to dara,
palīdzot visiem izprast Scrum teoriju un praksi gan Scrum Team, gan organizācijā.
Scrum Master ir atbildīgs par Scrum Team efektivitāti. Viņš Scrum Team to palīdz uzlabot ar Scrum
ietvara palīdzību.
Scrum Master ir patiess līderis, kas palīdz Scrum Team un visai organizācijai.
Scrum Master palīdz Scrum Team vairākos veidos, ieskaitot:

Apmācot komandas locekļus būt pašpārvaldošiem un multifunkcionāliem;
Palīdzot Scrum Team koncentrēties uz augstu vērtību nesošu Increment izstrādi, kas atbilst
Definition of Done;
Novēršot radušos šķēršļus, kas traucē Scrum Team darba progresam; un,Pārliecinoties, ka visas Scrum ceremonijas tiek ievērotas ir pozitīvā gaisotnē, produktīvas un tiekievēroti laika rāmji.

Scrum Master palīdz Product Owner vairākos veidos, ieskaitot:

Palīdzot atrast efektīvu pieeju Product Goal definēšanai un Product Backlog pārvaldībai;Palīdzot Scrum Team izprast nepieciešamību pēc skaidriem un kodolīgiem Product Backlog
vienību aprakstiem;
Palīdzot veidot empīrisku produktu plānošanu sarežģītai videi; un,
Veicinot ieinteresēto personu sadarbību pēc pieprasījuma vai vajadzības.

Scrum Master palīdz organizācijai vairākos veidos, ieskaitot:


Vadot un apmācot organizāciju Scrum ieviešanas procesā;
Scrum ieviešanas plānošana un konsultēšana organizācijas ietvaros;
Palīdzot darbiniekiem un ieinteresētajām personām saprast un ieviest empīrisku pieeju sarežģītu
darbu veikšanā; un,
Nojaucot barjeras starp ieinteresētajām personām un Scrum Team.

7

Scrum Ceremonijas
Sprints ir kā ietvars visām pārējām ceremonijām. Katra Scrum ceremonija ir oficiāla iespēja pārbaudīt unpielāgot Scrum artefaktus. Šīs ceremonijas ir speciāli izveidotas tā, lai nodrošinātu nepieciešamo
caurskatāmību. Nenodrošinot kādu no ceremonijām, tiek pazaudēta iespēja pārbaudīt un pielāgot.
Scrum ceremonijas tiek lietotas arī, lai nodrošinātu nepieciešamo informācijas apmaiņas regularitāti un,lai minimizētu sanāksmes, kas nav definētas Scrum ietvarā.
Lai mazinātu sarežģītību, ceremonijas tiek rīkotas vienā un tajā pašā laikā un vietā.

The Sprint
Sprinti ir Scrum pulss, kur idejas tiek pārvērstas vērtībā.
Tās ir fiksēta garuma, viena mēneša vai īsākas ceremonijas, lai veicinātu patstāvību. Jauns Sprint sākasuzreiz pēc iepriekšējā Sprint beigām.
Visi darbi, ko jāveic, lai sasniegtu Product Goal, ieskaitot – Sprint Planning, Daily Scrum, Sprint Review un
Sprint Retrospective, notiek katra Sprint laikā.
Sprint laikā:Netiek veiktas nekādas izmaiņas, kas varētu apdraudēt Sprint Goal;
Kvalitāte nesamazinās;
Product Backlog var tikt precizēta pēc nepieciešamības; un,
Tvērumu var precizēt un atkārtoti apspriest ar Product Owner, kad tiek uzzināts vairāk.

Sprint nodrošina paredzamību, nodrošinot Product Goal sasniegšanas pārbaudi un pielāgošanu vismaz
reizi kalendārā mēneša laikā. Ja Sprint ir pārāk garš, Sprint Goal var kļūt neaktuāls, var pieaugtsarežģītība un riski. Īsākus Sprint var izmantot, lai radītu vairāk mācību ciklu un ierobežotu izmaksu riskus
līdz mazākam laika periodam. Katru Sprint var uzskatīt par īsu projektu.
Lai prognozētu progresu, pastāv dažādas prakses, piemēram, burn‐up, burn‐down grafiki vai kumulatīvās
plūsmas. Lai arī tās ir noderīgas, tās neaizstāj empīrisma nozīmi. Sarežģītā vidē nav zināms, kas notiks. Uznākotni vērstu lēmumu pieņemšanai var izmantot tikai to pieredzi, kas gūta no lietām, kas jau ir
notikušas.
Sprint var atcelt, ja Sprint Goal kļūst neaktuāls. Tikai Product Owner ir tiesīgs atcelt Sprint.

Sprint Planning
Ar Sprint Planning tiek uzsākts Sprint, nosakot veicamos darbus Sprint ietvaros. Šī plāna radīšana ir visas
Scrum Team kopdarbs.

8

Product Owner pārliecinās, ka dalībnieki ir gatavi apspriest vissvarīgākos (pēc prioritātēm) ProductBacklog elementus un to, kā tie ir saistīti ar Product Goal. Scrum Team uz Sprint Planning var uzaicināt
citus cilvēkus, kas varētu būt noderīgi plānošanā.
Sprint Planning apskata sekojošas tēmas:Pirmā tēma: Kādēļ šis Sprint ir vērtīgs?
Product Owner prezentē, kā produkts varētu palielināt savu vērtību un lietderību šajā Sprint. Tad visa
Scrum Team sadarbojas, lai definētu Sprint Goal, un pamatojumu, kāpēc Sprint ir vērtīgs ieinteresētajām
personām. Sprint Goal ir jānodefinē līdz Sprint planning beigām.

Otrā tēma: Ko var paveikt šajā Sprint?
Apspriežoties ar Product Owner, Developers no Product Backlog izvēlas vienumus, kurus iekļaut
pašreizējā Sprint. Scrum team šī procesa laikā var precizēt šīs vienības, lai palielinātu izpratni unpārliecību par veicamo darbu.
Izvēlēties, cik daudz var tikt paveikts Sprint laikā var būt sarežģīti. Tomēr, jo vairāk Developers zina parsavu iepriekšējo sniegumu, potenciālo kapacitāti un Definition of Done, jo pārliecinātāki viņi būs savās
Sprint prognozēs.

Trešā tēma: Kā paveikt izvēlētos darbus?
Katrai izvēlētajai Product Backlog vienībai Developers plāno svarīgākos darbus, kas jāpaveic, lai izveidotu
Increment, kas atbilst Definition of Done. Tas bieži vien tiek panākts sadalot Product Backlog vienību
mazākos uzdevumos, kas ir paveicami vienas dienas laikā vai īsākā termiņā. Kā tas tiek darīts, to nosaka
tikai Developers. Neviens cits viņiem nenorāda, kā pārvērst Product Backlog vienības Increment, kas nesvērtību.
Sprint Goal, izvēlētās Product Backlog vienības uz Sprint un plāns to piegādāšanai, tiek saukts par Sprint
Backlog.
Sprint planning notiek ierobežotā laikā, maksimums astoņas stundas viena mēneša Sprint. Īsākiem Sprint
ceremonija parasti ir īsāka.

Daily Scrum
Daily Scrum mērķis ir pārbaudīt progresu ceļā uz Sprint Goal un, pēc vajadzības, pielāgot Sprint Backlog,
pielāgojot plānoto dienas darbu.
Daily Scrum ceremonija ir 15 minūtes gara un tajā piedalās Scrum Team. Lai mazinātu sarežģītību, tāstiek rīkotas vienā un tajā pašā vietā un laikā katru Sprint darba dienu. Ja Product Owner un Scrum
Master aktīvi piedalās Sprint Backlog vienību izstrādē, tad viņi piedalās, kā Developers.
9

Developers var izvēlēties sapulces formu un paņēmienus, kādus viņi vēlas, ja vien viņu Daily Scrum
koncentrējas uz progresu ceļā uz Sprint Goal un viņi ir spējīgi sagatavot efektīvu plānu nākamajai darba
dienai. Tas nodrošina koncentrēšanos uz veicamajiem darbiem un uzlabo pašpārvaldības prasmes.
Daily Scrum uzlabo un nodrošina komunikāciju, identificē šķēršļus, veicina ātru lēmumu pieņemšanu unlīdz ar to novērš nepieciešamību pēc citām sanāksmēm.
Daily Scrum nav vienīgais laiks, kad ir atļauts tikties Developers, lai saskaņotu plānus. Viņi bieži tiekas
dienas laikā, lai detalizētāk apspriestu, pielāgotu vai pārplānotu Sprint veicamos darbus.

Sprint Review
Sprint Review mērķis ir pārbaudīt Sprint rezultātus un identificēt pielāgojumus. Scrum Team iepazīstina
ieinteresētās personas ar sava darba rezultātiem un tiek apspriests progress Product Goal sasniegšanā.
Ceremonijas laikā Scrum Team un ieinteresētās personas pārskata, kas tika paveikts Sprint un kas ir
mainījies. Pamatojoties uz šo informāciju, dalībnieki vienojas, kā rīkoties tālāk. Arī Product Backlog var
tikt pielāgots, lai atbilstu jaunajām idejām vai iespējām. Sprint Review ir darba sesija un Scrum Teambūtu jāizvairās to pārvērst par vienkāršu prezentāciju.
Sprint Review ir pirmspēdējā Sprint ceremonija un tā arī ir ierobežota laikā ‐ maksimums 4 stundas viena
mēneša Sprint. Īsākiem Sprint ceremonija parasti ir īsāka.

Sprint Retrospective
Sprint Retrospective mērķis ir plānot kā paaugstināt kvalitāti un efektivitāti.
Scrum Team pārbauda, kā Sprint noritēja attiecībā uz indivīdiem, mijiedarbību, procesiem, rīkiem unviņu Definition of Done. Pārbaudāmie elementi mainās atkarībā no darbības jomas. Tiek identificētipieņēmumi, kas viņus maldināja, kā arī tiek izpētīts, kādēļ tādi pieņēmumi radās. Scrum Team apspriež,kas Sprint laikā izdevās labi, ar kādām problēmām tā saskārās un kā šīs problēmas tika (vai netika)
atrisinātas.
Scrum Team identificē nepieciešamās izmaiņas, lai uzlabotu savu efektivitāti. Visietekmīgākie uzlabojumi
tiek ieviesti pēc iespējas ātrāk. Tos var pat pievienot Sprint Backlog uz nākošo Sprint.
Sprint Retrospective noslēdz Sprint. Tā ir laikā ierobežota ceremonija, kas ilgst maksimums trīs stundas
viena mēneša Sprint. Īsākiem Sprint ceremonija parasti ir īsāka.

Scrum Artefakti
Scrum artefakti atspoguļo darbu vai vērtību. Tie ir paredzēti, lai maksimāli palielinātu svarīgākās
informācijas caurskatāmību.

10

Katrā artefaktā ir apņemšanās, kas sniedz informāciju, lai saglabātu caurskatāmību un fokusu, un pret
kuru tiek mērīts progress:Product Backlog tas ir Product Goal.
Sprint Backlog tas ir Sprint Goal.
Increment tā ir Definition of Done.

Apņemšanās pastāv, lai stiprinātu Scrum empīrismu, kā arī vērtības Scrum Team un ieinteresētajām
personām.

Product Backlog
Product Backlog ir prioritizēts darbu saraksts, kuri jāpaveic, lai pilnveidotu produktu. Tas ir vienīgais
Scrum Team darāmo darbu avots.
Product Backlog vienības, kas var tikt realizētas viena Sprint laikā, tiek uzskatītas par gatavām izvēlei
Sprint Planning ceremonijā. Tās sasniedz šo gatavības un caurskatāmības stāvokli pēc detalizācijas.
Product Backlog detalizācija ir process, kurā vienības tiek sadalītās vēl mazākās un precīzākās ProductBacklog vienībās. Tas ir nepārtraukts process, kurā tiek pievienotas dažādas detaļas, kā piemēram ‐apraksts, secība, apjoms, tas, kādus atribūtus pievieno, parasti atšķiras atkarībā no darbības sfēras.
Developers, kas veiks šos darbus, ir atbildīgi par detalizācijas līmeni. Product Owner var palīdzēt
Developers izprast izstrādājamās vienības un rast kompromisus.

Apņemšanās: Product Goal
Product Goal apraksta produkta stāvokli nākotnē, kas var kalpot par mērķi Scrum Team, pret kuru veikt
plānošanas darbus. Product Goal tiek iekļauts Product Backlog. Viss pārējais Product Backlog definē to,"kas" veicinās Product Goal sasniegšanu.
Produkts ir transports ar ko piegādāt vērtību. Tam ir skaidras robežas, zināmas ieinteresētās
personas, skaidri definēti lietotāji vai klienti. Produkts var būt serviss, fizisks produkts vai kautkas abstrakts.
Product Goal ir Scrum Team ilgtermiņa mērķis, ko jāsasniedz. Pirms nākamā mērķa sasniegšanas
jāsasniedz tekošais, vai no tā jāatsakās.

Sprint Backlog
Sprint Backlog ietver Sprint Goal (kāpēc?), Sprint izvēlēto vienību saraksta (Ko?) no Product Backlog, kāarī no plāna (Kā?) Increment piegādei.
Sprint Backlog ir Developers darba plāns. Tas ir caurskatāms, pastāvīgi aktualizēts darbu plāns, ko
Developers apņēmušies paveikt dotā Sprint laikā, lai sasniegtu Sprint Goal. Līdz ar to Sprint Backlog tiek
11

regulāri atjaunots, tiklīdz tiek uzzināta jauna informācija. Tam ir jābūt pietiekami detalizētam un
skaidram, lai komanda varētu pārbaudīt savu progresu Daily Scrum ceremonijā.

Apņemšanās: Sprint Goal
Sprint Goal ir viens. Lai gan Sprint Goal ir Developers apņemšanās, tas nodrošina elastību attiecībā uzprecīzu darbu, kas nepieciešams tā sasniegšanai. Sprint Goal arī rada saskaņotību un koncentrēšanos,mudinot Scrum Team strādāt kopā, nevis atsevišķi.
Sprint Goal tiek definēts Sprint planning laikā un pēc tam tiek pievienots Sprint Backlog. Developers
Sprint ietvaros visu laiku patur prātā Sprint Goal. Ja veicamie darbi sāk izrādīties citādi, nekā tika plānots,
Developers sadarbojas ar Product Owner, lai vienotos par Sprint tvērumu neietekmējot Sprint Goal.

Increment
Increment ir skaidrs pakāpiens tuvāk Product Goal. Katrs Increment ir papildinājums visiem
iepriekšējiem Increment un ir rūpīgi pārbaudīts, nodrošinot, ka visi Increment korekti darbojas kopā. Lai
nodrošinātu vērtību, Increment ir jābūt izmantojamam.
Sprint laikā var izveidot vairākus Increment. Increment tiek prezentēti Sprint review, tādā veidā veicinot
empīrismu. Lai gan, ieinteresētajām personām Increment var piegādāt arī pirms Sprint beigām. Tāpēc
Sprint review nevajadzētu uztvert kā vārtus, caur kuriem tiek "izlaista" kāda vērtība.
Darbu nevar uzskatīt par Increment daļu, ja tas neatbilst Definition of Done.

Apņemšanās: Definition of Done
The Definition of Done ir formāls apraksts, kas nosaka Increment stāvokli, kad tas ir sasniedzis vajadzīgo
produkta kvalitātes līmeni.
Brīdī, kad Product Backlog vienība sasniedz Definition of Done, ir izveidots Increment.
The Definition of Done rada caurskatāmību sniedzot visiem vienādu izpratni par to, kāds darbs ir
paveikts, kā daļa no Increment. Ja Product Backlog vienības nesasniedz Definition of Done, tās nevar tikt
nodotas, kā pabeigti vienumi vai tikt atrādīti Sprint Review ceremonijā. Tie tiek atgriezti uz ProductBacklog vēlākai izskatīšanai.
Ja Programmatūras Increment Definition of Done ir izstrādes organizācijas standartos, tad visām Scrum
Team tā jāievēro, vismaz kā minimālās prasības savas komandas Definition of Done noteikšanā. Ja
Increment Definition of Done nav ietverta izstrādes organizācijas konvencijās, tad Scrum Team
Developers jārada Definition of Done, kas vislabāk atbilst produktam.
Developers ir jāievēro Definition of Done. Ja pie viena produkta strādā vairākas Scrum Team, tāmsavstarpēji jādefinē un jāievēro viena un tā pati Definition of Done.

12

Noslēgums
Scrum ir bezmaksas šī ceļveža fomā. Šeit izklāstītais Scrum ietvars ir nemainīgs. Lai gan ir iespējams
ieviest tikai daļu no Scrum, rezultāts nebūs saucams par Scrum. Scrum pastāv tikai kopumā un darbojas
kā konteiners citām metodēm, metodoloģijām un praksēm.

Pateicības
Cilvēkiem
Starp tūkstošiem cilvēku, kuri ir devuši ieguldījumu Scrum, mums būtu jāizceļ tie, kuru nozīme bija liela
pašā sākumā: Jeff Sutherland strādāja ar Jeff McKenna un John Scumniotales, un Ken Schwaber strādāja
ar Mike Smith un Chris Martin, un visi viņi strādāja arī kopā. Gadiem ejot, arī daudzi citi sniedza savu
ieguldījumu un bez viņu palīdzības Scrum nebūtu tāds, kāds tas ir šodien.

Scrum Ceļveža Vēsture
Ken Schwaber un Jeff Sutherland pirmo reizi Scrum prezentēja OOPSLA konferencē 1995. gadā. Tas
galvenokārt bija mācību dokumentējums, ko Kens un Džefs bija guvuši iepriekšējo gadu laikā, tajā tika
publiskota arī pirmā oficiālā Scrum definīcija.
Scrum ceļvedis dokumentē Scrum, kuru Jeff Sutherland un Ken Schwaber ir izstrādājuši, attīstījuši unuzturējuši vairāk kā 30 gadus. Citi avoti sniedz šablonus, procesus un metodes, kas papildina Scrum
sistēmu. Tās var paaugstināt produktivitāti, vērtību, radošumu un apmierinātību ar rezultātiem.
Detalizēta Scrum vēsture ir aprakstīta citur. Par godu pirmajiem uzņēmumiem, kur Scrum tika pārbaudīts
un pierādīts, mēs izceļam Individual, Inc., Newspage, Fidelity Investments un IDX (tagad GE Medical).

TulkotājiŠī ceļveža oriģinālu angļu valodā izveidoja iepriekš minētie autori. Pie Scrum Ceļveža tulkojuma izveides latviešu
valodā strādāja Andris Savickis, rediģēja ‐ Amanda Zemīte.
Kontakti:
 E‐pasts acbrzsh@inbox.lv;
 Mājaslapa www.AgileScrum.lv;
 LinkedIn https://www.linkedin.com/in/andris‐savickis‐a121aa63/

13

2020 Scrum ceļvedī ieviestās izmaiņas attiecībā pret 2017
Scrum ceļvedi
Mazāk noteikumus aprakstošs
Gadu gaitā Scrum ceļvedis sāka kļūt aprakstošs. 2020. gada versijas mērķis ir izveidot Scrum Ceļvedi kā minimālinepieciešamo ietvaru, mazinot aprakstošās lietas, piemēram, noņemtot Daily Scrum jautājumus, aprakstus PBI
atribūtiem, Sprint Backlog, saīsinot Sprint atcelšanas sadaļu un citas lietas.

Viena komanda, Koncentrējas uz vienu produktuMērķis bija izskaust atsevišķas komandas jēdzienu vienas komandas ietvaros, kas izraisīja “starpnieka” vai “mēs unviņi” attiecības starp PO un Developers. Tagad ir tikai viena Scrum Team, kas koncentrējas uz vienu un to pašumērķi, ar trim dažādiem atbildības sadalījumiem: PO, SM, un Developers.

Ieviests Product Goal
2020. gada Scrum ceļvedis iepazīstina ar Product Goal jēdzienu, lai Scrum Team būtu lielāks mērķis uz ko
fokusēties. Katram Sprint vajadzētu tuvināt produktu kopējam Product Goal.

Sprint Goal, Definition of Done un Product Goal vieta
Iepriekšējie Scrum ceļveži aprakstīja Sprint Goal un Definition of Done tikai nedaudz tiem pieskaroties. Tie nebijaīsti artefakti, bet bija kaut kas saistīts ar artefaktiem. Ar papildus Product Goal, 2020. Gada versija sniedz vairākskaidrības par šo. Katrs no artefaktiem tagad satur “apņemšanos” pret tiem. Priekš Product Backlog tas ir Product
Goal, Sprint Backlog tas ir Sprint Goal, un Increment tas ir Definition of Done (tagad bez pēdiņām). Tie eksistē, lai
nodrošinātu caurskatāmību un fokusētos uz progresu, katrā no artefaktiem.

Pašorganizētu vietā Pašpārvaldošas
Iepriekšējie Scrum ceļveži atsaucās uz Development Teams kā uz pašorganizētām komandām, kas izvēlas – kurš unkā darīs darbu. Vairāk pievēršoties Scrum komandai, 2020. gada versijā tiek uzsvērta pašpārvaldoša Scrum
komanda, kas izvēlas – kurš un kā, un kādu darbu darīs.

Trīs Sprint Planning tēmas
Papildus Sprint planning tēmām “Kas” un “Kā” 2020. gada Scrum ceļvedī uzsvars tiek likts uz trešo tēmu “Kāpēc”,
kura sasaucas ar Sprint Goal.

Vienkāršota valoda lielākas auditorijas sasniegšanai
2020. gada Scrum ceļvedis koncentrējas uz sarežģītu teikumu vienkāršošanu, kā arī uz atlikušo IT nozares terminu
izslēgšanu (piemēram, testēšana, sistēma, izstrāde, prasības utt.). Scrum rokasgrāmatā (Oriģinālajā ‐ Angļu valodā)tagad ir mazāk nekā 13 lappuses.

14