A Scrum Útmutató

A Scrum egy olyan keretrendszer, amelyet komplex termékek fejlesztésére és fenntartására hoztak létre. Ez a kalauz a Scrum leírását tartalmazza, mely a Scrum szerepekből, eseményekből, munkaanyagokból és az ezeket összekötő szabályokból áll. A Scrumot Ken Schwaber és Jeff Sutherland fejlesztette ki; ezt az útmutatót is ők írták és tették elérhetővé. Ők ketten állnak a Scrum útmutató mögött.

A Scrum meghatározása

Scrum (főnév): Egy olyan keretrendszer, melynek segítségével emberek komplex problémákat tudnak adaptív módon kezelni úgy, hogy közben termelékenyen és kreatívan szállítják le a lehető legértékesebb termékeket.

A Scrum:

• Egyszerű

• Könnyen érthető

• Rendkívül nehezen művelhető mesteri szinten

A Scrum egy folyamat-keretrendszer, amit az 1990-es évek eleje óta használnak komplex termékek fejlesztésére. Nem egy termékek létrehozására kitalált folyamat vagy technika; sokkal inkább egy olyan keretrendszer, melyen belül különböző folyamatokat és technikákat lehet alkalmazni. A Scrum láthatóvá teszi a termék menedzsmentjének és a fejlesztési gyakorlatainak relatív hatékonyságát, így elősegíti annak tökéletesítését.

A Scrum keretrendszer a Scrum Csapatokból, valamint a hozzájuk rendelt szerepekből, eseményekből, munkaanyagokból (artifacts) és szabályokból áll. A keretrendszeren belül minden egyes komponens meghatározott célt szolgál, és mindegyik alapvetően szükséges a Scrum sikeréhez és használatához.

A Scrum szabályai kapcsolják össze az eseményeket, szerepköröket és a munkaanyagokat, meghatározva a köztük lévő viszonyokat és kölcsönhatásokat. A Scrum szabályait e dokumentum törzse ismerteti.

A Scrum keretrendszer használatának sajátos technikái, taktikái eltérőek lehetnek és más forrásokban találhatók meg.

A Scrum használata

A Scrumot kezdetben termékmenedzsmentre és -fejlesztésre tervezték. A 90-es évek elejétől kezdve azonban világszerte használják a módszertant az alábbi területeken:

1. Piackutatásra, termék- és technológiai lehetőségek azonosítására

2. Termékek fejlesztésére és bővítésére

3. Termékek és termék-inkrementumok kiadásra, akár naponta többszöri gyakorisággal is

4. Cloud (online, biztonságos, igény szerinti) és más operációs környezetek fejlesztésére és fenntartására

5. Termékek fenntartására és megújítására

A Scrumot használták már szoftver, hardver, beágyazott szoftver, interaktív funkciók hálózatai, önvezető járművek, iskolák, kormányok, marketing fejlesztésre, vállalatirányítás szervezésre és szinte mindenre amit a mindennapjainkban akár mint egyének, akár mint társadalom használunk.

A technológiai, piaci és környezeti komplexitások és kölcsönhatásaik villámgyors növekedésével a Scrum nap, mint nap bizonyítja hasznosságát a komplexitás kezelésében.

A Scrum különösen hatásosnak bizonyult az iteratív (ismétlődő) és inkrementális tudásátadásban. A Scrum ma már széleskörben használt termékeknél, szolgáltatásoknál, valamint a hozzájuk kapcsolódó szervezetek irányításánál.

A Scrum eszenciája az emberek kisméretű csapata. Az önálló csapat rendkívül rugalmas és alkalmazkódóképes. Ezek az erősségeik megmaradnak egyetlen, néhány vagy számos csapatot magában foglaló szervezetekben is, de csapatok olyan nagy hálózataiban is, ahol több ezer ember munkáját és produktumait fejlesztik, üzemeltetik, tartják karban és adják ki. Együttműködésüket szofisztikált fejlesztési architektúrák és kiadási környezetek segítségével oldják meg.

Amikor a Scrum Útmutatóban a „fejleszt” és „fejlesztés” szavakat használjuk, minden esetben komplex feladatokra gondolunk, mint amilyenek például a fent említett feladattípusok.

Scrum elmélet

A Scrum a tapasztaláson alapuló folyamatellenőrzési elméleten, vagy más néven empirizmuson alapul. Az empirizmus azt állítja, hogy a tudás a tapasztalatokból és az adott ismereteken alapuló döntésekből ered. A Scrum egy iteratív (ismétlődő), inkrementális megközelítést alkalmaz a kiszámíthatóság optimalizálása és a kockázat kézben tartása érdekében.

Az empirikus folyamatellenőrzés megvalósítása három pilléren nyugszik: transzparencia (átláthatóság), ellenőrzés és korrekció.

Transzparencia (Átláthatóság)

A folyamat lényeges nézőpontjainak láthatónak kell lenni azok számára, akik felelősek az eredményért. A transzparencia elve megköveteli, hogy ezeket a nézőpontokat egy közös szabvány szerint határozzák meg, hogy a minden résztvevő ugyanazzal az értelmezéssel rendelkezzen.

Például:

• Egy egyezményes nyelvet kell kialakítani a folyamatra vonatkozóan, amit meg kell osztani a résztvevők között és

• Meg kell határozni a "Kész" egyezményes, a munkát végzők és a munka eredményét átvevők által közösen elfogadott definícióját (definition of "Done").

Ellenőrzés

A Scrum felhasználóknak gyakorta kell ellenőrizniük a Scrum munkaanyagait, és a cél felé történő haladást, hogy észleljék a nem kívánatos eltéréseket. Ugyanakkor az ellenőrzés nem lehet olyan gyakori, hogy akadályozza a munkát. Az ellenőrzés akkor a legeredményesebb, ha képzett elemzők hajtják végre éppen a munkafolyamat megkezdése előtt.

Korrekció

Amennyiben egy elemző megállapítja, hogy egy folyamat egy vagy több szempontból a megengedett határokon kívül esik, és azt, hogy a végtermék nem lesz megfelelő, akkor módosítani kell a folyamaton, vagy kidolgozás alatt lévő anyagon. A további eltérések minimalizálása érdekében a módosítást mihamarabb el kell végezni.

A Scrum négy formális eseményt ír elő a vizsgálatra és az alkalmazkodásra, melyek kifejtését a „Scrum események” fejezet tartalmazza.

Sprint Tervezés (Sprint Planning)

Napi Scrum (Daily Scrum)

Sprint Áttekintés (Sprint Review)

Sprint Visszatekintés (Sprint Retrospective)

Scrum Értékek

