Iteration, Effort e Business Value.

• Iteration. Il Product Backlog è un elenco dei lavori da fare, funzionalità da implementare e bug da risolvere affinché il progetto possa dirsi realizzato. Specie se il progetto è complesso, il product backlog arriverà a contenere una bella lista di work items, tanto da tenere impegnato il team di sviluppo per vari mesi. La filosofia dello sviluppo agile è che un periodo di attesa di mesi da parte del cliente non è comtemplabile. Bisogna che di frequente il team rilasci in produzione piccoli incrementi del software, in modo che il cliente possa verificare direttamente che i requisiti siano stati compresi fino in fondo e che tutto sia stato fatto in accordo con quanto richiesto.
  Di solito, tali incrementi vengono messi in produzione dopo un periodo di sviluppo di 2-4 settimane, denominato sprint.
  Nel campo Iteration devi appunto indicare qual è lo sprint in cui si è deciso che quel work item andrà lavorato. Di solito questo campo si valorizza solo per i work items che andrai a lavorare nel prossimo sprint. Non si pianifica mai tutto in anticipo perché i requisiti potrebbero cambiare, così come le priorità, e non c'è garanzia che i tempi di sviluppo saranno rispettati, specie guardando al lungo periodo.
  Assegnare l'Iteration dovrebbe essere un lavoro svolto dal Product Owner, ovvero una figura all'interno della tua azienda che vuole perseguire la soddisfazione del cliente e che conosce bene i le sue necessità. Infatti, prima di poter assegnare l'Iteration, è necessario che i work items siano ordinati all'interno del product backlog secondo priorità. Solo una persona che conosce bene le necessità del cliente può riuscire a decidere a cosa dovrà lavorare il team di lì a poco.
• Effort. Questo è l'impegno necessario a portare a compimento il work item. Si tratta di un valore numerico, non vuole indicare ore o giorni di lavoro. Anzi, resisti alla tentazione di far finta che l'Effort indichi le ore di lavoro perché può portare a conseguenze spiacevoli, tipo dirigenti che ti rinfacciano di aver sbagliato la previsione o di averci messo più tempo del normale. Sviluppare software è già una cosa difficile di per sé; non dare modo di creare dissapori a chi non lo comprende.
  Per l'Effort, ad esempio, potresti scegliere un numero nell'intervallo tra 1 e 100 dove 1 indica uno sforzo minimo e 100 uno sforzo enorme. Ma non scegliere qualsiasi numero, prendilo dalla successione di Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, ecc... Più il compito è complesso, meno puoi essere preciso sullo sforzo necessario a completarlo. Quindi ecco perché finché siamo sui numeri piccoli hai più scelte a disposizione (1, 2, 3, 5, 8), perché puoi fare una previsione più precisa ma quando si sale conviene avere meno scelte, più approssimative (34, 55, eccc..).
  L'Effort dovrebbe essere deciso all'unanimità da tutti gli sviluppatori che compongono il team perché se lo facesse una sola persona potrebbe non aver tenuto in considerazione tutti i possibili rischi, e che quindi la sua previsione sia errata in partenza.
  Una pratica usata per determinare tutti insieme questo valore è il planning poker.
  L'Effort può aiutare il product owner a capire che priorità dare ai vari work item. Magari tra due ugualmente importanti sceglierà quello che richiede uno sforzo minore.
  Se un work item ha un Effort molto alto, che potrebbe richiedere più di uno sprint per essere completato, allora è consigliato spezzarlo in due affinché sia più gestibile e conduca ad una previsione più accurata.
• Business Value. Questo è il valore che il work item creerà per il cliente, quando sarà completato. Una funzionalità per lui molto importante o un bug molto critico assumeranno un valore alto. Puoi scegliere un valore da 1 a 5.
  Di solito è il product owner che lo assegna, o il cliente stesso, se hai la fortuna di avere clienti desiderosi di partecipare alla buona riuscita del prodotto.
  Il product owner terrà in considerazione questo valore nel decidere la priorità dei work items.

Altri libri da consigliare per chi parte da 0 con TFS.