A 2011-es Scrum Guide egyik újítása az volt, hogy a Fejlesztő Csapat nem vállalást tesz az elvégzendő feladatok teljesítésére a planningen, hanem előrejelzést tesznek arra, hogy azokat el fogják készíteni. 2013-as Guide egyik új eleme pedig a sprint cél bevezetése volt.

Mi az a sprint cél?

A sprint cél a sprint során valósul meg, és utat mutat a Fejlesztő Csapatnak, hogy miért fejlesztik az inkrementumot. A planningen kiválasztott Backlog elemek lehetőség szerint egy koherens funkciót vagy funkció csomagot alkotnak, ami a sprint célját adja. A sprint célt a Scrum Csapat fogalmazza meg, azaz a Product Owner, a Fejlesztő Csapat és a Scrum Master együtt. Azért is fontos, hogy ne a PO nyilatkoztassa ki a planning végén, hogy a Fejlesztő Csapat biztosan értse, és legyen beleszólása, hogy mi lesz a következő iteráció célja. 

Miért jó?

Képzeld el, hogy hajnali három óra van, a Hármashatár-hegy tetején vagy, alkoholtól némileg bódultan, a céges karácsonyi buli után, és mivel éppen nincs térerő, nem tudsz taxit hívni, ami hazavisz. Tudod, hogy kb. 5 km-t kell megtenned ahhoz, hogy eljuss az első éjszakai busz megállójáig. Az a célod, hogy hazajuss, és ezt abban a pillanatban sétával tudod megvalósítani. A probléma legjobb megoldásának akkor épp ez tűnik. Háromnegyed óra séta után még mindig a sötét úton gyalogolsz, amikor hallod, hogy egy autó közeledik. Nem folytatod a sétát, hanem megpróbálod leinteni, mert a célod nem az, hogy hazasétálj, hanem hogy hazajuss. Akár taxival, akár gyalog, de minél hamarabb. Ha az lenne a célod, hogy kocsival juss haza, akkor sokáig várhatnál a hidegben.

Rengeteg előnye van, én eddig ezeket tapasztaltam:

• Rugalmasságot ad a Fejlesztő Csapatnak az implementált funkciókra vonatkozólag. Megadja nekik a lehetőséget, hogy jobb utat keressenek a kiválasztott funkciók fejlesztésére. Ha gebasz van, nem a túlóra a megoldás.
• Ha elcsúszott a sprint, akkor segít a rövidebb út megtalálásában, és a kiválasztott elemek priorizálásban.
• Megadja a fókuszt: azon dolgozik a csapat, hogy elérje a sprint célját. Bár már csak ajánlás, de tök jó, ha a standupon az van a középpontban, hogy hogyan fogjuk elérni a kitűzött célt. Már csak azért is, mert akkor simán születhetnek jobb ötletek a megvalósításra.
• A közös célok összekötnek. Egy csapat dolgozik azon, hogy együtt megvalósítsanak egy célt, azzal szemben, hogy egyének dolgoznak a saját feladataikon.
• Segíti a tervezést. A termék roadmap-jére fel lehet dobálni a sprintek céljait, ami elvezet a vízióhoz.
• Motiválja a csapatot. Ha van célja az iterációknak, akkor biztos, hogy minden sprint végén koherens funkciókat fejlesztenek le, így látható és érezhető igazán a termék növekedése.

A jó sprint cél nemes (ez csak nemes, de nem jó)

Milyen a rossz sprint cél?

• Ha a PO hirdeti ki planningen. Ha a csapat nem érti, vagy nem tudnak vele együtt dobogni, akkor nincs értelme.
• Ha túl hosszú, akkor a kiválasztott funkciók valószínűleg nem koherensek, és elvész a kreativitás lehetősége. Különben fel sem fér a táblára. :))
• Ha magában foglalja a sprint teljes scope-ját. Ez összekapcsolódik a hosszúsággal is. Ha pl. tételesen felsoroljuk a feladatok neveit, akkor az kevés rugalmasságot enged.
• Nem tudjuk, hogy mikor értük el. Voltam már olyan review-n, ahol a PO-n kívül senki nem tudta eldönteni, hogy elértük-e a sprint célját.
• Ha nincs.

Ha pedig, attól félsz, hogy a csapat hátradől, amikor elérte a sprint célját a sprint vége előtt, akkor ajánlom figyelmedbe ezt az agilis alapelvet: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Milyen a jó sprint cél?

• Konkrét és mérhető. Tudjuk, mikor értük el.
• Érthető. Tisztában van vele és érti a csapat.
• Elérhető. Reális célokat állítsunk magunk elé.