Ken Schwaber & Jeff Sutherland

Y Canllaw
Scrum
Y Canllaw Diffiniol i Scrum: Rheolau'r Gêm

Tachwedd 2020

Pwrpas y Canllaw Scrum
Fe wnaethom ddatblygu Scrum yn y 1990au cynnar. Fe wnaethon ni ysgrifennu'r fersiwn gyntaf o'r
Canllaw Scrum yn 2010 i helpu pobl ledled y byd i ddeall Scrum. Rydym wedi datblygu'r Canllaw ers
hynny gyda ddiweddariadau bach, swyddogaethol. Gyda'n gilydd, rydym yn sefyll y tu ôl iddo.
Mae’r Canllaw Scrum yn cynnwys y diffiniad o Scrum. Mae pob elfen o'r fframwaith yn cyflawni pwrpas
penodol sy'n hanfodol i'r gwerth cyffredinol a'r canlyniadau a wireddwyd gyda Scrum. Mae newid
dyluniad neu syniadau craidd Scrum, gadael elfennau allan, neu beidio â dilyn rheolau Scrum, yn
cuddio problemau ac yn cyfyngu ar fanteision Scrum, gan ei wneud e’n hyd yn oed yn ddiwerth.
Dilynwn y defnydd cynyddol o Scrum o fewn byd cymhleth sy’n tyfu’n barhaus. Rydym yn falch iawn oweld Scrum yn cael ei fabwysiadu mewn sawl maes sy'n cynnal gwaith sydd yn ei hanfod yn gymhleth,y tu hwnt i ddatblygu cynnyrch meddalwedd lle mae Scrum â'i wreiddiau. Wrth i ddefnydd Scrum ledu,
mae datblygwyr, ymchwilwyr, dadansoddwyr, gwyddonwyr, ac arbenigwyr eraill yn gwneud y gwaith.
Rydym yn defnyddio'r gair “developers” yn Scrum nid i eithrio, ond i symleiddio. Os ydych chi'n cael
gwerth o ddefnyddio Scrum, ystyriwch eich bod wedi'ch cynnwys.
Wrth i Scrum gael ei ddefnyddio, gellir dod o hyd i batrymau, prosesau a mewnwelediadau sy'n cyd‐fynd â fframwaith Scrum fel y'i disgrifir yn y ddogfen hon, eu cymhwyso a'u dyfeisio. Mae eu disgrifiad
y tu hwnt i bwrpas y Canllaw Scrum oherwydd eu bod yn sensitif i gyd‐destun ac yn amrywio'n fawr
rhwng defnyddiau Scrum. Mae’r tactegau ar gyfer eu ddefnyddio o fewn fframwaith Scrum yn
amrywio'n fawr ac yn gael eu disgrifio mewn mannau eraill.

Ken Schwaber & Jeff Sutherland Tachwedd 2020

© 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

Pwrpas y Canllaw Scrum

1

Diffiniad Scrum

3

Theori Scrum

3

Tryloywder

3

Arolygu

4

Addasiad

4

Gwerthoedd Scrum

4

Scrum Team

5

Developers

5

Product Owner

5

Scrum Master6

Digwyddiadau Scrum

7

Sprint7

Sprint Planning

8

Daily Scrum

9

Sprint Review

9

Sprint Retrospective

10

Arteffactau Scrum

10

Product Backlog
Ymrwymiad: Product Goal

11

Sprint Backlog
Ymrwymiad: Sprint Goal

112

Increment
Ymrwymiad: Definition of Done (Definition of Done)

13

Diwedd Nodyn

14

Diolchiadau

14

Pobl

14

Hanes y Canllaw Scrum

14

Y Cyfieithiad

14

Newidiadau o Scrum Guide 2017 i Scrum Guide 2020

15

2

Scrum Diffiniad
Mae Scrum yn fframwaith ysgafn sy'n helpu pobl, timau a sefydliadau'n cynhyrchu gwerth drwy
atebion addasol ar gyfer problemau cymhleth.
Yn gryno, mae Scrum angen Scrum Master i greu amgylchedd lle:
1.
2.
3.
4.

Mae’r Product Owner yn archebu'r gwaith ar gyfer problem gymhleth yn Product Backlog.
Mae'r Scrum Team yn troi detholiad o'r gwaith yn Increment o werth yn ystod Sprint.
Mae Scrum Team a'i randdeiliaid yn archwilio'r canlyniadau ac yn addasu ar gyfer y Sprint nesaf.
Ailadrodd

Mae Scrum yn syml. Rhowch gynnig arni fel y mae a phenderfynwch a yw ei hathroniaeth, ei theori a'istrwythur yn helpu i gyflawni nodau a chreu gwerth. Mae fframwaith Scrum yn anghyflawn yn
bwrpasol, gan ddiffinio dim ond y rhannau sydd eu hangen i roi theori Scrum ar waith. Adeiladir ar
Scrum gan ddeallusrwydd cyfunol y bobl sy'n ei ddefnyddio. Yn hytrach na rhoi cyfarwyddiadau manwl ibobl, mae rheolau Scrum yn arwain eu perthnasoedd a'u rhyngweithiadau.
Gellir defnyddio prosesau, technegau a dulliau amrywiol o fewn y fframwaith. Mae Scrum yn lapio oamgylch arferion presennol neu'n eu gwneud yn ddiangen. Mae Scrum yn gwneud effeithiolrwydd
cymharol rheolaeth gyfredol, yr amgylchedd a thechnegau gwaith yn weladwy, fel y gellir gwneud
gwelliannau.

