Produkty sú pri klasickom projektovom riadení pripravené na začiatku veľmi podrobne. Projektový manažér plánuje projekt od začiatku tak, aby v ňom boli všetky úlohy, často až do najmenších detailov. A aj vrátane “bezpečnostnej vaty 10-15%”. Robí to v dobrej viere, že projekt je naplánovaný, odhadnuteľný a realizovateľný. Detailné plánovanie sa však v praxi zrúti ako domček z kariet v momente keď sa požiadavky zmenia. A to znamená “čoskoro a vždy“.

Agilný projekt má samozrejme tie isté úskalia. No agilita dovoľuje flexibilitu rozsahu požiadaviek, čo by produktový vlastník mal využiť. Využiť aj tým, že backlog bude obsahovať vlastnosti rôznej náročnosti (veľkosti).

Prediktívny aj agilný plán majú tie isté východiská, no agilný projekt je  realizovaný odlišným spôsobom:

• Agilný projekt má síce dohodnuté dátumy dodania, no obsah dodávky je možné zmeniť. V tradičnom projekte sú väčšinou pevne dohodnuté dátumy, rozsah a často aj rozpočet. To znemožňuje pružne reagovať na zmeny.
• Plán vždy obsahuje veľké požiadavky, tzv. eposy (v anglickej literatúre sa používa slovo epics). Produktového vlastníka zaujímajú práve eposy vytvárané na základe vízie produktu. Príklad: Správa zákazníkov, Správa produktov, Prehľady.
• Plán obsahuje niekoľko malých, no konkrétnych požiadaviek, ktoré sa majú dokončiť v jednej alebo dvoch nasledujúcich iteráciách. Nie pre celý plán, len pre niekoľko iterácií! Tieto menšie požiadavky, stories, vznikajú iteratívnym a/alebo inkrementálnym rozdelením eposu. Príklad: Pridanie nového zákazníka, Pridanie kontroly údajov do formulára, Mesačný výkaz účtu

Agilný plán by mal obsahovať  “tehly aj piesok”. Eposy (tehly), ktoré tvoria základ aplikácie a stories (piesok), ktoré tvoria detaily.

Produktový vlastník tak má čas pripravovať eposy dopredu, zatiaľ čo tím má čas konkrétne požiadavky (stories) implementovať a dodávať.

Toto je základ dobrého agilného projektového plánu. Ako ale určíme, ktoré eposy potrebujeme skonkretizovať na stories a kedy?