Amikor az elkötelezettség, bátorság, fókusz, nyíltság és tisztelet értékeit megéli és megvalósítja a Scrum Csapat, a Scrumpillérei: a transzparencia (átláthatóság), ellenőrzés (inspekció) és korrekció (adaptálás) életre kelnek és építik a bizalmat mindenki számára. A Scrum Csapat tagjai folyamatosan tanulják és fedezik fel ezeket az értékeket a Scrum eseményekkel, szerepekkel és munkaanyagokkal (artifacts) való munka során.

A Scrum sikeres használata azon múlik, hogy a résztvevők egyre gyakorlottabbak legyenek az öt érték megélésében. A résztvevők személyesen kötelezettséget vállalnak a Scrum Csapat céljainak elérésére. A Scrum Csapat tagjainak van bátorsága a helyes cselekedetek végrehajtására és hogy nehéz problémákon dolgozzanak. Mindenki a Sprintre és a Scrum Csapat céljaira fókuszálva végzi munkáját. A Scrum Csapat és megrendelő oldal (stakeholders) megegyeznek, hogy nyíltan kommunikálnak a munkáról, és a munka végzése közben felmerülő kihívásokról. A Scrum Csapat tagjai tisztelik egymást, és elfogadják egymást, mint független, hozzáértő embereket.

A Scrum Csapat

A Scrum Csapat a Terméktulajdonosból, Fejlesztőcsapatból és Scrum Mesterből (Scrum Master) áll. A Scrum Csapatok önszerveződőek és kereszt-funkcionálisak. Az önszerveződő csapatok döntik el, hogy milyen módon tudják a legjobban elvégezni a munkát szemben azzal, hogy valaki kívülről irányítaná őket. A kereszt-funkcionális csapatok a munka elvégzéséhez minden szükséges kompetenciával rendelkeznek, és nem függnek olyanoktól, akik nem részei a csapatnak. A csapat modellt a Scrumban a rugalmasság, a kreativitás és a produktivitás optimalizálása érdekében tervezték meg.

A Scrum Csapatok iteratív módon és fokozatos lépésekben (inkrementálisan) szállítják a terméket, maximalizálva a visszajelzés lehetőségét. A “Kész” termék fokozatos leszállításai biztosítják, hogy a termékből mindig elérhető egy jó eséllyel hasznosítható változat.

A Terméktulajdonos

A Terméktulajdonos (Product Owner) felelős a termék értékének maximalizálásáért és a Fejlesztőcsapat munkájáért. Ennek megvalósítása szervezeti formától, Scrum Csapatoktól és egyénektől függően nagyon eltérő lehet.

A Terméktulajdonos az egyetlen személy, aki felelős a Termék Backlog (Termék Teendőlista - Product Backlog) kezeléséért, mely a következőket foglalja magában:

• A Termék Backlog tételeinek egyértelmű leírása,

• A Termék Backlogban szereplő tételeknek sorba rendezése aszerint, hogy azok a célok és küldetések legjobb, leghatékonyabb elérését szolgálják,

• A Fejlesztőcsapat által végzett munka értékének optimalizálása,

• Annak biztosítása, hogy a Termék Backlog elérhető, könnyen áttekinthető és mindenki számára világos legyen, továbbá egyértelmű legyen, hogy a Scrum Csapatnak mi lesz a következő munkája, valamint

• Annak biztosítása, hogy a Fejlesztőcsapat legalább a munkavégzéshez szükséges szinten érti a Termék Backlog egyes tételeit.

A Terméktulajdonos saját maga is elvégezheti a fenti teendőket, vagy a Fejlesztőcsapattal is elvégeztetheti azokat, viszont ez utóbbi esetben is a Terméktulajdonosé a felelősség.

A Terméktulajdonos nem egy bizottság, hanem egyetlen személy. A Terméktulajdonos képviselheti egy bizottság kívánságait a Termék Backlogban, de ha a bizottság meg szeretné változtatni valamelyik Termék Backlog elem prioritását, akkor ezt csak a Terméktulajdonoson keresztül teheti meg.

Ahhoz, hogy a Terméktulajdonos sikeresen el tudja végezni a feladatát, a teljes szervezetnek tiszteletben kell tartania a döntéseit. A Terméktulajdonos döntései a Termék Backlog tartalmában és az elemek sorrendjében nyilvánulnak meg. Senki nincs felhatalmazva arra, hogy a Fejlesztőcsapattal a meghatározottól eltérő követelmény-rendszer szerint dolgoztasson, és a Fejlesztőcsapat sem fogadhat el utasítást senki mástól.

A Fejlesztőcsapat

A Fejlesztőcsapat olyan szakemberekből áll, akik azon dolgoznak, hogy minden egyes Sprint végén leszállítható legyen a termék egy “Kész” potenciálisan kibocsátható Inkrementuma. Az Inkrementum elkészítésében csak a Fejlesztőcsapat tagjai vesznek részt.

A Fejlesztőcsapatokat úgy állítja össze és hatalmazza fel a szervezet, hogy ők maguk szervezzék és menedzseljék saját munkájukat. Az így létrejövő szinergia optimalizálja a Fejlesztőcsapat hatékonyságát és termelékenységét.

A Fejlesztőcsapatok az alábbi tulajdonságokkal rendelkeznek:

Önszerveződőek. Senki – még a Scrum Mester – sem mondja meg a Fejlesztőcsapatnak, hogy miként hozzanak létre a Termék Backlogból potenciálisan szállítható funkcionalitást tartalmazó Inkrementumokat,

A Fejlesztőcsapatok kereszt-funkcionálisak, és csapatként minden olyan ismerettel és készséggel rendelkeznek, ami szükséges a termék Inkrementumok elkészítéséhez,

A Scrum a „Fejlesztő”-n kívül nem alkalmaz külön titulust a Fejlesztőcsapat egyes tagjaira, függetlenül attól, hogy egyénenként milyen tevékenységet végeznek. Ez alól a szabály alól nincs kivétel.

A Fejlesztőcsapatokban nincsenek alcsoportok egyes célfeladatok – pl. tesztelés vagy üzleti elemzés

– elvégzésére; ez alól a szabály alól nincs kivétel, illetve

A Fejlesztőcsapatban az egyes tagok speciális ismeretekkel, készségekkel és szakterületi tudással rendelkezhetnek, de a felelősség az egész Fejlesztőcsapatra, mint egy egységre hárul.

A Fejlesztőcsapat mérete

A Fejlesztőcsapat optimális mérete elég kicsi ahhoz, hogy a csapat gyors reagálású maradjon, de elég nagy ahhoz, hogy jelentős mennyiségű munkát tudjon végezni egy Sprint alatt. Háromnál kevesebb tag esetében csökken az interakció mértéke, és ez alacsonyabb termelékenységhez vezet. A kisebb csapatok a Sprint során készségkorlátokba ütközhetnek, aminek következtében előfordulhat, hogy nem tudnak a Sprint végére egy potenciálisan kiadható inkrementumot készíteni. Kilencnél több tag már túl sok koordinációt igényel. A tapasztalati úton fejlesztett folyamatok kezelése nagy létszámú

