Agile szoftverprojekt-menedzsment: a sprintektől a portfólió-irányításig

Az Agile a szoftverfejlesztésben: mi változik a hagyományos PM-hez képest

A hagyományos projektmenedzsment azt feltételezi, hogy egy projekt előre meghatározható: hatókör, ütemterv, költségvetés, erőforrások. A projektmenedzser feladata, hogy az egészet megtervezze, jóváhagyást szerezzen, majd a végrehajtást a tervhez mérje. Az Agile az ellenkezőjét feltételezi: hogy a követelmények változni fognak, hogy a néhány héten túli részletes tervezés fikció, és hogy az érték a működő szoftver rövid ciklusokban való leszállításából származik, nem pedig egy nagy, végső leszállításból. Egy projektmenedzser számára ez valódi váltás, nem kozmetikai. A terv gördülővé válik a rögzített helyett, a státuszriportálás hetivé válik a mérföldkő-alapú helyett, és a sikert a leszállított érték méri az eredeti ütemterv betartása helyett.

A változások három kategóriába sorolhatók. Először, a tervezés az átfogóból a fokozatosba tolódik: egy magas szintű útiterv több hónapot fed le, de a részletes tervezés csak a következő egy-két sprintre terjed ki. Másodszor, a kontroll az ütemtervi eltérésről a velocityre és az átbocsátásra tolódik: a projektmenedzser már nem azt kérdezi, hogy a Gantt-diagramon belül vagyunk-e, hanem azt, hogy mennyi értéket szállítottunk le ebben a sprintben. Harmadszor, a kommunikáció a formális státuszjelentésekről a folyamatos átláthatóságra tolódik: a sprint review, a retrospektíva és a napi standup váltja fel a heti PM-megbeszéléseket mint fő információs csatornákat. E változások egyike sem teszi feleslegessé a projektmenedzsert, de megváltoztatják, hogy mit csinál. Ha az Agile teljesebb definíciójára van szükséged, a Mi az Agile? útmutatónk lefedi az alapokat; a cikk többi része ezt az alapot feltételezi, és a projektmenedzser gyakorlatára összpontosít.

Az Agile PM működési modellje: sprintek, ceremóniák, artefaktumok

Az Agile PM-munka egy sprint kadencián belül zajlik, jellemzően iterációnként két-négy hét. A ciklus megértése a projektmenedzser (nem a fejlesztő) nézőpontjából jelenti a különbséget egy Agile projekt vezetése és a ceremóniákon való puszta részvétel között.

Sprint mechanika: tervezés, végrehajtás, review, retrospektíva

A sprintnek négy pontja van, ahol a projektmenedzser szerepe elkülönül. A sprint tervezés az, amikor a csapat elkötelezi magát egy sztorikészlet mellett, és a projektmenedzser feladata biztosítani, hogy az elköteleződés reális legyen az ismert függőségek, a kapacitás és a külső korlátok fényében. A végrehajtás az, amikor a projektmenedzser elhárítja azokat az akadályokat, amelyeket a csapat maga nem tud kezelni: beszerzési blokkolók, az érintettek elérhetetlensége, csapatok közötti függőségek. A sprint review az, amikor a csapat működő szoftvert mutat be az érintetteknek, és a projektmenedzser feladata a technikai eredmények üzleti nyelvre fordítása a szponzor számára. A retrospektíva az, amikor a csapat javítja a folyamatát, és a projektmenedzser olyan csapatok közötti kontextust ad hozzá, amelyet a csapat esetleg nem lát. A velocity, amelyet sprintenként teljesített story pontokban mérnek, a projektmenedzser fő előrejelzési bemenetévé válik: három-négy sprintnyi előzménnyel a kiadási dátumok előrejelzése matematikai gyakorlattá válik a találgatás helyett.

Backlog kezelés: a víziótól a sprintig

A termék backlog a fő listája mindannak, amit a csapat építhetne; a sprint backlog az aktuális sprintre elkötelezett részhalmaz. A Product Owner birtokolja a prioritásokat a termék backlogban, de a projektmenedzser olyan kontextust ad hozzá, amellyel a Product Owner esetleg nem rendelkezik: projektek közötti függőségek, a sorrendet korlátozó üzleti mérföldkövek, szabályozási vagy megfelelőségi határidők. A story pont becslés az a mechanizmus, amellyel a csapat a munkát önmagához mérten, nem pedig abszolút időben méretezi, és a projektmenedzsernek elég jól kell értenie ahhoz, hogy megkérdőjelezze a mintából kilógó becsléseket anélkül, hogy maga becsülne. Amikor a csapat egy sztorit 13 pontra becsül, az előzmény pedig hasonló sztorikat 5-re mutat, ez vizsgálatra érdemes jelzés.