Theori Scrum
Mae Scrum wedi'i seilio ar empiriaeth a meddwl darbodus. Mae empiriaeth yn honni bod gwybodaeth
yn dod o brofiad a gwneud penderfyniadau yn seiliedig ar yr hyn sy'n cael ei arsylwi. Mae meddwl
darbodus yn lleihau gwastraff ac yn canolbwyntio ar yr hanfodion.
Mae Scrum yn defnyddio dull ailadroddol, cynyddol i optimeiddio rhagweladwyedd ac i reoli risg. Mae
Scrum yn ymgysylltu â grwpiau o bobl sydd, gyda'i gilydd, â'r holl sgiliau ac arbenigedd i wneud y gwaitha rhannu neu gaffael sgiliau o'r fath yn ôl yr angen.
Mae Scrum yn cyfuno pedwar digwyddiad ffurfiol i'w harchwilio a'u haddasu o fewn digwyddiad sy'ncynnwys y Sprint. Mae'r digwyddiadau hyn yn gweithio oherwydd eu bod yn gweithredu pileri empirig
Scrum o dryloywder, arolygu ac addasu.

Tryloywder
Rhaid i'r broses a'r gwaith datblygol fod yn weladwy i'r rhai sy'n cyflawni'r gwaith yn ogystal â'r rhai sy'nderbyn y gwaith. Gyda Scrum, mae penderfyniadau pwysig yn seiliedig ar gyflwr canfyddedig ei driarteffact ffurfiol. Gall arteffactau sydd â thryloywder isel arwain at benderfyniadau sy'n lleihau gwerth ac
yn cynyddu risg.
3Mae tryloywder yn galluogi arolygu. Mae arolygu heb dryloywder yn gamarweiniol ac yn wastraffus.

Arolygu
Rhaid archwilio arteffactau Scrum a'r cynnydd tuag at nodau cytunedig yn aml ac yn ddiwyd i ganfod
amrywiannau neu broblemau a allai fod yn annymunol. I helpu gydag arolygu, mae Scrum yn darparu
diweddeb ar ffurf ei bum digwyddiad.
Mae arolygu yn galluogi addasu. Ystyrir bod arolygu heb addasu yn ddibwrpas. Mae digwyddiadau sgrum
wedi'u cynllunio i ysgogi newid.

AddasuOs bydd unrhyw agweddau ar broses yn gwyro y tu allan i derfynau derbyniol neu os yw'r cynnyrch
canlyniadol yn annerbyniol, rhaid addasu'r broses sy'n cael ei defnyddio neu'r deunyddiau sy'n cael eu
cynhyrchu. Rhaid gwneud yr addasiad cyn gynted â phosibl i leihau gwyriad pellach.
Mae addasu yn dod yn fwy anodd pan nad yw'r bobl dan sylw wedi'u grymuso neu'n hunanreoli.
Disgwylir i Scrum Team addasu'r eiliad y bydd yn dysgu unrhyw beth newydd trwy arolygu.

Gwerthoedd Scrum
Mae’r defnydd llwyddiannus o Scrum yn dibynnu ar bobl yn dod yn fwy hyfedr mewn byw pum gwerth:Ymrwymiad, Ffocws, Bod yn Agored, Parch, a Dewrder
Mae Scrum Team yn ymrwymo i gyflawni ei nodau ac i gefnogi ei gilydd. Mae eu prif ffocws ar waith y
Sprint i wneud y cynnydd gorau posibl tuag at y nodau hyn. Mae Scrum Team a'i randdeiliaid yn agoredam y gwaith a'r heriau. Mae aelodau Scrum Team yn parchu ei gilydd i fod yn bobl alluog, annibynnol,
ac yn cael eu parchu felly gan y bobl y maent yn gweithio gyda nhw. Mae aelodau Scrum Team yn
ddigon dewr i wneud y peth iawn, i weithio ar broblemau anodd.
Mae'r gwerthoedd hyn yn rhoi cyfeiriad i Scrum Team o ran eu gwaith, eu gweithredoedd a'u
hymddygiad. Dylai'r penderfyniadau a wneir, y camau a gymerir, a'r ffordd y defnyddir Scrum
atgyfnerthu'r gwerthoedd hyn, nid eu lleihau na'u tanseilio. Mae aelodau Scrum Team yn dysgu ac yn
archwilio'r gwerthoedd wrth iddynt weithio gyda digwyddiadau ac arteffactau Scrum. Pan ymgorfforir y
gwerthoedd hyn gan Scrum Team a'r bobl y maent yn gweithio gyda nhw, mae pileri empirig Scrum odryloywder, arolygu ac addasu yn dod i ymddiriedaeth adeiladu bywyd.

