A legtöbb termékütemtervet egy negyedéven belül elhagyják, miután megírták. Nem azért, mert a csapatok fegyelmezetlenek, hanem mert az ütemterv rossz alapokra épült: rögzített dátumokra, funkciólistákra és tervnek csomagolt érdekelti kívánságokra. Amikor a valóság elkerülhetetlenül eltér a tervtől — egy funkció tovább tart, egy ügyféligény eltolódik, egy versenytárs lép —, az ütemterv fikcióvá válik, és a csapatok nem néznek rá többé.
Az az ütemterv, amelyet az emberek ténylegesen követnek, nem termékstratégiának öltöztetett Gantt-diagram. Hanem élő dokumentum, amely a csapat aktuális legjobb elképzelését tükrözi arról, milyen sorrendben érdemes megoldani a problémákat, és őszinte abban, hogy mi ismert, és mi nem.
Mielőtt megtervezel egy ütemtervet, érdemes tisztázni a célját. Az ütemterv három dolgot tesz: kommunikálja az irányt (hova tartunk és miért), kikényszeríti a priorizálást (nem tudunk mindent megcsinálni, tehát mi jön előbb), és alapot teremt az összehangolódáshoz (hogy a fejlesztés, a dizájn, az értékesítés és a támogatás mind ugyanazon célok felé dolgozzon).
Az ütemterv nem garantál szállítási határidőket. Nem kötelez el konkrét funkciók mellett. És nem váltja ki a folyamatos feltárómunka szükségességét. Ha az érdekelt felek ígéretként kezelik az ütemtervet, az folyamatprobléma — nem ok arra, hogy hamis pontosságot építsünk a dokumentumba.
A legtöbb csapat számára a legtartósabb ütemtervformátum a háromhorizontos modell. Őszinte a bizonytalanságról: a „Most” elemei vállalt feladatok, a „Következő” elemei tervezettek, de nem véglegesek, a „Később” elemei pedig irányt mutatnak, de változhatnak, ahogy többet tanulsz.
Figyeld meg, hogy minden tétel nemcsak azt tartalmazza, mi az, hanem azt is, miért van ott. Indoklás nélkül az ütemterv csak egy lista. Ha a csapattagok értik, miért került be az egyes tétel, jobb döntéseket tudnak hozni, amikor a körülmények megváltoznak — és eredményesebb beszélgetéseket tudnak folytatni, amikor egy ügyfél olyasmit kér, ami nincs a listán.
A funkcióalapú ütemtervek („építsd X-et, építsd Y-t, építsd Z-t”) veszélyes dinamikát hoznak létre: a csapat funkciókat szállít, és késznek tekinti a munkát, még ha a funkciók nem is mozdítják el azokat a mutatókat, amelyeket el kellett volna. A funkciót leszállították; a problémát nem oldották meg.
Az eredményalapú ütemtervek minden elemet célként fogalmaznak újra: „Csökkentsd az új felhasználók első értékélményig eltelt idejét 4 napról 24 óra alá.” A csapat ezután eldöntheti — és újra átgondolhatja —, hogyan éri el ezt az eredményt. Ez a szerkezet azt is sokkal könnyebbé teszi, hogy egy funkció prioritását csökkentsd, ha felfedezel egy jobb módot ugyanannak az eredménynek az elérésére.
Az ütemterv gazdája a termékmenedzser. Ez azt jelenti, hogy ő felel a tartalmáért, a frissítéséért és az érdekelt felek felé való kommunikálásáért. De a felelősség nem jelent egyedüli szerzőséget — a legjobb ütemterveket együttműködve építik fel, a fejlesztés (megvalósíthatóság és ráfordítás), a dizájn (felhasználói élményre gyakorolt hatások) és az ügyfelekkel foglalkozó csapatok (piaci jelzések) bevonásával.
Amit a termékmenedzsernek el kell kerülnie, az az, hogy bizottságban tervezze meg az ütemtervet. Az érdekelt felek hozzászólhatnak; de nem lehet vétójoguk az egyes tételek felett. A termékmenedzser összegzi a beérkező véleményeket, és meghozza a döntéseket. Ha a döntésekhez vezető folyamatban megbíznak, a döntésekben is meg fognak.
A Most oszlopot minden sprintben át kell tekinteni. A Következő oszlopot minden negyedév elején, vagy amikor jelentős új bizonyíték érkezik (egy nagy ügyfél lemorzsolódik, egy versenytárs elindít valami releváns dolgot, egy feltáró sprint meglepő eredményt hoz). A Később oszlopot negyedévente egyszer kell újra átnézni — nem finomítás céljából, hanem hogy megerősítsük, hogy az irányt mutató fogadások még mindig értelmesek.
A cél olyan ütemterv, amely sosem elég elavult ahhoz, hogy kínos legyen, de nem is frissül olyan gyakran, hogy szorongást keltsen. A legtöbb csapat a túl ritka frissítés felé téved — az ütemterv hat hónappal ezelőtti döntéseket tükröz, és senki sem tudja pontosan, mikor módosították utoljára.
Az ütemtervet akkor és csak akkor fogják követni, ha a csapat megbízik benne. Ez a bizalom három dologból fakad: az egyes tételek indoklása látható és megalapozott, a csapat részt vett az ütemterv megalkotásában ahelyett, hogy készen kapta volna, és a termékmenedzser haladéktalanul frissíti, ha a körülmények változnak, ahelyett hogy úgy tenne, mintha az eredeti terv még érvényes volna.
Az az ütemterv, amelyet alkudozási eszközként vagy a vezetők kielégítésére készített dokumentumként kezelnek, csapatszinten figyelmen kívül marad, az érdekelt felek szintjén pedig neheztelést kelt. Az az ütemterv, amely valódi gondolkodást, valódi kompromisszumokat és őszinte bizonytalanságot tükröz, olyan eszközzé válik, amelyért az emberek kinyúlnak — mert ténylegesen segít nekik dönteni.