Artefaktumok és riportálás: burndown, velocity, kumulatív áramlás

Három artefaktum hajtja az Agile PM riportálását. A burndown diagram a hátralévő munkát mutatja az idő függvényében egy sprintben, és alakja felfedi, hogy a csapat teljesíti-e a sprint elköteleződést. A velocity trendek több sprinten át felfedik a csapat kapacitását és stabilitását: az emelkedő velocity gyakran azt jelenti, hogy a csapat egyre jártasabb a kódbázisban, a lapos velocity állandósult állapotra utal, a csökkenő velocity pedig gyakran technikai adósságot vagy a csapat felbomlását jelzi. A kumulatív áramlási diagramok a munkaelemeket állapotonként mutatják (backlog, folyamatban, review, kész), és felfedik a szűk keresztmetszeteket: ha a folyamatban lévő munka megduzzad, míg a kész lapos marad, a csapatnak áramlási problémája van, amelyet érdemes megoldani. A projektmenedzser feladata nem ezen artefaktumok előállítása (az Agile eszközök automatikusan generálják őket), hanem az olvasásuk és a jelzéseik szponzorhoz igazított riportálásra fordítása.

Szerepek és felelősségek az Agile szoftvercsapatokban

Az Agile szoftverfejlesztésben leginkább félreértett elem az, hogy hol illeszkedik a projektmenedzser. A Scrum három szerepet határoz meg (Product Owner, Scrum Master, fejlesztőcsapat), és nem tartalmaz projektmenedzsert. A gyakorlatban a legtöbb vállalati Agile bevezetésnek továbbra is vannak projektmenedzserei, és annak megértése, hogy valójában mit csinálnak, megelőzi a gyakori hibamódot, amelyben a projektmenedzser és a Scrum Master átfedésbe kerül vagy ütközik.

A projektmenedzser szerepe az Agile csapatokban

A projektmenedzser egy Agile csapatban a csapaton kívül látható eredményekért felel: leszállítás a szponzoroknak, csapatok közötti koordináció, portfólió szintű riportálás, kockázateszkaláció és üzleti összehangolás. A projektmenedzser nem vezeti a sprint ceremóniákat (az a Scrum Master területe), és nem dönt a funkciók prioritásairól (az a Product Owner területe). A projektmenedzser hatásköre leszállítás-központú: birtokolja a leszállítási dátumot az üzlet felé, az elköltött költségvetést, a más csapatokkal való függőségeket és a csapaton kívüli érintettekkel való kommunikációt. A gyakorlatban ez azt jelenti, hogy a projektmenedzser a csapat és a szervezet közötti térben él, mindkét irányba fordít, és elhárítja azokat a szervezeti akadályokat, amelyeket a csapat belsőleg nem tud megoldani.

Product Owner, Scrum Master, fejlesztőcsapat

A Product Owner birtokolja a termék backlogot, prioritizálja a funkciókat, és képviseli az ügyfelet a csapat felé. A Scrum Master facilitálja a ceremóniákat, elhárítja a csapatszintű akadályokat, és coacholja a csapatot az Agile gyakorlatban. A fejlesztőcsapat (jellemzően öt-kilenc fő) építi a szoftvert, önszerveződik a sprint elköteleződés köré, és minden sprintben konkrét sztorik mellett kötelezi el magát. Ezeket a szerepeket részletesebben tárgyalja a Scrum Master útmutatónk és a Product Owner útmutatónk; a projektmenedzserek számára az a lényeg, hogy ez a három szerep a csapat felé irányuló munkát kezeli, míg a projektmenedzser a szervezet felé irányuló munkát kezeli.

Érintettek és irányítás: hogyan kapcsolódnak az Agile projektek az üzlethez