Fejlesztőcsapatok esetében túl bonyolulttá, nehézkessé válik. A Terméktulajdonos és a Scrum Mester nem számít bele ebbe a létszámba kivéve, ha ők is dolgoznak a Sprint Backlog (Sprint Teendőlista) megvalósításában.

A Scrum Mester

A Scrum Mester a Scrum népszerüsítéséért és támogatásáért felelős, a Scrum Útmutatóban foglaltaknak megfelelően. A Scrum Mesterek ezt az által érik el, hogy mindenkinek segítenek megérteni a Scrum elméletét, gyakorlati elemeit, szabályait és értékeit.

A Scrum Mester a Scrum Csapat szolgáló-vezetője (servant-leader). A Scrum Mester segíti a Scrum Csapaton kívülieknek megérteni azt, hogy mely Scrum Csapattal való interakciójuk lesz hasznos és melyik nem. A Scrum Mester mindenkinek segít oly módon megváltoztatni ezeket az interakciókat azért, hogy azok a Scrum Csapat által létrehozott értéket maximalizálják.

A Scrum Mester szolgáltatásai a Terméktulajdonos felé

A Scrum Mester többféle módon segíti a Terméktulajdonost, többek között azzal, hogy:

Biztosítja a célok, feladatok (scope) és a termék üzleti területe lehető legteljesebb megértését a Scrum Team minden tagja számára,

Módszereket alakít ki a Termék Backlog hatékony kezelésére,

Segít megérteni a Scrum Csapatnak, hogy miért szükséges, hogy a Termék Backlog elemei világosak, tömörek legyenek,

Megérti a terméktervezést empirikus környezetben,

Biztosítja, hogy a Terméktulajdonos tudja, hogy miként rendezze a Termék Backlogot az érték maximalizálása érdekében

Érti és gyakorolja az agilitást, valamint

Kérés, illetve szükség esetén előmozdítja a Scrum események lebonyolítását.

A Scrum Mester szolgáltatásai a Fejlesztőcsapat felé

A Scrum Mester többféle módon segíti a Fejlesztőcsapatot, beleértve:

• Felkészíti, támogatja a Fejlesztőcsapatot az önszerveződésben és a kereszt-funkcionalitás kialakításában,

• Segíti a Fejlesztőcsapatot magas színvonalú termékek előállításában,

• Eltávolítja a Fejlesztőcsapat útjába kerülő akadályokat,

• Kérés, illetve szükség esetén előmozdítja a Scrum események lebonyolítását, és

• Segíti a Fejlesztőcsapatot olyan szervezeti környezetben, ahol még nem teljes mértékben vezették be és értették meg a Scrumot.

A Scrum Mester szolgáltatásai a Szervezet felé

A Scrum Mester többféle módon segíti a Szervezetet, beleértve:

• Vezeti és képzi a szervezetet a Scrum elsajátításában,

• Megtervezi a Scrum megvalósítását a szervezetben,

• Segít az alkalmazottaknak és az megrendelő oldal szereplőinek megérteni és elfogadni a Scrumot és az empirikus termékfejlesztést,

• Olyan változásokat eszközöl, melyek növelik a Scrum Csapat termelékenységét, és

• Együttműködik a többi Scrum Mesterrel annak érdekében, hogy növelje a Scrum alkalmazásának hatékonyságát a szervezetben.

Scrum Események

Az előírt eseményeket a Scrumban arra használják, hogy rendszerességet, szabályszerűséget teremtsenek, és hogy minimalizálják az egyéb, Scrumban nem meghatározott megbeszélések szükségességét. A Scrum időkorlátos (time-boxed) eseményeket használ, ami azt jelenti, hogy minden eseménynek van egy maximális hossza. Amint a Sprint megkezdődött, annak időtartama rögzített, melyet nem lehet csökkenteni vagy növelni. A többi esemény véget érhet, amint az esemény elérte célját (akár az időkorlát elérése előtt), így biztosítva, hogy az időveszteséget kizárva csak a szükséges időmennyiséget használtuk fel.

Magán a Sprinten kívül, ami az összes többi esemény gyűjtője, minden egyes Scrum-esemény egy formális lehetőség valaminek az ellenőrzésére és korrekciójára. Ezeket az eseményeket kifejezetten úgy tervezték meg, hogy biztosítani tudják a kritikus átláthatóságot és ellenőrizhetőséget. Ezen események bármelyikének elhagyása csökkenti az átláthatóságot, és elvész az ellenőrzés és a korrekció lehetősége.

A Sprint

A Scrum lelke a legfeljebb egy hónapig tartó Sprint, melynek időtartama alatt előáll egy “Kész”, használható és potenciálisan kibocsátható termék Inkrementum. A Sprintek hossza legjobb esetben a teljes fejlesztési idő során azonos. Az előző Sprint lezárása után azonnal egy újabb Sprint kezdődik.

A Sprintek Sprint Tervezésből, Napi Scrumokból, a fejlesztési munkából, a Sprint Áttekintésből és a Sprint Visszatekintésből épülnek föl.

A Sprint során:

• Nem történnek olyan változtatások, melyek veszélyeztetik a Sprint Célját,

• A minőségi célok nem csökkennek, és

• A Terméktulajdonos és a Fejlesztőcsapat újratárgyalhatja és tisztázhatja a Feladatokat (Scope) az időközben szerzett ismeretek alapján.

Minden egyes Sprint egy hónapnál nem hosszabb horizonttal rendelkező projektnek tekinthető. Hasonlóan a projektekhez, a Sprintek is valamilyen cél elérését szolgálják. Minden egyes Sprint tartalmaz egy meghatározást, ami leírja, hogy minek kell megvalósulnia, egy modellt és egy rugalmas tervet, ami irányt mutat a megvalósításban. A Sprint részének tekintjük továbbá az elvégzett munkát és az eredményül kapott terméket.

A Sprintek időtartama egy naptári hónapra korlátozott. Ha a Sprint horizontja túl hosszú, megváltozhat a megvalósítandó dolog specifikációja, emelkedhet a komplexitása és nőhet a kockázat. A Sprintek úgy biztosítják a tervezhetőséget, hogy legalább minden naptári hónapban egyszer ellenőrzik a Sprint Cél felé haladást, és szükség esetén kiigazítják a folyamatot. A Sprintek a kockázatot is egy naptári hónap költségére korlátozzák.

Egy Sprint lefújása