4

Scrum Team
Uned sylfaenol Scrum yw tîm bach o bobl, Scrum Team. Mae Scrum Team yn cynnwys un Scrum Master,un Product Owner, a Developers. O fewn Scrum Team, nid oes unrhyw is‐dimau na hierarchaethau.
Mae'n uned gydlynol o weithwyr proffesiynol sy'n canolbwyntio ar un amcan ar y tro, y Product Goal.
Mae Scrum Teams yn draws‐swyddogaethol, sy'n golygu bod gan yr aelodau'r holl sgiliau angenrheidiol
i greu gwerth am phob Sprint. Maent hefyd yn hunanreoli, sy'n golygu eu bod yn penderfynu'n fewnol
pwy sy'n gwneud beth, pryd, a sut.
Mae Scrum Team yn ddigon bach i aros yn ddigon heini ac yn ddigon mawr i gwblhau gwaith sylweddol ofewn Sprint, fel arfer 10 neu lai o bobl. Yn gyffredinol, rydym wedi canfod bod timau llai yn cyfathrebu'nwell ac yn fwy cynhyrchiol. Os bydd Scrum Teams yn mynd yn rhy fawr, dylent ystyried ad‐drefnu i mewn
i dimau Scrum lluosog cydlynol, pob un yn canolbwyntio ar yr un cynnyrch. Felly, dylent rannu'r un
Product Goal, Product Backlog, a Product Owner.
Mae Scrum Team yn gyfrifol am yr holl weithgareddau sy'n ymwneud â chynnyrch, o gydweithio ârhanddeiliaid, dilysu, cynnal a chadw, gweithredu, arbrofi, ymchwil a datblygu, ac unrhyw beth arall a
allai fod yn ofynnol. Cânt eu strwythuro a'u grymuso gan y sefydliad i reoli eu gwaith eu hunain. Mae
gweithio yn Sprints ar gyflymder cynaliadwy yn gwella ffocws a chysondeb Scrum Team.
Mae’r Scrum Team cyfan yn gyfrifol am greu Increment pob Sprint gwerthfawr a defnyddiol. Mae Scrum
yn diffinio tri atebolrwydd penodol o fewn Scrum Team: y Developers, Product Owner, a'r Scrum Master.

Developers
Yr Developers yw'r bobl yn Scrum Team sydd wedi ymrwymo i greu unrhyw agwedd ar Increment
Defnyddiadwy bob Sprint.
Mae'r sgiliau penodol sydd eu hangen ar y Developers yn aml yn eang a byddant yn amrywio yn ôl ymaes gwaith. Fodd bynnag, mae'r Developers bob amser yn atebol am:●●●●

Greu cynllun ar gyfer y Sprint, yr Sprint Backlog;
Sefydlu ansawdd trwy gadw at Definition of Done;
Addasu eu cynllun bob dydd tuag at y Sprint Goal; a,
Dal ein gilydd yn atebol fel gweithwyr proffesiynol.

Product Owner
Product Owner sy'n gyfrifol am wneud y mwyaf o werth y cynnyrch o ganlyniad i waith Scrum Team.
Gall sut y gwneir hyn amrywio'n fawr ar draws sefydliadau, Scrum Teams, ac unigolion.

5

Mae’r Product Owner hefyd yn atebol am reoli Product Backlog yn effeithiol, sy'n cynnwys:●●●●

Datblygu a chyfathrebu Product Goal yn benodol;
Creu a chyfathrebu eitemau Product Backlog yn glir;
Archebu eitemau Product Backlog; a,Sicrhau bod yr Product Backlog yn dryloyw, yn weladwy ac yn ddealladwy.

Gall Product Owner wneud y gwaith uchod neu ddirprwyo'r cyfrifoldeb i eraill. Serch hynny, mae Product
Owner yn parhau i fod yn atebol.
Er mwyn i Product Owners lwyddo, rhaid i'r sefydliad cyfan barchu eu penderfyniadau. Mae'r
penderfyniadau hyn i'w gweld yng nghynnwys a threfniadaeth yr Product Backlog, a thrwy'r Increment
archwiliadwy yn yr Sprint Review.
Un person yw Product Owner, nid pwyllgor. Gall Product Owner gynrychioli anghenion llawer oranddeiliaid yn yr Product Backlog. Gall y rhai sydd am newid yr Product Backlog wneud hynny trwy
geisio argyhoeddi Product Owner.

Scrum Master
Mae'r Scrum Master yn gyfrifol am sefydlu Scrum fel y'i diffinnir yn Canllaw Scrum. Maen nhw'n gwneud
hyn trwy helpu pawb i ddeall theori ac ymarfer Scrum, o fewn Scrum Team a'r sefydliad.
Mae'r Scrum Master yn atebol am effeithiolrwydd Scrum Team. Gwnânt hyn drwy alluogi Scrum Team iwella ei arferion, o fewn fframwaith Scrum.
Mae Scrum Masters yn arweinwyr go iawn sy'n gwasanaethu Scrum Team a'r sefydliad. Mae'r Scrum
Master yn gwasanaethu Scrum Team mewn sawl ffordd, gan gynnwys:●●●●