Egy Agile csapat nem egy absztrakt ügyfélnek szállít; egy üzleti kontextusnak szállít szponzorokkal, irányítóbizottságokkal és üzleti tulajdonosokkal, akiknek a csapat előrehaladása alapján kell döntéseket hozniuk. A projektmenedzser három mechanizmuson keresztül strukturálja ezt a kapcsolatot: rendszeres szponzor-frissítések, amelyek a sprint eredményeit üzleti fogalmakra fordítják, egy irányítóbizottsági kadencia (általában havi), ahol a fő döntések születnek, és egy üzleti tulajdonosi kapcsolat, ahol a napi termékkérdésekre válasz születik. E struktúrák nélkül a csapat eltűnik a szervezeti láthatóságból, és a szervezetek úgy reagálnak, hogy vízesés jellegű felügyeletet adnak hozzá, ami aláássa az Agile rugalmasságot. A projektmenedzser feladata, hogy az Agile-t olvashatóvá tegye a szervezet számára anélkül, hogy megszűnne Agile-nek lenni.

Keretrendszerek a szoftverfejlesztésben: Scrum, Kanban, Scrumban, SAFe

Nem minden Agile csapatnak kellene Scrumot használnia. A keretrendszer kiválasztása projektmenedzseri döntés, amely a csapat munkamintájától, a szervezet Agile érettségétől és az épített szoftver természetétől függ. Az alábbi négy keretrendszer lefedi a vállalati Agile szoftverfejlesztés többségét.

Scrum a sprint-alapú klasszikus. Rögzített hosszúságú iterációk (jellemzően két hét), meghatározott ceremóniák és egy elkötelezett sprint backlog. Legjobb az olyan csapatoknak, amelyek kiszámítható kadenciában építenek új funkciókat, egy olyan Product Ownerrel, aki képes elkötelezni magát egy stabil sprint hatókör mellett. Gyenge a sok karbantartási munkát végző csapatoknak, vagy ahol a megszakítás-vezérelt prioritások dominálnak. Részletesen tárgyalja a Scrum módszertani bevezetőnk.

Kanban folyamatos áramlás, nem sprint-alapú. A munkaelemek oszlopokon haladnak át (backlog, folyamatban, review, kész), a folyamatban lévő munka korlátai szabályozzák az áramlást. Legjobb támogatói csapatoknak, karbantartási munkának és olyan csapatoknak, ahol a prioritások gyakrabban változnak, mint egy sprint hossza. Gyenge az olyan csapatoknak, amelyeknek kiszámítható, sprint határokhoz kötött kiadási kadenciára van szükségük. Lásd a Kanban munkafolyamat útmutatónkat és a Kanban tábla útmutatót.

Scrumban a kettőt hibridizálja: Scrum ceremóniák a tervezéshez és a review-hoz, Kanban tábla a napi munkakezeléshez. Hasznos a Scrumról Kanbanra (általában amikor a Scrum túl nehézkesnek tűnik) vagy Kanbanról Scrumra (általában amikor a csapatnak több fegyelemre van szüksége az elköteleződés körül) átmenő csapatoknak. Gyakran a pragmatikus választás azoknak a csapatoknak, amelyek kinövik a szigorú Scrumot anélkül, hogy teljesen fel akarnák adni az iterációkat.

SAFe (Scaled Agile Framework) azoknak a szervezeteknek szól, amelyek több Agile csapatot koordinálnak egy közös programon vagy terméken. Programszintű tervezést (Program Increment tervezés, jellemzően negyedéves) rétegez a csapatszintű Scrum fölé. Hasznos több tucat, ugyanazon a terméken dolgozó Agile csapattal rendelkező vállalatoknak. Túlzás az 5-10 csapatnál kevesebbel rendelkező szervezeteknek; fontold meg a LeSS-t vagy a Nexust könnyebb alternatívaként.

A választás nem végleges. Az érett Agile szervezetek gyakran váltanak keretrendszerek között, ahogy a csapat összetétele, a termék érettsége és a szervezeti kontextus változik. A projektmenedzser feladata a keretrendszer kiválasztásakor az, hogy láthatóvá tegye a kompromisszumokat, és a választást ahhoz mérje, ahogy a csapat valójában dolgozik, nem pedig ahhoz, ahogy az Agile puristák szerint a csapatnak dolgoznia kellene.

Híd az Agile és a PMO között: eszközök vegyes portfóliókhoz

A vállalati szoftverfejlesztés nagy része olyan szervezetekben zajlik, amelyek nem szoftveres projekteket is futtatnak: üzleti kezdeményezések, marketingkampányok, tőkeberuházások, megfelelőségi programok. Ez olyan eszközproblémát teremt, amelyet az Agile írások többsége figyelmen kívül hagy.