A Sprintet az időkorlát lejárta előtt le lehet fújni. Erre kizárólag a Terméktulajdonosnak van joga, jóllehet, ezt a megrendelő oldali résztvevők, a Fejlesztőcsapat vagy a Scrum Mester befolyására is teheti.

Egy Sprintet akkor is törölhetnek, ha a Sprint Cél elavul, okafogyottá válik. Ilyen akkor fordulhat elő, ha a cég irányt változtat, vagy ha a piaci vagy technológiai feltételek megváltoznak. Általánosságban elmondható, hogy egy Sprintet olyan esetekben érdemes lefújni, ha az adott körülmények között már nincs értelme folytatni. Ugyanakkor a Sprintek rövidsége miatt a törlésnek ritkán van értelme.

Amikor lefújnak egy Sprintet, minden befejezett és “Kész” Termék Backlog tételt felülvizsgálnak. Ha a munka egy része potenciálisan kibocsátható, a Terméktulajdonos általában elfogadja azt. Az összes félkész Termék Backlog tételt ezután újrabecsülik és visszateszik a Termék Backlogba. Az ezeken elvégzett munka hamar veszít értékéből, és gyakran kell új becslést készíteni.

A Sprint-törlések jelentős erőforrásokat emésztenek fel, mivel mindenkinek át kell szerveződnie egy másik Sprint Tervezésre, hogy egy új Sprintet kezdjenek el. A Sprint lefújása gyakran nyomasztó a Scrum Csapat számára, és a valóságban ritkán fordul ilyen elő.

Sprint Tervezés

A Sprintben végzendő munkát a Sprint Tervezésen tervezik meg. Ez a terv a teljes Scrum Csapat közös munkájának eredménye.

A Sprint Tervezés időtartama egy hónapos Sprint esetében legfeljebb nyolc óra. Rövidebb Sprintek esetén az esemény időtartama általában kisebb. A Scrum Mester biztosítja, hogy az esemény megtörténjen és a résztvevők megértsék annak célját. A Scrum Mester ráneveli a Scrum Csapatot az időkorlátok betartására.

A Sprint Tervezés a következő kérdésekre válaszol:

• Mit fog tartalmazni a következő Sprint eredményeképpen szállítandó Inkrementum?

• Hogyan lehet elvégezni az Inkrementum előállításához szükséges munkát?

Első kérdéskör: Mi fog elkészülni ebben a Sprintben?

A Fejlesztőcsapat azon dolgozik, hogy felvázolja a Sprint során megvalósítandó funkcionalitást. A Terméktulajdonos bemutatja a Sprint során elérendő célt és azokat a Termék Backlog tételeket, amelyek megvalósításával a Sprint eléri a Sprint Célt. A teljes Scrum Csapat együttműködik a Sprintben elvégzendő munka megértésének érdekében.

Ennek a megbeszélésnek a bemeneti elemei a Termék Backlog, a legutóbbi termék Inkrementum, a

Fejlesztőcsapat tervezett kapacitása a Sprint ideje alatt, valamint a Fejlesztőcsapat korábbi teljesítménye.

Az, hogy az adott Sprint számára a Termék Backlogból hány tételt választanak ki, egyedül a Fejlesztőcsapaton múlik. Kizárólag a Fejlesztőcsapat tudhatja, hogy mit képes végrehajtani a soron következő Sprintben.

Miután a Fejlesztőcsapat előrejelezte, hogy a Termék Backlog mely elemeit fogja leszállítani a Sprint során, a Scrum Csapat elkészíti a Sprint Célt. A Sprint Cél a Sprintben végrehajtásra kiválasztott Termék

Backlog elemek megvalósításával elért célkitűzés, a Sprint során előállított termék Inkrementum tárgyának megfogalmazása. A Sprint Cél iránytűként szolgál a Fejlesztőcsapatnak abban a tekintetben, hogy a csapat a Sprint során végig, egyértelműen a meghatározott cél irányába haladjon.

Második kérdéskör: Hogyan készül el a kiválasztott munka?

Miután a Sprint Célját meghatározta és a Sprintbe kerülő Termék Backlog tételeket kiválasztotta, a Fejlesztőcsapat eldönti, hogy a Sprint során miként építi be ezt a funkcionalitást a “Kész” termék inkrementumba. Az erre a Sprintre kiválogatott Termék Backlog tételeket, valamint ezek leszállítási tervét együttesen Sprint Backlognak (Sprint Teendőlista) nevezik.

A Fejlesztőcsapat általában a Termék Backlog működő termék inkrementummá konvertálásához szükséges feladatok meghatározásával és a rendszer megtervezésével kezdi meg a munkát. A munka mennyiség- és becsült ráfordítás szerint is változhat. Mindamellett a Sprint Tervezés során elegendő mennyiségű kivitelezendő munkát terveznek meg a Fejlesztőcsapat részére annak érdekében, hogy megalapozottan előre tudják vetíteni, hogy mit vélnek elvégezhetőnek a soron következő Sprint alatt. A megbeszélés végére a Fejlesztőcsapat a Sprint első napjaira tervezett feladatokat gyakran egy napos vagy annál kisebb részekre bontja le. A Fejlesztőcsapat önszerveződve vállalja el a Sprint Backlogban szereplő egyes feladatokat a Sprint Tervezés alatt, valamint amennyire szükséges, a Sprint közben is.

A Terméktulajdonos segíthet tisztázni a kiválasztott Termék Backlog tételeket és kompromisszumokat köthet. Ha a Fejlesztőcsapat úgy ítéli meg, hogy túl sok vagy túl kevés az elvégzendő munka, újratárgyalhatja a kiválasztott Termék Backlog tételeket a Terméktulajdonossal. A Fejlesztőcsapat másokat is meghívhat a megbeszélésre, hogy technikai vagy szakterületi tanácsokat adjanak.

A Sprint Tervezés végére a Fejlesztőcsapatnak el kell tudni magyarázni a Terméktulajdonosnak és a Scrum Mesternek, hogy miként szándékozik önszerveződő csapatként dolgozni a Sprint Cél megvalósítása és az elvárt inkrementum elkészítése érdekében.

Sprint Cél

A Sprint Cél a Sprinthez rendelt célkitűzés, mely a Termék Backlog megvalósításával érhető el. Irányt ad a Fejlesztőcsapatnak azzal kapcsolatban, hogy miért fejlesztik az inkrementumot. A Sprint Tervezés során kerül meghatározásra. A Sprint Cél enged némi rugalmasságot a Fejlesztőcsapatnak a Sprint során megvalósított funkcionalitás kapcsán. A kiválasztott Termék Backlog tételek egy összefüggő funkcionalitást jelentenek, amelyet a Sprint Cél fogalmaz meg. A Sprint Célt jelentheti bármely más összefüggés is, amely a Fejlesztőcsapatot külön kezdeményezések helyett közös munkára készteti.