Hyfforddi aelodau'r tîm mewn hunanreolaeth a thraws‐swyddogaeth;
Helpu Scrum Team i ganolbwyntio ar greu cynyddiadau gwerth uchel sy'n bodloni'r
Definition of Done;
Achosi dileu rhwystrau i gynnydd Scrum Team; a,Sicrhau bod holl ddigwyddiadau Scrum yn digwydd a'u bod yn gadarnhaol, yn gynhyrchiol,
ac yn cael eu cadw o fewn y blwch amser.

Mae'r Scrum Master yn gwasanaethu Product Owner mewn sawl ffordd, gan gynnwys:

6

●
●
●
●

Helpu i ddod o hyd i dechnegau ar gyfer diffinio Product Goal yn effeithiol a rheoli ProductBacklog;
Helpu Scrum Team i ddeall yr angen am eitemau Product Backlog clir a chryno;
Helpu i sefydlu cynllunio cynnyrch empirig ar gyfer amgylchedd cymhleth; a,Hwyluso cydweithredu â rhanddeiliaid yn ôl y gofyn neu yn ôl yr angen.

Mae'r Scrum Master yn gwasanaethu'r sefydliad mewn sawl ffordd, gan gynnwys:●●●●

Arwain, hyfforddi a hyfforddi'r sefydliad i fabwysiadu Scrum;
Cynllunio a chynghori gweithrediadau Scrum o fewn y sefydliad;
Helpu gweithwyr a rhanddeiliaid i ddeall a gweithredu dull empirig ar gyfer gwaith cymhleth;a,Dileu rhwystrau rhwng rhanddeiliaid a Scrum Teams.

Digwyddiadau Scrum
Mae'r Sprint yn gynhwysydd ar gyfer pob digwyddiad arall. Mae pob digwyddiad yn Scrum yn gyfle ffurfiol iarchwilio ac addasu arteffactau Scrum. Mae'r digwyddiadau hyn wedi'u cynllunio'n benodol i alluogi'rtryloywder sydd ei angen.
Mae methu â gweithredu unrhyw ddigwyddiadau fel y rhagnodwyd yn arwain at golli cyfleoedd i archwilio
ac addasu. Defnyddir digwyddiadau yn Scrum i greu rheoleidd‐dra ac i leihau'r angen am gyfarfodydd nad
ydynt wedi'u diffinio yn Scrum.
Yn optimaidd, cynhelir pob digwyddiad ar yr un pryd a lle i leihau cymhlethdod.

Y Sprint
Mae’r Sprints yn curiad calon Scrum, lle mae syniadau'n cael eu troi'n werth.
Maent yn ddigwyddiadau hyd sefydlog o fis neu lai i greu cysondeb. Mae Sprint newydd yn cychwyn ynsyth ar ôl diwedd y Sprint blaenorol.
Mae'r holl waith sydd ei angen i gyflawni'r Product Goal, gan gynnwys Sprint Planning, Daily Scrums,
Sprint Review, ac Sprint Retrospective, yn digwydd o fewn Sprints.
Yn ystod y Sprint:●●●●

Ni wneir unrhyw newidiadau a fyddai'n peryglu'r Sprint Goal;
Nid yw ansawdd yn gostwng;
Mae'r Product Backlog yn cael ei fireinio yn ôl yr angen; a,gellir egluro ac aildrafod y cwmpas gyda Product Owner wrth i ragor gael ei ddysgu.
7Mae Sprintiau yn galluogi rhagweladwyedd trwy sicrhau arolygu ac addasu cynnydd tuag at Product
Goal o leiaf bob mis calendr. Pan fydd gorwel Sprint yn rhy hir gall y Sprint Goal ddod yn annilys, gall
cymhlethdod godi, a gall risg gynyddu. Gellir defnyddio Sprints byrrach i gynhyrchu mwy o gylchoedd
dysgu a chyfyngu'r risg o gost ac ymdrech i amserlen lai. Gellir ystyried pob Sprint yn brosiect byr.
Mae arferion amrywiol yn bodoli i ragweld cynnydd, megis llosgiadau, llosgiadau, neu lifau cronnus. Er
eu bod yn ddefnyddiol, nid yw'r rhain yn disodli pwysigrwydd empirigiaeth. Mewn amgylcheddau
cymhleth, ni wyddys beth fydd yn digwydd. Dim ond yr hyn sydd eisoes wedi digwydd y gellir ei
ddefnyddio ar gyfer gwneud penderfyniadau sy'n edrych i'r dyfodol.
Gallai Sprint gael ei ganslo os daw'r Sprint Goal i ben. Dim ond Product Owner sydd â'r awdurdod iganslo'r Sprint.