A vegyes portfólió problémája: fejlesztők a Jirában, üzlet a PPM-ben

A fejlesztők erősen preferálják a Jirát (vagy az Azure DevOps-ot), mert illik a munkafolyamatukhoz: sztori szintű követés, sprint táblák, backlog grooming, verziókövetéssel való integráció. Az üzleti csapatok a PPM (projektportfólió-menedzsment) rendszereket preferálják, mert illenek a munkafolyamatukhoz: mérföldkő-követés, költségvetés-kezelés, portfólió szintű irányítópultok, erőforrás-kapacitás projekteken át. A vezetésnek egyetlen nézetre van szüksége a teljes portfólióról, Agile és vízesés együtt. Amikor minden terület a saját natív eszközét használja, a szervezet három igazságforrással végzi: a fejlesztők nézete a Jirában, az üzleti tulajdonosok nézete a PPM-ben, és a vezetés nézete, amelyet minden irányítóbizottsághoz kézzel állítanak össze diákra. Ez az a hibamód, amelyet a legtöbb vállalat elér, amikor az Agile bevezetés eszközstratégia nélkül nő.

Hogyan integráljuk az Agile eszközöket egy projektportfólió-rendszerrel

Az architektúrailag tiszta válasz az, hogy a csapatszintű munkát a Jirában tartjuk (ahová tartozik), a portfólió szintű munkát pedig egy PPM-ben (ahová tartozik), egy integrációval, amely szinkronizálja a kettőt. Aminek szinkronizálódnia kellene: a feladat szintű státusz (nyitott, folyamatban, kész), a tulajdonos hozzárendelése, a dátumok, valamint a story pontok vagy becslések. Aminek nem kellene szinkronizálódnia: a napi kommentek, az alfeladatok részletessége, a fejlesztő-specifikus mezők. A túlszinkronizálás zajt teremt; az alulszinkronizálás réseket teremt. A helyes minta az, hogy a fejlesztők természetesen a Jirában dolgoznak, a projektmenedzserek és a PMO a PPM-ben látják a Jira-munka portfólió-releváns részhalmazát a nem Jira projektek mellett, és senkinek sem kell bejelentkeznie egy olyan eszközbe, amely nem a fő munkatere.

A FlexiProject-Jira integráció a gyakorlatban

A FlexiProject ezt a mintát egy közvetlen Jira integrációval valósítja meg, amely epikeket, sztorikat és feladatokat importál a Jirából, megőrizve a státuszt, a tulajdonost és a típust. A JQL szűrők lehetővé teszik a projektmenedzserek számára, hogy pontosan kiválasszák, mely munkaelemek jelennek meg a FlexiProject nézetében, és az importok egyszerre több Jira projektből is húzhatnak csapatok közötti programokhoz. A felhasználó-leképezés megoldja azt a gyakori problémát, amikor ugyanannak a személynek eltérő azonosítói vannak a Jirában és a PPM-ben: a leképezést egyszer állítják be, majd automatikus, így a feladatok tulajdonlása konzisztens marad mindkét rendszerben. Az eredmény az, hogy a Jira feladatok megjelennek a FlexiProject ütemtervén az üzleti feladatok, a marketingfeladatok és más nem szoftveres munka mellett – a vezetés és a PMO a teljes portfóliót látja anélkül, hogy valaha is bejelentkezne a Jirába, miközben a fejlesztők továbbra is a preferált eszközükben dolgoznak. A dedikált FlexiProject-Jira integrációs cikk részletesebben tárgyalja a technikai beállítást.

Irányítás és riportálás az Agile projektekhez egy PMO-ban

A PMO-k másképp irányítják az Agile projekteket, mint a vízesés projekteket, és ennek helyes elvégzése az, ahol a legtöbb vállalat küzd. A hibamód a vízesés jellegű irányítás (részletes ütemtervkövetés, mérföldkő-jóváhagyások, hatókör-változásvezérlés) alkalmazása az Agile munkára, ami súrlódást termel anélkül, hogy felügyeleti értéket adna hozzá.

Az Agile PMO riportáláshoz számító mérőszámok

