Hogyan csinálhatsz egyszerű, mégis részletes user sztorikat, koherens backlogot, mindenre kiterjedő tervezést?

Előfordult már veletek is, hogy ahogy haladtok a projekttel, esnek ki a csontvázak a szekrényből?

Előfordult már, hogy az ügyfél újabb és újabb igényekkel áll elő, és azt állítja, ezek szerinte benne vannak, ezekről nekünk is tudni kellett volna?

Van már gyakorlatotok abban, hogyan írjatok specifikációt, de most mégis backlogot várnak tőletek?

Mégis mi ez a backlog és miért nem jó a specifikáció? Eddig funkciókat írtatok le és követelményeket, erre most user sztorikat várnak tőletek?

Mégis mi ez a User sztori, és mi értelme?

Gondolkodtatok már azon, hogy, ha egy specifikációba kellett egy csomó információ, képernyőterv, működési folyamat leírás, adat struktúra leírás, akkor a user sztoriba miért nem kell ilyen?

Volt már olyan, hogy írtatok egy csomó user sztorit, de nem értettétek, mégis hogyan fog ebből egy koherens rendszer összeállni?

Hogyan lehet egy koherens backlogot írni egy milliárdos projekthez?

Mit lehet kezdeni azzal, ha minden user sztori hatalmas, de szétszedni kisebbre meg nem lehet, mert akkor nem lenne önmagában értékes?

Hogyan lehet olyan elfogadási kritériumokat írni, aminek értelme is van? Mi szükség arra, hogy egy user sztori vitatható legyen?

Ha Te is találkoztál ezekkel a problémákkal, gyere el, megmutatom, hogyan csinálhatsz egyszerű, mégis részletes user sztorikat, koherens backlogot, mindenre kiterjedő tervezést csinálni szoftver projektekben.