A Fejlesztőcsapat a Sprint Célt tartja szem előtt a munka során. A Sprint Cél elérése érdekében hozza létre a funkcionalitást és a technológiát. Ha kiderül, hogy a munka eltér attól, mint amire a Fejlesztőcsapat számított, a Fejlesztőcsapat a Terméktulajdonossal újratárgyalja a Sprint Backlog terjedelmét (scope) a Sprintben.

Napi Scrum

A Napi Scrum a Sprint minden napján megtartott, maximum 15 perc időtartamú megbeszélés, ahol a Fejlesztőcsapat megtervezi a következő 24 órát. Ezt a legutóbbi Napi Scrum megbeszélés óta elvégzett feladatok ellenőrzésével és az elvégzendő feladatok előrejelzésével teszi meg, így optimalizálva a csapat együttműködését és teljesítményét. A Napi Scrumot minden nap ugyanabban az időben, ugyanazon a helyen tartják az egyszerűség és hatékonyság elősegítése érdekében.

A Napi Scrum során a Fejlesztőcsapat ellenőrzi a Sprint Célhoz vezető folyamat haladását és azt, hogy a haladás tendenciája miként változik a Sprint Backlogban szereplő munka teljesítése felé. A Napi Scrum maximálja annak a valószínűségét, hogy a Fejlesztőcsapat eléri a Sprint Célt. A Fejlesztőcsapatnak minden nap meg kell értenie, hogy önszerveződő csapatként hogyan szándékozik együtt dolgozni a Sprint Cél eléréséért és azért, hogy a Sprint végéig létrehozza a várható Inkrementumot.

A megbeszélés menetét a Fejlesztőcsapat határozza meg. Amennyiben a Sprint Célhoz vezető haladásra összpontosít, a megbeszélés többféle módon folyhat. Néhány Fejlesztőcsapat kérdéseket használ, amíg más csapatok inkább beszélgetnek. Például az alábbi kérdéseket lehet használni:

• Mit sikerült elvégeznem tegnap, ami a Fejlesztőcsapatot segíti a Sprint Cél elérésében?

• Mit fogok tenni ma, ami a Fejlesztőcsapatot segíti a Sprint Cél elérésében?

• Látok-e akadályozó tényezőt, ami gátol engem vagy a Fejlesztőcsapatot a Sprint Cél elérésében?

A Fejlesztőcsapat vagy egyes csapattagok gyakran közvetlenül a Napi Scrum után részletesen megbeszélik a Napi Scrumon felmerült kérdéseket, vagy áttervezik a Sprintben hátralévő munkát.

A Scrum Mester biztosítja azt, hogy a Fejlesztőcsapat tagjai minden nap megtartsák a megbeszélést, de a Fejlesztőcsapat felelős a Napi Scrum levezetéséért. A Scrum Mester tanítja meg a Fejlesztőcsapatnak, hogy miként tudják a Napi Scrumot a 15 perces időkereten belül megtartani.

A Napi Scrum a Fejlesztőcsapat saját, belső megbeszélése. Ha mások is részt vesznek rajta, a Scrum Mester ügyel arra, hogy ne zavarják meg a megbeszélés menetét.

A Napi Scrum javítja a kommunikációt, szükségtelenné tesz egyéb megbeszéléseket, azonosítja és így eltávolíthatóvá teszi a fejlesztés útjába kerülő akadályokat, kihangsúlyozza és elősegíti a gyors döntéshozatalt és növeli a Fejlesztőcsapat tudását. Ez egy, a munka haladásának elemzése és hangolása szempontjából kulcsfontosságú megbeszélés.

Sprint Áttekintés

A Sprint Áttekintést (Sprint Review) a Sprint végén tartják azzal a céllal, hogy ellenőrizzék az

Inkrementumot és szükség esetén módosítsák a Termék Backlogot. A Sprint Áttekintésen a Scrum Csapat tagjai és az megrendelő oldal (stakeholders) egyeztetik, hogy mi történt a Sprint során. Ezt és a Sprint során a Termék Backlogban történt változásokat alapul véve a résztvevők egyeztetik a következő időszakban végrehajtandó, optimális/maximális értéket képviselő teendőket. Ez egy informális megbeszélés, melynek célja nem a projekt státuszának riportolása, hanem hogy az Inkrementum bemutatásán keresztül visszajelzés érkezzen a megrendelő oldal (stakeholders) részéről, valamint hogy erősítse az együttműködést a két oldal között.

Ennek a megbeszélésnek az időtartama egy hónapos sprint esetén maximum négy órára korlátozódik. Rövidebb Sprintek esetében általában rövidebb ideig tart. A Scrum Mester gondoskodik arról, hogy ez az esemény létrejöjjön és a résztvevők megértsék annak célját. A Scrum Mester mindenkit figyelmeztet az időkorlát betartására.

A Sprint Áttekintés az alábbi elemeket tartalmazza:

• A résztvevői kör a Scrum Csapatból és a Termék Tulajdonos által meghívott kulcs érintettekből

áll,

• A Terméktulajdonos megállapítja, hogy melyik Termék Backlog tétel lett “Kész” és melyik nem lett “Kész”,

• A Fejlesztőcsapat megvitatja, mi ment jól a Sprint során, milyen problémákba futott bele, és hogyan oldotta meg azokat,

• A Fejlesztőcsapat szemlélteti a “Kész” munkát, és válaszol az inkrementummal kapcsolatos kérdésekre,

• A Terméktulajdonos bemutatja a Termék Backlog aktuális állapotát, előrevetíti a várható befejezési dátumokat az addigi haladás alapján (amennyiben ez szükséges),

• Az összes résztvevő közös munkával meghatározza, hogy mik legyenek a következő feladatok, így a Sprint Áttekintés eredménye értékes bemenetként szolgál a következő Sprint Tervezéshez,

• Annak áttekintése, hogy a piac illetve a termék várható használata megváltoztatta-e azt, hogy mik a soron következő, legnagyobb értéket szállító tennivalók, és

• Az ütemezés, költségvetés, várható képességek, funkciók és a piac áttekintése a termék következő release-ére vonatkozóan.

A Sprint Áttekintés eredménye egy módosított Termék Backlog, ami meghatározza a következő Sprint során megvalósítani tervezett Termék Backlog tételeket. A Termék Backlog teljes körűen is módosítható, annak érdekében, hogy az akár az új piaci lehetőségeknek is megfeleljen.

Sprint Visszatekintés

A Sprint Visszatekintés (Sprint Retrospective) egy lehetőség a Scrum Csapatnak arra, hogy elemezze saját tevékenységét, és ezzel kapcsolatban egy fejlesztési tervet készítsen, amit a következő Sprintek során megvalósít.