Nem minden Agile mérőszám való egy PMO jelentésbe. A burndown diagramok és a velocity csapatszintű mérőszámok, amelyek maga a csapat számára hasznosak; ezek megmutatása egy szponzornak mikromenedzsmentre hív anélkül, hogy döntési értéket adna. A PMO riportálásba tartozó mérőszámok eredményközpontúak: cycle time (mennyi idő az elköteleződéstől a leszállításig), átbocsátás (időszakonként leszállított funkciók), megszökött hibák aránya (a leszállítás minősége) és a sprint cél sikerességi aránya (teljesülnek-e az elköteleződések). Ezek a mérőszámok azokra a kérdésekre válaszolnak, amelyeket a szponzorok valójában feltesznek: szállítunk-e, tartja-e magát a minőség, reálisak-e az elköteleződések. A sprinten belüli mérőszámok a csapatnál maradnak; a portfólió szintű mérőszámok a PMO-hoz kerülnek.

Portfólió szintű nézet: Agile és vízesés projektek keverése

Egy kemény végdátumok nélküli Agile projektnek és egy rögzített mérföldkövekkel rendelkező vízesés projektnek ugyanabban a portfólió nézetben kell megjelennie, és eltérő ritmusaik összeegyeztetése az, ahol a PMO eszközök megérik az árukat. A pragmatikus minta a gördülő hullám: az Agile projektek egy elkötelezett rövid távú hullámot mutatnak (a következő egy-három sprint) részletes szinten, a jövőbeli hullámokat pedig becslési szinten. A vízesés projektek mérföldköveket és függőségeket mutatnak ugyanolyan vizuális súllyal, mint az Agile hullámok. A portfólió nézet mindkettőt egyszerre mutatja, és a szponzor láthatja, hogy az Agile csapat következő kiadása illeszkedik-e (vagy elmulasztja) a vízesés projekt átállási mérföldkövét. A hibrid projektmenedzsment megközelítések ugyanazt az összeegyeztetési problémát kezelik projektszinten; a portfólió szintű eszközök az egész szervezetre skálázzák.

Kockázatkezelés az Agile projektekben

Az Agile projekteknek saját kockázati profiljuk van, amelyet a hagyományos kockázatkezelés gyakran figyelmen kívül hagy. A sprint kudarc (a csapat nem fejezi be az elkötelezett sztorikat) becslési vagy tervezési problémákat jelez, és vizsgálatot indokol, nem hibáztatást. A velocity sprintről sprintre ingadozása gyakran a csapat felbomlását jelzi (új tagok, betegség, versengő prioritások), amelyet a projektmenedzser kezelhet. A csapatok közötti függőségi kockázat a késés legnagyobb egyedüli forrása a skálázott Agile-ben: ha az A csapat sprintje a B csapat befejezett munkájától függ, és B csúszik, A blokkolódik. A technikai adósság felhalmozódása rejtett kockázat, amely idővel csökkenti a velocityt bármilyen látható hiba nélkül. A PMO kockázati nyilvántartásoknak meg kell ragadniuk ezeket az Agile-specifikus kockázatokat a hagyományos projektkockázatok mellett, és a felülvizsgálati kadenciának a sprint határokhoz kell igazodnia, nem a havi PM ciklusokhoz.

GYIK: Agile szoftverprojekt-menedzsment

Mi a különbség a projektmenedzser és a Scrum Master között?

A Scrum Master belsőleg facilitálja a csapatot: vezeti a ceremóniákat, coacholja az Agile gyakorlatot, elhárítja a csapatszintű akadályokat. A projektmenedzser külsőleg szállít a szervezetnek: kezeli a szponzor-kommunikációt, a csapatok közötti függőségeket, a költségvetést, a portfólió riportálást és azokat a szervezeti akadályokat, amelyeket a csapat egyedül nem tud megoldani. Kis csapatokban egy személy mindkét szerepet betöltheti, de a vállalati Agile-ben elkülönülnek: a Scrum Master birtokolja a csapat egészségét, a projektmenedzser birtokolja a leszállítási felelősséget az üzlet felé.

Hogyan tervezel egy kiadást Agile csapatokkal?

A kiadás tervezése egyesíti a csapat velocityjét (sprintenként teljesített pontok) a kiadási backloggal (a kiadási hatókörre becsült pontok), hogy valószínű kiadási dátumtartományt hozzon létre. Három sprintnyi velocity előzmény használható előrejelzést ad; tíz sprint megbízhatót ad. A kiadási dátumokat tartományokként (P50 és P80) fejezik ki, nem pontokként, és finomítják, ahogy több sprint befejeződik. A rögzített dátumú kiadások hatókör-rugalmasságot igényelnek; a rögzített hatókörű kiadások dátum-rugalmasságot igényelnek.

