Oltre alla tecnologia in se, l’introduzione della funzionalita’ di Agile Portfolio Management in Team Foundation Server e Service ha un grosso impatto sulla superficie che si va a coprire con il progetto.

Attenzione: in molti casi parlo di progetti medio-grandi. Introdurre concetti come questo in progetti piccoli potrebbe essere controproducente.

Fino ad oggi, il modo piu’ comune di approcciare l’agile backlog management e’ stato quelo di creare delle User Story e in seguito suddividerle in task unitari. Questo va benone e non sta cambiando, ma a volte ci si trova di fronte al seguente problema: la User Story e’ troppo grande per essere inclusa in uno sprint.

A volte capita, sfortunatamente. Per risolvere questo problema, ci viene in aiuto il concetto di Epic.

Un’ Epic e’ sostanzialmente una grande User Story, che e’ a sua volta divisa in diverse sottostorie il cui effort e’ compatibile con la durata dello sprint. Si puo’ rappresentare come un obiettivo funzionale. Una Epic contiene una o piu’ User Story tenute insieme da un tema comune. Non si terminera’ mai in uno sprint, solitamente un’Epic e’ una grossa feature (spesso una killer feature) del nostro prodotto. Si gestisce on top, perche’ potrebbe avere impatti anche su altri prodotti nell’organizzazione.

Il Theme e’ in coma a tutto quanto. Parlando in termini di progetto, potrebbe essere una major release. E’ una iniziativa, una pietra angolare del progetto stesso. I Theme guidano la strategia ed esprimono una direzione, per questo sono generalmente non specifici.

Al momento in Team Foundation Service (e presto in Team Foundation Server 2013) si avra’ il concetto di Epic out-of-the-box. Ma come Brian Harry ci ha detto nel suo post, e’ possibile effettuare delle customizzazioni con un basso effort per modificare l’esperienza d’uso e modellare in modo ancora piu’ fedele il processo.