A Sprint Visszatekintés a Sprint Áttekintés után, a következő Sprint Tervezés előtt történik. Egy hónapos Sprintek esetén ez egy maximum háromórás időtartamra korlátozott megbeszélés. Rövidebb Sprinteknél általában rövidebb. A Scrum Mester biztosítja, hogy az esemény létrejöjjön és a résztvevők megértsék annak célját. A Scrum Mester gondoskodik arról, hogy az esemény ne lépje túl az időkorlátot. A Scrum Mester a Scrum Csapat egyenrangú tagjaként, mint a Scrum keretrendszer betartásáért felelős szereplő vesz részt a megbeszélésen.

A Sprint Visszatekintés célja, hogy:

• Megvizsgálják, hogy mennyire volt sikeres a legutóbbi Sprint az emberek, kapcsolatok, folyamatok és eszközök szempontjából,

• Azonosítsák és sorba rendezzék a jól működő főbb elemeket és a lehetséges javításokat, valamint

• Tervet készítsenek a Scrum Csapat működésének javítására.

A Scrum Mester támogatja a Scrum Csapatot abban, hogy a Scrum folyamat keretrendszerén belül folyamatosan javítsa a fejlesztés folyamatait és gyakorlatait annak érdekében, hogy a következő Sprint még hatékonyabb és élvezetesebb legyen. A Scrum Csapat minden egyes Sprint Visszatekintés során különféle terveket készít a termék minőségének javítására, a “Kész” termék definíciójának módosításával.

A Sprint Visszatekintés végére a Scrum Csapatnak meg kell határozni azokat a szükséges javításokat, amiket a következő Sprintben meg fog valósítani. Ezen javítások következő Sprintben történő megvalósítása tulajdonképpen a Scrum Csapat működésének saját megfigyelésen alapuló korrekciója. Habár javító intézkedések bármikor tehetők, a Sprint Visszatekintés egy formális lehetőséget biztosít arra, hogy a csapat magára az ellenőrzésre és korrekcióra, mint tevékenységekre összpontosítson.

Scrum Munkaanyagok

A Scrum munkaanyagai (scrum artifacts) olyan munkát vagy értéket képviselnek különböző formákban, melyek segítenek az átláthatóság megteremtésében, valamint lehetőséget nyújtanak az elemzésre és kiigazításra. A Scrum által meghatározott munkaanyagokat kifejezetten úgy tervezték meg, hogy azok maximalizálják a kulcsfontosságú információk átláthatóságát, annak érdekében, hogy a munkaanyagot mindenki ugyanúgy értelmezze.

Termék Backlog (Termék Teendőlista)

A Termék Backlog egy sorba rendezett lista, ami minden olyan dolgot tartalmaz, amire szükség lehet a termékben, valamint ez alkotja a termékkel kapcsolatos változtatási követelmények egyetlen forrását. A Terméktulajdonos felelős a Termék Backlogért, beleértve annak tartalmát, elérhetőségét és sorba rendezését.

A Termék Backlog sosem tekinthető teljesnek. A legelső változata csak a kezdetben ismert és legjobban megértett követelményeket fekteti le. A Termék Backlog a termék és a majdani használati környezet változásával összhangban fejlődik. A Termék Backlog dinamikus; folyamatosan változik annak érdekében, hogy meghatározza azt, hogy mi szükséges ahhoz, hogy a termék megfelelő, versenyképes és hasznos legyen. Ameddig egy termék létezik, a hozzá tartozó Termék Backlog is létezik.

A Termék Backlog tartalmazza az összes olyan jellemzők, funkciók, követelmények, továbbfejlesztések és javítások formájában megjelenő változtatást, amiket a termék jövőbeni kibocsátásaiban (release-eiben) el kell végezni. A Termék Backlog tételeihez leírást, sorrendi helyezést, becslést és értéket rendelnek.

Amint egy terméket elkezdenek használni és ezáltal értéket termel, valamint a piacról visszajelzések érkeznek, a Termék Backlog egy nagyobb és átfogóbb listává alakul. A követelmények folyamatosan változnak, ennek megfelelően a Termék Backlog egy élő, folyamatosan alakuló munkaanyag. Az üzleti követelményekben, piaci vagy technológiai feltételekben beállt változások hatására a Termék Backlog is változhat.

Gyakran több Scrum Csapat dolgozik együtt ugyanazon a terméken. A termékkel kapcsolatos várható munkák leírására ilyen esetekben is egyetlen Termék Backlogot használnak. Ekkor a Termék Backloghoz rendelhető egy olyan tulajdonság, melynek segítségével a backlog elemei csoportosíthatók.

A Termék Backlog finomítása abból áll, hogy további részletekkel, becsléssel egészítjük ki az elemeket, illetve változatjuk azok sorrendjét. Ez egy folyamatos tevékenység, amely során a Fejlesztőcsapat és a Terméktulajdonos közösen dolgoznak a tételek részletein. E folyamatban átnézik és felülvizsgálják a Termék Backlog tételeket. A Scrum Csapat dönti el, hogy ez a folyamat hogyan és mikor zajlik. Ez a tevékenység a Fejlesztő csapat kapacitásának általában nem több mint 10%-át köti le. Mindamellett a Termék Backlog elemeit bármikor frissítheti a Terméktulajdonos, vagy azok frissíthetők a Terméktulajdonos döntése alapján.

A sorban előbb álló tételek világosabbak és részletesebben kifejtettek, mint a hátrébb állók. A nagyobb fokú tisztázottságnak és részletezésnek köszönhetően pontosabb becslések készíthetők; minél hátrébb van a sorban egy tétel, annál kevesebb részlet ismert azzal kapcsolatban. Azok a Termék Backlog tételek, amelyekkel a Fejlesztőcsapat a soron következő Sprintben foglalkozni fog, kellően részletezettek (finomítottak, granuláltak) ahhoz, hogy bármelyiket „Kész” állapotba lehessen hozni a következő Sprint időtartama alatt. Azokat a Termék Backlog tételeket, amiket a Fejlesztőcsapat egy Sprinten belül el tud “Kész”-íteni, a Sprint Tervezésen “Kiválasztható”-nak, kiválasztásra „kész”-nek nyilvánítanak. A Termék Backlog tételek általában a feljebb leírt Termék Backlog finomítási tevékenységek során érik el ezt a fokú átláthatóságot (készültségi fokot).

Az összes becslésért a Fejlesztőcsapat felelős. A Terméktulajdonos hathat a Csapatra úgy, hogy segít megérteni és kiválasztani a kompromisszumokat, de a végső becslést azok az emberek mondják ki, akik a munkát ténylegesen el fogják végezni.

A Cél felé haladás ellenőrzése