Sprint Planning
Mae Sprint Planning yn cychwyn y Sprint trwy osod allan y gwaith i'w wneud ar gyfer y Sprint. Mae'r
cynllun canlyniadol hwn yn cael ei greu gan waith cydweithredol holl Scrum Team.
Mae Product Owner yn sicrhau bod mynychwyr yn barod i drafod yr eitemau Product Backlog pwysicaf asut maent yn mapio i'r Product Goal. Gall Scrum Team hefyd wahodd pobl eraill i fynychu Sprint Planningi roi cyngor.
Mae Sprint Planning yn mynd i'r afael â'r pynciau canlynol:

Pwnc Un: Pam mae'r Sprint hwn yn werthfawr?
Mae Product Owner yn cynnig sut y gallai'r cynnyrch gynyddu ei werth a'i ddefnyddioldeb yn y Sprintpresennol. Yna mae holl Scrum Team yn cydweithio i ddiffinio Sprint Goal sy'n cyfleu pam mae'r Sprint
yn werthfawr i randdeiliaid. Rhaid cwblhau'r Sprint Goal cyn diwedd y Cynllun Sprint.

Pwnc Dau: Beth Gellir ei Wneud y Sprint hwn?
Trwy drafod gyda Product Owner, mae'r Developers yn dewis eitemau o'r Product Backlog i'w
cynnwys yn y Sprint cyfredol. Gall Scrum Team fireinio'r eitemau hyn yn ystod y broses hon, sy'ncynyddu dealltwriaeth a hyder.
Gall fod yn heriol dewis faint y gellir ei gwblhau o fewn Sprint. Fodd bynnag, po fwyaf y mae'r
Developers yn ei wybod am eu perfformiad yn y gorffennol, eu gallu sydd ar ddod, a'u Definition ofDone, y mwyaf hyderus y byddant yn eu rhagolygon Sprint.

Pwnc Tri: Sut bydd y gwaith a ddewiswyd yn cael ei wneud?
Ar gyfer pob eitem Product Backlog a ddewiswyd, mae'r Developers yn cynllunio'r gwaith angenrheidiol
8

i greu Increment sy'n cwrdd â'r Definition of Done. Gwneir hyn yn aml trwy ddadelfennu eitemau
Product Backlog yn eitemau gwaith llai o ddiwrnod neu lai. Mater i'r Developers yn unig fydd
penderfynu sut y gwneir hyn. Nid oes neb arall yn dweud wrthynt sut i droi eitemau Product Backlog yn
Increments o werth.
Cyfeirir at y Sprint Goal, yr eitemau Product Backlog a ddewiswyd ar gyfer y Sprint, ynghyd â'r cynllun argyfer eu cyflawni gyda'i gilydd fel yr Sprint Backlog.
Mae Sprint Planning wedi'i neilltuo i uchafswm o wyth awr ar gyfer Sprint un mis. Ar gyfer Sprints
byrrach, mae'r digwyddiad fel arfer yn fyrrach.

Daily Scrum
Pwrpas y Daily Scrum yw archwilio cynnydd tuag at y Sprint Goal ac addasu'r Sprint Backlog yn ôl yr
angen, gan addasu'r gwaith arfaethedig.
Mae’r Daily Scrum yn ddigwyddiad 15 munud ar gyfer Developers y Scrum Team. Er mwyn lleihau
cymhlethdod, fe'i cynhelir ar yr un pryd ac yn y lle bob diwrnod gwaith o'r Sprint. Os yw Product Owner
neu'r Scrum Master yn gweithio'n weithredol ar eitemau yn yr Sprint Backlog, maent yn cymryd rhan fel
Developers.
Gall y Developers ddewis pa bynnag strwythur a thechnegau y maent eu heisiau, cyn belled â bod eu
Daily Scrum yn canolbwyntio ar gynnydd tuag at y Sprint Goal ac yn cynhyrchu cynllun gweithredu argyfer y diwrnod nesaf o waith. Mae hyn yn creu ffocws ac yn gwella hunanreolaeth.
Mae Daily Scrums yn gwella cyfathrebu, yn nodi rhwystrau, yn hyrwyddo gwneud penderfyniadau
cyflym, ac o ganlyniad yn dileu'r angen am gyfarfodydd eraill.
Nid y Daily Scrum yw'r unig amser y mae Developers yn cael addasu eu cynllun. Maent yn aml yn
cyfarfod trwy gydol y dydd ar gyfer trafodaethau manylach am addasu neu ailgynllunio gweddill gwaithy Sprint.

Sprint Review
Pwrpas yr Sprint Review yw archwilio canlyniad y Sprint a phennu addasiadau yn y dyfodol. Mae Scrum
Team yn cyflwyno canlyniadau eu gwaith i randdeiliaid allweddol a thrafodir cynnydd tuag at y ProductGoal.
Yn ystod y digwyddiad, mae Scrum Team a rhanddeiliaid yn adolygu'r hyn a gyflawnwyd yn y Sprint a'r
hyn sydd wedi newid yn eu hamgylchedd. Yn seiliedig ar y wybodaeth hon, mae mynychwyr yn
cydweithio ar beth i'w wneud nesaf. Efallai y bydd yr Product Backlog hefyd yn cael ei addasu i gwrdd âchyfleoedd newydd. Sesiwn waith yw'r Sprint Review a dylai Scrum Team osgoi ei gyfyngu i gyflwyniad.
9

