Pripravená požiadavka

Ako ušetriť veľa peňazí na vývoj za málo úsilia. Alebo, prečo definovať požiadavky poriadne.

Pankáči

Pankáči sú u klienta a ich manažmentu už niekoľko rokov horším tímom. Ich požiadavky sa neustále naťahujú a aj keď sa ich podarí dokončiť, klient je permanentne nespokojný a generuje mnoho požiadaviek na zmenu.

Pankáči to už ani neriešia, trvá to roky tak čo! Už to vraveli veľakrát. Požiadavky sú väčšinou jeden titulok, sem tam niečo trochu viac.

 „Si zistite sami„.

„Veď vás predsa platíme ako expertov.“

A tak skúšajú vyťahovať implementáciu ako z kúzelnického klobúka. Tak čo sa všetci čudujete výsledku?

Kto to zaplatí?

Majú pravdu.  V prvom rade je to problém klienta. Ide o jeho peniaze, ktoré platí za vývoj. Je to problém manažmentu. Ide o ich costy. Je to problém majiteľov firmy. Ide o meno a renomé. Ale je to aj problém tímu. Aj oni sú firma.

Ready. Steady. Go!

Najjednoduchšie ako začať riešiť tento problém je označiť každú požiadavku príznakom Pripravená. Najlepšie týždeň-dva pred plánovaním sprintu. Aby PO mal čas požiadavku doladiť. S klientom, obchodom, manažmentom, architektom, s UX.

V ScrumDesku používame 2 stavy – pripravená, nepripravená. Iní naši klienti preferujú semafór s 3 stavmi.

Podľa čoho dávajú danú hodnotu? Najskôr podľa pocitu. Popritom začne diskusia o atribútoch dobrej požiadavky. A tak začína vznikať Definition of Ready.

Neskôr tím zistí, že správne popísaná požiadavka má iné atribúty ako správne popísaná chyba, alebo výskum. A tak začínajú vznikať Definition of Ready pre rôzne typy požiadaviek.

Zrazu produktový vlastník vie aké informácie​ má pre tím pripraviť. Ak ich nemá, vie, že tím požiadavku nezaradí do sprintu. Lebo princíp, dohoda.

Vývoj hodnoty readiness pravidelne merajte a vyhodnocujte. Zamyslite sa nad tým, ako ju zlepšiť v nasledujúcom sprinte.

…lebo trikrát priprav a raz napropgramuj…