A scrum projektek gyorsan változó és adaptív projektek. Minden sikeres scrum projektet egyszerű tervezési feladatok előznek meg, amelyek segítenek a végrehajtásban és az utókövetésben is. Mindössze néhány folyamatról van szó, de ezek megértése és helyes használata elengedhetetlen a projekt sikerességéhez. Ebben a részben először betekintést nyerünk a sprintek koncepciójába. Ezután megismerkedünk az agilis tervezés legfontosabb elemeit jelentő User story – kkal és azok létrejöttével. Ezután pedig bemutatjuk, hogy hogyan lehet ezeket egy megtervezett sprintbe összeállítani.

A hagyományos szoftverfejlesztési megközelítés szerint a legtöbb projektet egy hosszú tervezési szakasz előzi meg, amelyet aztán pontosan ki is viteleznek, és a végén leszállítanak. A scrum projektek során ez a tervezési szakasz jelentősen lerövidül. A scrum projektek alapfeltevése az, hogy nem érdemes a szoftvert az elején minden apró részletében megtervezni, hanem inkább folyamatosan, újra- és újratervezve célravezetőbb leszállítani, jól átgondolt kisebb elemekben. Mivel a scrum egy iteratív megvalósítást feltételez, ezért a scrum csapatok a projektben felmerült feladatokat rövid és önmagukban könnyen megérthető szeletekre osztják fel, amelyeket egy meghatározott idő alatt végrehajtanak.

Sprint

A scrum projektek lelke a sprint.  Minden scrum projekt egy meghatározott számú és fix hosszúságú sprintből áll. Ezek a sprintek legtöbbször egy 1-2-4 hetes időintervallumot ölelnek fel és mindegyiket egy rövid tervezés előzi meg. Tervezés során a scrum csapatok egy ún. sprint-tervező megbeszélésen vesznek részt, amelynek kereteiben közösen megbecsülik az előttük álló feladatok nagyságát, és közösen megállapodnak abban, hogy az adott sprint alatt mely feladatokat fogják elvégezni.

Minden sprint célja, hogy a sprint végén egy önmagában is működő és tesztelhető szoftver készüljön el. A sprintek tervezésénél a legfontosabb szempont az, hogy a sprint végén a megrendelő mindig lásson egy olyan egységet a megrendelt szoftverből, amelyet akár rögtön használni is tud.

User Story

A scrum projektek nem használnak tradicionális projekt követelményeket. Ehelyett a projekten dolgozó product owner (termék tulajdonos) egy listát vezet a Product Backlog-ban. Ennek a listának minden eleme egy ún. user story. A user story mindig röviden leírja a felhasználó szemszögéből, hogy hogyan fogja azt majd használni és miért.

Egy tipikus story felépítése a következő:

Felhasználói szerep / Mit szeretne csinálni / Miért szeretné azt csinálni

Ezek alapján egy példa: Látogatóként szeretnék bejelentkezni az alkalmazásba, hogy elérhessem a regisztrációhoz kötött funkciókat. A felhasználó szerepeket (user roles) a termék-tulajdonos határozza meg a megrendelővel közösen még a projekt megkezdése előtt. A fenti példa ugyan egy nagyon tág feladathalmazt ír le, de bárki, aki ránéz (beleértve a megrendelőt is), elég jól el tudja képzelni, hogy nagyjából mi a feladat. A termék-tulajdonos munkájának a nagy része abból áll, hogy ezeket a story-kat folyamatosan információval tölti fel és szükség esetén tovább bontja még kisebb elemekre. Ahhoz, hogy a fejlesztőcsapat ezeket a story-kat végre is tudja hajtani, ahhoz a story-nak megfelelő információtartalommal kell rendelkeznie.

Miután a termék-tulajdonos összeállította a story-kat és azok tartalmaznak minden információt, ami szükséges a megvalósításhoz, a csapat összeül és megbecsüli, hogy az adott user story mekkora munkát képvisel. A hagyományos projektekkel ellentétben a scrum projektekben a fejlesztőcsapat nem órában, hanem story pontban becsüli meg a story-kat. Ezt a csapatok vagy egy scrum póker nevezetű folyamat során vagy közösen megbeszélve becsülik meg. Egy-egy ilyen tervezés során a fejlesztőcsapat átbeszéli, hogy az adott feladat elvégzéséhez mire lesz szükség és ez mennyi időt fog igénybe venni.

Tervezés

A sprint tervezés során a fejlesztőcsapat, a product owner és a scrum master közösen összeülnek és megbeszélik, hogy a következő sprintben mely user story – k kerülnek megvalósításra. Tipikusan a csapatok tudják, hogy az általuk kiválasztott sprint-hosszúság alatt átlagosan, hány story pontot tudnak kivitelezni (ezt hívják team velocity-nek) és ez alapján választják meg, hogy mely feladatok kerülnek bele a sprintbe. A feladatok kiválasztásánál mindössze annyi kitétel van, hogy a product owner a backlog-ban mindig prioritás szerint rendezi a feladatokat, így a csapatnak azt a sorrendet kell követnie a kiválasztás során kivéve, ha a megvalósításnak technikai akadályai vannak, ami miatt egy másik story-t kell megvalósítani. Persze itt sem szabad elfelejteni, hogy a feladatokat úgy kell megválasztani, hogy a sprint végén mindig egy működő szoftveregység jöjjön létre.

Ez a megközelítés lehetővé teszi, hogy a csapat meghatározott időközönként újratervezze a feladatait, átgondolja a projektet, illetve segítsék egymást a megvalósításban és megértésben.