Yr Sprint Review yw'r ail ddigwyddiad i'r olaf o'r Sprint ac mae mewn blwch amser hyd at bedair awr argyfer Sprint un mis. Ar gyfer Sprints byrrach, mae'r digwyddiad fel arfer yn fyrrach.

Sprint Retrospective
Pwrpas yr Sprint Retrospective yw cynllunio ffyrdd o wella ansawdd ac effeithiolrwydd.
Mae’r Scrum Team yn archwilio sut aeth y Sprint diwethaf o ran unigolion, rhyngweithio, prosesau,
offer, a'u Definition of Done. Mae elfennau a arolygir yn aml yn amrywio yn ôl y maes gwaith.
Nodir y rhagdybiaethau a'u harweiniodd ar gyfeiliorn ac archwilir eu tarddiad. Mae Scrum Team yn
trafod beth aeth yn dda yn ystod y Sprint, pa broblemau y daeth ar eu traws, a sut y cafodd yproblemau hynny eu datrys (neu na chawsant eu datrys).
Mae’r Scrum Team yn nodi'r newidiadau mwyaf defnyddiol i wella ei effeithiolrwydd. Eir i'r afael â'rgwelliannau mwyaf effeithiol cyn gynted â phosibl. Efallai y byddant hyd yn oed yn cael eu hychwanegu at
yr Sprint Backlog ar gyfer y Sprint nesaf.
Mae'r Sprint Retrospective yn cloi'r Sprint. Mae wedi'i osod mewn blwch amser hyd at dair awr argyfer Sprint o fis. Ar gyfer Sprints byrrach, mae'r digwyddiad fel arfer yn fyrrach.

Arteffactau Scrum
Mae arteffactau Scrum yn cynrychioli gwaith neu werth. Maent wedi'u cynllunio i wneud y mwyaf odryloywder gwybodaeth allweddol. Felly, mae gan bawb sy'n eu harolygu yr un sail ar gyfer addasu.
Mae pob arteffact yn cynnwys ymrwymiad i sicrhau ei fod yn darparu gwybodaeth sy'n gwella tryloywdera ffocws y gellir ei ddefnyddio i fesur cynnydd:●●●

Ar gyfer y Product Backlog, Product Goal yw hwn.
Ar gyfer y Sprint Backlog dyma'r Sprint Goal.
Ar gyfer yr Increment dyma'r Definition of Done.

Mae'r ymrwymiadau hyn yn bodoli i atgyfnerthu empiriaeth a gwerthoedd Scrum ar gyfer Scrum Teama'u rhanddeiliaid.

Product Backlog
Mae'r Product Backlog yn rhestr ddatblygol, drefnus o'r hyn sydd ei angen i wella'r cynnyrch. Dyma'r
ffynhonnell waith unigol a wneir gan Scrum Team.
Ystyrir bod eitemau Product Backlog y gall Scrum Team ei wneud o fewn un Sprint yn barod i'w dewis
mewn digwyddiad Sprint Planning. Maent fel arfer yn caffael y lefel hon o dryloywder ar ôl mireinio
10

gweithgareddau. Coethi Product Backlog yw'r weithred o dorri i lawr a diffinio ymhellach eitemau
Product Backlog yn eitemau llai a mwy manwl gywir. Mae hwn yn weithgaredd parhaus i ychwanegu m
Y Developers a fydd yn gwneud y gwaith sy'n gyfrifol am y maint. Gall Product Owner ddylanwadu ar y
Developers trwy eu helpu i ddeall a dewis cyfaddawdau.

Ymrwymiad: Product Goal
Mae Product Goal yn disgrifio cyflwr y cynnyrch yn y dyfodol a all fod yn darged i Scrum Team gynllunio
yn ei erbyn. Mae'r Product Goal yn yr Product Backlog. Daw gweddill yr Product Backlog i'r amlwg i
ddiffinio “beth” fydd yn cyflawni Product Goal.
Mae cynnyrch yn gyfrwng i sicrhau gwerth. Mae ganddo ffin glir, rhanddeiliaid hysbys,
defnyddwyr neu gwsmeriaid sydd wedi'u diffinio'n dda. Gallai cynnyrch fod yn wasanaeth, yn
gynnyrch ffisegol, neu'n rhywbeth mwy haniaethol.
Product Goal yw amcan hirdymor Scrum Team. Rhaid iddynt gyflawni (neu gefnu ar) un amcan cyn
ymgymryd â'r nesaf.

Sprint Backlog
Mae'r Sprint Backlog yn cynnwys y Sprint Goal (pam), y set o eitemau Product Backlog a ddewiswyd
ar gyfer y Sprint (beth), yn ogystal â chynllun gweithredu ar gyfer cyflawni'r Increment (sut).
Mae'r Sprint Retrospecftive yn gynllun gan ac ar gyfer y Developers. Mae'n ddarlun amser real hynod
weladwy o'r gwaith y mae'r Developers yn bwriadu ei gyflawni yn ystod y Sprint er mwyn cyflawni'r Sprint
Goal.
O ganlyniad, mae'r Sprint Backlog yn cael ei ddiweddaru trwy gydol y Sprint wrth i fwy gael ei ddysgu.
Dylai gynnwys digon o fanylion fel y gallant archwilio eu cynnydd yn y Daily Scrum.