Hogyan illeszkedik az Agile egy vízesés projekteket tartalmazó portfólióba?

Az Agile és a vízesés projektek egy portfólióban egy portfóliókezelő rendszeren keresztül élnek együtt, amely mindkettőt megfelelő részletességgel mutatja. Az Agile projektek részletesen mutatják az elkötelezett rövid távú munkát, a jövőbelit pedig becslési szinten; a vízesés projektek mérföldköveket és függőségeket mutatnak. A portfólió nézet felszínre hozza a projektek közötti függőségeket (az Agile csapat kiadása blokkolja a vízesés projekt élesítését), így a PMO-k kezelhetik a vegyes portfóliót anélkül, hogy az egyik módszertant a másik formájába kényszerítenék.

Milyen eszközökre van szükségük az Agile projektmenedzsereknek a Jirán túl?

A Jira jól kezeli a csapatszintű Agile munkát, de nem kezeli jól a portfólió szintű PPM-et. Az Agile projektmenedzsereknek jellemzően olyan PPM-rendszerre van szükségük, amely integrálódik a Jirával (feladatokat, státuszokat és becsléseket importál) a portfólió szintű riportáláshoz, a nem Agile projektekkel való függőségekhez, a projekten átívelő költségvetés-kezeléshez és a vezetői irányítópultokhoz. Akár FlexiProject, akár Planview, akár más platform a PPM, az integrációs minta ugyanaz: a fejlesztők a Jirában maradnak, a projektmenedzserek és a PMO a PPM-ben dolgoznak, az integráció mindkettőt szinkronban tartja.

Hogyan kezelsz rögzített hatókörű, rögzített határidejű projekteket Agile-lel?

A tisztán rögzített hatókörű és határidejű projektek nem illenek jól a tiszta Agile-hez, de gyakoriak a szabályozott iparágakban, a megfelelőségi projektekben és a szállítói szerződésekben. A pragmatikus válasz a hibrid: vízesés jellegű hatókör- és határidő-elköteleződés projektszinten, Agile jellegű végrehajtás azon belül. A sprintek inkrementálisan szállítanak a rögzített határidő felé, a korai sprintek minimálisan életképes funkcionalitást állítanak elő, a későbbiek pedig csiszolást adnak hozzá. A hatókör-kompromisszumok explicit változásvezérlésen keresztül történnek a folyamatos finomítás helyett, védve a határidő-elköteleződést.

Hogyan működjön az Agile PM a gyakorlatban

Az Agile szoftverprojekt-menedzsment nem sprint ceremóniák vezetéséről vagy story pontok írásáról szól. Arról szól, hogy sikeresen szállítsunk szoftverprojekteket egy olyan szervezetben, amely nem Agile munkát is futtat, ahol a projektmenedzser egy Scrum csapat és egy portfólió szintű láthatóságot igénylő PMO között helyezkedik el. A projektmenedzser feladata eltér a Scrum Masterétől: a Scrum Master birtokolja a csapat egészségét, a projektmenedzser birtokolja a leszállítási felelősséget az üzlet felé. A projektmenedzser működési modellje sprint kadencián fut, de eredménymérőszámokban riportál, a csapat munkamintájához illő Agile keretrendszereket használ, és a Jira-alapú csapatmunkát egy PPM-alapú portfólió nézetbe integrálja. Az irányítás és a riportálás az Agile ritmusához igazodik, ahelyett hogy az Agile-t vízesés jellegű riportálási mintákba kényszerítené. Az eszközök számítanak: a Jira és egy PPM-rendszer közötti integráció nélkül a szervezet három igazságforrással végzi, és egyik sem teljes. A FlexiProject ezt a mintát egy közvetlen Jira integrációval támogatja, amely epikeket, sztorikat és feladatokat importál megőrzött státusszal, tulajdonossal és típussal, JQL-szűrt kiválasztással, rendszerek közötti felhasználó-leképezéssel és egy egységes ütemterv nézettel, ahol a Jira-munka a nem Agile projektek mellett jelenik meg. A vezetés a teljes portfóliót látja, a fejlesztők a preferált eszközükben maradnak, a projektmenedzserek pedig felhagynak azzal, hogy minden héten újraépítsék ugyanazt a nézetet három helyen. Az Agile projektmenedzser feladata, hogy ezt a gyakorlatban működtesse, ne csak tudja, hogyan kellene elméletben működnie.