Bármely időpontban összegezhető, hogy mennyi munka szükséges még egy adott cél eléréséhez. A Terméktulajdonos legalább minden Sprint Áttekintés alkalmával nyomon követi ezt a hátralévő munkát. Ezt a mennyiséget összehasonlítja a korábbi Sprint Áttekintések alkalmával megállapított hátralévő munkával, hogy felmérje a cél kívánt határidőre való elérése érdekében szükséges haladás ütemét. Ez az információ minden érintett számára elérhető és világos.

Korábban olyan különféle, jövőt előre jelző technikákat használtak a haladás becsléséhez, mint a burnup, burn-down és cumulative flow diagramok. Ezek hasznosnak bizonyultak, viszont nem helyettesítik a megtapasztalás fontosságát. Komplex környezetekben nem lehet megjósolni, hogy mi fog történni. Csak azokat az információkat lehet hasznosítani a jövőre vonatkozó döntéshozatalhoz, amik már megtörtént eseményeken alapulnak.

Sprint Backlog (Sprint Teendőlista)

A Sprint Backlog a Termék Backlog elemeinek egy, a Sprintre kiválasztott halmazát, plusz a termék

Inkrementum leszállítására és a Sprint Cél megvalósítására vonatkozó tervet tartalmaz. A Sprint Backlog a Fejlesztőcsapat előrejelzése arra vonatkozóan, hogy a következő Inkrementum milyen funkcionalitást fog tartalmazni, és mely feladatok végrehajtása szükséges ennek „Kész” inkrementumkénti leszállításához.

A Sprint Backlog mindazt a munkát láthatóvá teszi, melyet a Fejlesztőcsapat szükségesnek vél elvégezni a Sprint Cél teljesítéséhez. A folyamatos fejlődés elősegítésére legalább egy olyan, magas prioritású folyamat-fejlesztést tartalmaz, melyet az előző Sprint Visszatekintésen határozott meg a csapat.

A Sprint Backlog egy olyan terv, ami elég részletes ahhoz, hogy a haladásban bekövetkezett változások a

Napi Scrum során érthetőek legyenek. A Fejlesztőcsapat a Sprint során folyamatosan módosítja a Sprint

Backlogot, mely egyre tisztábbá, világosabbá válik a Sprint során. Ez úgy valósul meg, hogy amikor a Fejlesztőcsapat dolgozik a terv megvalósításán, egyre több ismeretet gyűjt össze a Sprint Cél eléréséhez szükséges munkáról.

Amikor új feladat végrehajtása válik szükségessé, a Fejlesztőcsapat felveszi azt a Sprint Backlogba. Ahogy haladnak a munkával, a becsült hátralévő ráfordítást folyamatosan frissítik. Amennyiben a terv egyes elemeit szükségtelennek tartják, eltávolítják azokat. A Sprint alatt kizárólag a Fejlesztőcsapat változtathat a Sprint Backlogon. A Sprint Backlog egy nyilvános, elérhető, valós idejű képe annak a munkának, amit a Fejlesztőcsapat a Sprint során el kíván végezni, és csak és kizárólag a Fejlesztőcsapaté.

A Sprint haladásának felügyelete

A Sprint során bármely időpontban összegezhető, hogy mennyi hátralévő munkát tartalmaz a Sprint Backlog. A Fejlesztőcsapat legalább naponta, minden Napi Scrum alkalmával nyomon követi ezt az értéket és előrevetíti a Sprint Cél elérésének valószínűségét. A Sprint során a fennmaradó munka követésével a Fejlesztőcsapat felügyelni tudja a haladását.

Inkrementum

Az Inkrementum a Sprintben leszállított Termék Backlog elemeknek és az összes megelőző Sprint során szállított inkrementumok értékének összessége. A Sprint végére az új Inkrementumnak “Kész”-nek, azaz használhatónak kell lennie, és meg kell felelnie a Scrum Csapat által meghatározott “Kész” definíciójának. Az Inkrementum egy ellenőrizhető, “Kész” munkatermék, ami a Sprint végén az empirikus működést támogatja. Az Inkrementum egy lépés egy vízió vagy cél felé. Felhasználható állapotban kell lennie független attól, hogy a Terméktulajdonos úgy dönt, hogy ténylegesen kibocsátja-e azt.

Munkaanyagok átláthatósága

A Scrum az átláthatóságon alapszik. Az értékoptimalizációt és kockázatkezelést érintő döntések a munkaanyagok aktuális állapotának függvényében születnek. Amennyiben az átláthatóság teljes, a döntéseknek szilárd alapja van. Amennyiben az átláthatóság nem teljes, ezek a döntések tévesek lehetnek, az érték csökkenhet és a kockázat nőhet.

A Scrum Mesternek a Terméktulajdonossal, Fejlesztőcsapattal és a többi bevont féllel közösen azon kell munkálkodnia, hogy megértsék, hogy a munkaanyagok átláthatósága teljes-e. Léteznek módszerek a nem teljes átláthatóság kezelésére; A Scrum Mesternek mindenkit segítenie kell, hogy a legmegfelelőbb módszert alkalmazza az átláthatóság javítása érdekében. A Scrum Mester a munkaanyagok átnézésével, minták felismerésével, a szóban elhangzottak alapján és az elvárt illetve valós eredmények közötti különbségek alapján érheti tetten a nem teljes átláthatóságot.

A Scrum Mester feladata, hogy a Scrum Csapattal és a szervezettel együtt azon dolgozzon, hogy növeljék a munkaanyagok átláthatóságát. Ez a munka általában tanulásból, meggyőzésből és változásból áll. Az átláthatóság nem jön létre az éj leple alatt, ez egy fejlődési út.

A “Kész” meghatározása

Amikor egy Termék Backlog tételt vagy egy Inkrementumot “Kész”-nek nyilvánítanak, mindenkinek pontosan kell tudnia, hogy a “Kész” definíció (Definition of “Done”) mit is jelent. Bár ez Scrum Csapatonként jelentősen eltérhet, az áttekinthetőség biztosítása érdekében a csapattagoknak közös, egyértelmű értelmezéssel kell rendelkezniük arról, mikor tekintenek egy munkát késznek. Ez a “Kész definíciója” a Scrum Csapat számára, és ezt használják annak megállapítására, hogy a termék Inkrementummal való munka mikor fejeződik be.

Ugyanez a definíció segíti a Fejlesztőcsapatot abban, hogy mennyi Termék Backlog tételt válasszon ki a Sprint Tervezésen. Minden egyes Sprintnek az a célja, hogy olyan potenciálisan használható funkcionalitással rendelkező termék Inkrementumot szállítson le, ami megfelel a Scrum Csapat aktuális “Kész” definíciójának.