Ymrwymiad: Sprint Goal
Y Sprint Goal yw'r amcan unigol ar gyfer y Sprint. Er bod y Sprint Goal yn ymrwymiad gan y Developers,
mae'n darparu hyblygrwydd o ran yr union waith sydd ei angen i'w gyflawni. Mae Sprint Goal hefyd yncreu cydlyniad a ffocws, gan annog Scrum Team i gydweithio yn hytrach nag ar fentrau ar wahân.
Mae'r Sprint Goal yn cael ei greu yn ystod y digwyddiad Sprint Planning ac yna'n cael ei ychwanegu at yr
Sprint Backlog. Wrth i'r Developers weithio yn ystod y Sprint, maen nhw'n cadw'r Sprint Goal mewn cof.
Os bydd y gwaith yn wahanol i'r disgwyl, maent yn cydweithio â Product Owner i drafod cwmpas yr
Sprint Backlog o fewn y Sprint heb effeithio ar y Sprint Goal.

Increment
Mae’r Increment yn garreg gamu goncrit tuag at Product Goal. Mae pob Increment yn
11adchwanegiad i bob Increment blaenorol ac wedi'i wirio'n drylwyr, gan sicrhau bod pob Increment
yn gweithio gyda'i gilydd. Er mwyn darparu gwerth, rhaid i'r Increment fod yn ddefnyddiadwy.
Gellir creu cynyddrannau lluosog o fewn Sprint. Cyflwynir swm y codiadau yn yr Sprint Review gan
gefnogi empiriaeth. Fodd bynnag, mae'n bosibl y caiff cynyddiad ei gyflwyno i randdeiliaid cyn
diwedd y Sprint. Ni ddylid byth ystyried yr Sprint Review fel porth i ryddhau gwerth.
Ni ellir ystyried gwaith yn rhan o gynyddiad oni bai ei fod yn bodloni'r Definition of Done.

Ymrwymiad: Definition of Done (Diffiniad o Wneud)
Mae'r Definition of Done yn ddisgrifiad ffurfiol o gyflwr y Increment pan fydd yn bodloni'r mesurau
ansawdd sy'n ofynnol ar gyfer y cynnyrch.
Y foment y mae eitem Product Backlog yn cwrdd â'r Definition of Done, mae Increment yn cael ei eni.
Mae'r Definition of Done yn creu tryloywder trwy ddarparu dealltwriaeth gyffredin i bawb o'r gwaith agwblhawyd fel rhan o'r Increment. Os nad yw eitem Product Backlog yn bodloni'r Definition of Done, ni
ellir ei ryddhau na hyd yn oed ei gyflwyno yn yr Sprint Review. Yn lle hynny, mae'n dychwelyd i'r
Product Backlog i'w ystyried yn y dyfodol.
Os yw Definition of Done ar gyfer cynyddran yn rhan o safonau'r sefydliad, rhaid i bob Scrum Team ei
ddilyn o leiaf. Os nad yw'n safon sefydliadol, mae'n rhaid i Scrum Team greu Definition of Done sy'n
briodol ar gyfer y cynnyrch.
Mae'n ofynnol i'r Developers gydymffurfio â'r Definition of Done. Os oes nifer o Scrum Teams yn
gweithio gyda'i gilydd ar gynnyrch, rhaid iddynt ddiffinio a chydymffurfio â'r un Definition of Done ar y
cyd.

12

Diwedd Nodyn
Scrum yn rhad ac am ddim ac yn cael ei gynnig yn y Canllaw hwn. Mae fframwaith Scrum, fel yr
amlinellir yma, yn ddigyfnewid. Er mai dim ond rhannau o Scrum sy'n bosibl, nid Scrum yw'r canlyniad.
Mae Scrum yn bodoli yn ei gyfanrwydd yn unig ac mae'n gweithredu'n dda fel cynhwysydd ar gyfer
technegau, methodolegau ac arferion eraill.

Diolchiadau
Pobl
O’r miloedd o bobl sydd wedi cyfrannu at Scrum, dylem dynnu sylw at y rhai a oedd yn allweddol ary dechrau: bu Jeff Sutherland yn gweithio gyda Jeff McKenna a John Scumniotales, a bu Ken
Schwaber yn gweithio gyda Mike Smith a Chris Martin, a phob un ohonynt gweithio gyda'i gilydd.
Cyfrannodd llawer o rai eraill yn y blynyddoedd i ddod a heb eu cymorth ni fyddai Scrum yn cael ei
fireinio fel y mae heddiw.