A Fejlesztőcsapatok minden Sprintben egy használható funkcionalitással rendelkező termék

Inkrementumot szállítanak le. Mivel ez egy használati értékkel bíró termék, a Terméktulajdonos akár úgy is dönthet, hogy azonnal kibocsátja azt. Amennyiben egy inkrementum esetén a „kész” meghatározása a fejlesztő szervezet egyezményeinek, standardjainak és irányelveinek része, ezt minden Scrum Csapatnak – mint minimumot – követnie kell. Amennyiben a „kész” fogalma nem része a fejlesztő szervezet konvencióinak, a Scrum Csapaton belül a Fejlesztőcsapatnak kell meghatároznia a terméknek megfelelő „Kész” fogalmát. Ha ugyanazon a rendszeren vagy terméken több Scrum Csapat dolgozik, a Fejlesztőcsapatoknak közösen kell meghatározni a „Kész” fogalmát.

Minden Inkrementum alapos tesztelés után hozzáadódik a korábbi Inkrementumhoz, biztosítva azt, hogy az összes Inkrementum együttműködik.

Ahogy a Scrum Csapatok érnek, fejlődnek, általában a “Kész” definíciójuk is velük együtt fejlődik, és még magasabb minőséget biztosító, szigorúbb feltételeket fog tartalmazni. Minden egyes rendszernek vagy terméknek rendelkeznie kell egy „Kész” fogalommal, amely minden vele kapcsolatos tevékenység esetén irányadó.

Összegzés

A Scrum ingyenes és ebben az útmutatóban elérhető. A Scrum szerepkörei, munkaanyagai, eseményei és szabályai nem megváltoztathatók, és bár lehetséges a Scrum csupán egyes részeinek bevezetése is, az eredmény nem Scrum lesz. A Scrum csak a maga teljességében létezik és működik jól, más módszertanok és gyakorlatok, technikák gyűjtőjeként.

Köszönetnyilvánítás

Emberek

A több ezer ember közül, akik hozzájárultak a Scrumhoz, ki kell emelnünk azokat, akik meghatározóak voltak annak első tíz évében. Először is Jeff Sutherlandet, aki Jeff McKenna-val dolgozott, majd Ken Schwabert, aki Mike Smith-szel és Chris Martinnal dolgozott együtt. Sokan mások is hozzájárultak a további években, és az ő segítségük nélkül a Scrum nem lenne olyan kifinomult, mint ma.

Történet

Először Ken Schwaber és Jeff Sutherland mutatták be közösen a Scrumot az OOPSLA konferencián, 1995ben. Ez az előadás alapvetően azt a tudáshalmazt dokumentálta, amit Ken és Jeff szerzett a Scrum alkalmazásával az azt megelőző évek során.

A Scrum története most már hosszúnak tekinthető. Hogy elismerjük az első projekteket, ahol a módszertant kikísérletezték és csiszolták, emlékezzünk meg az Individual Inc.-ről, Fidelity Investments-ről és az IDX-ről (jelenleg GE Medical).

A Scrum Útmutató úgy mutatja be a Scrumot, ahogy azt Jeff Sutherland és Ken Schwaber fejleszti és karbantartja több, mint 20 éve. Egyéb források a Scrum keretrendszert kiegészítő mintákat, folyamatokat nyújtanak és betekintést engednek a gyakorlati alkalmazásba. Ezek optimalizálják a termelékenységet, értéket, kreativitást és büszkeséget.

Magyar nyelvre fordította: Péntek Gábor és Dr. Bodó Árpád Zsolt

Magyar nyelvre lektorálta: Sprint Consulting

Fordítói Elismerések

Ezt az útmutatót az eredeti angol verzióról a fent elismert fejlesztők biztosították. A fordításkhoz hozzájárult:

Magyar nyelvre fordította: Péntek Gábor és Dr. Bodó Árpád Zsolt Magyar nyelvre lektorálta: Sprint Consulting

Változások a Scrum Útmutatóban 2016 és 2017 között

1. Hozzáadásra került egy fejezet a Scrum használatáról:

A Scrumot kezdetben termékmenedzsmentre és -fejlesztésre tervezték. A 90-es évek elejétől kezdve azonban világszerte használják a módszertant az alábbi területeken:

1. Piackutatásra, termék- és technológiai lehetőségek azonosítására

2. Termékek fejlesztésére és bővítésére

3. Termékek és termék-inkrementumok kiadásra, akár naponta többszöri gyakorisággal is

4. Cloud (online, biztonságos, igény szerinti) és más operációs környezetek fejlesztésére és fenntartására

5. Termékek fenntartására és megújítására

A technológiai, piaci és környezeti komplexitások és kölcsönhatásaik villámgyors növekedésével a Scrum nap, mint nap bizonyítja hasznosságát a komplexitás kezelésében.

Amikor a Scrum Útmutatóban a „fejleszt” és „fejlesztés” szavakat használjuk, minden esetben komplex feladatokra gondolunk, mint amilyenek például a fent említett feladattípusok.

2. A jobb érthetőség érdekében a Scrum Mester leírása átfogalmazásra került. A mostani megfogalmazás:

3. A Scrum Mester szolgáltatásai a Terméktulajdonos felé című bekezdés a következőkkel bővült:

Biztosítja a célok, feladatok (scope) és a termék üzleti területe lehető legteljesebb megértését a Scrum Team minden tagja számára

4. A Napi Scrum fejezet első bekezdése frissült:

5. A Napi Scrum céljának jobb érthetősége érdekében a Napi Scrum fejezet az alábbi szöveggel frissült:

• Mit sikerült elvégeznem tegnap, ami a Fejlesztőcsapatot segíti a Sprint Cél elérésében?

• Mit fogok tenni ma, ami a Fejlesztőcsapatot segíti a Sprint Cél elérésében?

• Látok-e akadályozó tényezőt, ami gátol engem vagy a Fejlesztőcsapatot a Sprint Cél elérésében?

6. Tisztázásra került az időtartamok (time-boxok) helyes értelmezése:

A Scrum eseményeknek nem kell egy meghatározott ideig tartaniuk, ezért a ‘legfeljebb’ szó hozzáadásával az események maximum időtartamát határozza meg.

7. A Sprint Backlog fejezet az alábbi bekezdéssel bővült:

A folyamatos fejlődés elősegítésére legalább egy olyan, magas prioritású folyamat-fejlesztést tartalmaz, melyet az előző Sprint Visszatekintésen határozott meg a csapat.

A tisztább érthetőség kedvéért az Inkrementum fejezet az alábbi mondatokkal bővült:

Az Inkrementum egy ellenőrizhető, “Kész” munkatermék, ami a Sprint végén az empirikus működést támogatja. Az Inkrementum egy lépés egy vízió vagy cél felé.