Hanes y Canllaw Scrum
Cyd‐gyflwynodd Ken Schwaber & Jeff Sutherland Scrum am y tro cyntaf yng Nghynhadledd OOPSLA ym
1995. Yn ei hanfod, roedd yn dogfennu'r hyn a ddysgwyd gan Ken a Jeff dros yr ychydig flynyddoedd
blaenorol a chyhoeddodd y diffiniad ffurfiol cyntaf o Scrum.
Mae'r Canllaw Scrum yn dogfennu Scrum fel y mae wedi'i ddatblygu, ei esblygu, a'i gynnal am 30
mlynedd a mwy gan Jeff Sutherland a Ken Schwaber. Mae ffynonellau eraill yn darparu patrymau,
prosesau a mewnwelediadau sy'n ategu fframwaith Scrum. Gall y rhain gynyddu cynhyrchiant, gwerth,creadigrwydd, a boddhad â'r canlyniadau.
Disgrifir hanes cyflawn Scrum mewn man arall. I anrhydeddu'r lleoedd cyntaf lle cafodd ei brofi, rydym
yn cydnabod Unigol Inc., Newspage, Fidelity Investments, ac IDX (GE Medical bellach).

Y Cyfieithiad
Yr oedd y canllaw yma wedi ei cyfieithu o’r fersiwn saesneg gan Ken Schwaber & Jeff Sutherland. Mae’rcyfiethiad iaith Cymraeg wedi eu arweinu gan Daniel Mathews.
Gwybodaeth Pwysig : Yn ddilyn gorchmynion Scrum.org, mae llawer o termau heb eu gyfieithu: Scrum,
Product Goal, Definition of Done, Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint
Retrospective, Sprint Goal, Scrum Team, Scrum Master, Product Owner, Developers, Product Backlog,
Sprint Backlog, Increment. Er mwyn hwyluso darllen y canllaw hwn, darperir geirfa yn Ffrangeg ar gais.

13Newidiadau o Scrum Guide 2017 i Scrum Guide 2020
Hyd yn oed yn Llai Rhagnodol
Dros y blynyddoedd, dechreuodd Scrum Guide ddod ychydig yn fwy rhagnodol. Nod fersiwn 2020 oedd dodâ Scrum yn ôl i fod yn fframwaith digon lleiaf trwy ddileu neu feddalu iaith ragnodol. ee dileu cwestiynau
Daily Scrum, meddalu iaith o amgylch priodoleddau PBI, meddalu iaith o amgylch eitemau retro yn Sprint
Backlog, adran canslo Sprint byrrach, a mwy.

Un Tîm, Yn Canolbwyntio ar Un Cynnyrch
Y nod oedd dileu'r cysyniad o dîm ar wahân o fewn tîm sydd wedi arwain at ymddygiad “procsi” neu “ni anhw” rhwng y PO a Thîm Datblygu. ar yr un amcan, gyda thair set wahanol o atebolrwydd: PO, SM, a
Developers

Cyflwyno Product Goal
Mae Scrum Guide 2020 yn cyflwyno'r cysyniad o Product Goal i roi ffocws fwy i Scrum Team tuag at amcan
gwerthfawr. Dyle pob Sprint dod â'r cynnyrch yn nes at y Product Goal cyffredinol.

Cartref ar gyfer Sprint Goal, Definition of Done, a Product Goal
Disgrifiodd Canllawiau Scrum blaenorol Sprint Goal a Definition of Done heb roi hunaniaeth iddynt mewn
gwirionedd. Gydag ychwanegiad Product Goal, mae fersiwn 2020 yn rhoi mwy o eglurder ynghylch hyn.
Mae pob un o'r tri arteffact bellach yn cynnwys 'ymrwymiadau' iddynt. Am yr Product Backlog mae’r Product
Goal, am yr Sprint Backlog yr Sprint Goal, ac mae gan yr Increment y Definition of Done (nawr heb ydyfyniadau). Maent yn bodoli i ddod â thryloywder a ffocws tuag at gynnydd pob arteffact.

Hunanreoli Dros Hunan-Drefnu
Cyfeiriodd Tywyswyr Sgrymiau Blaenorol at Dimau Datblygu fel rhai sy'n hunan-drefnu, gan ddewis pwy asut i wneud gwaith. Gyda mwy o ffocws ar Dîm Scrum, mae fersiwn 2020 yn pwysleisio Tîm Scrum sy’nrheoli ei hun, gan ddewis pwy, sut, a beth i weithio arno.

Tri Phwnc am Sprint PlanningYn ogystal â phynciau Sprint Planning “Beth” a “Sut”, mae Canllaw Scrum 2020 yn rhoi pwyslais ar drydydd
pwnc, “Pam”, gan gyfeirio at y Sprint Goal.

Symleiddio Iaith yn Gyffredinol ar gyfer Cynulleidfa Ehangach
Mae Scrum Guide 2020 wedi rhoi pwyslais ar ddileu datganiadau diangen a chymhleth yn ogystal â chaelgwared ar unrhyw gasgliad sy'n weddill ynghylch gwaith TG (ee profi, system, dyluniad, gofyniad, ac ati).
Mae'r Scrum Guide bellach yn llai na 13 tudalen.

14