Il backlog di prodotti gerarchici è una buona idea in TFS 2012-2013?

Per quanto ho capito i backlog gerarchici: Non sono pensati per essere organizzati da argomenti tecnici, ma piuttosto organizzati per livello di astrazione dell'oggetto di lavoro. Si suppone che i livelli più bassi siano i più tecnici, i più elevati rispetto al rapporto valore aziendale / obiettivo aziendale.

Nella documentazione MSDN c'è un esempio con la seguente gerarchia :

• Assistenza clienti di livello mondiale
  • Mitigare l'impatto delle aree a bassa copertura
    • Miglioramenti della cache di dati

Per me questo modo di usare i diversi livelli sembra essere utile per:

• Acquisire obiettivi di alto livello, anche se al momento non sono disponibili per lo sviluppo e senza dover specificare attività tecniche e dettagliate
• Documentare il presunto collegamento tra i dettagli tecnici e l'esito aziendale previsto
• I livelli di astrazione simili all'interno di ogni livello e il contesto dei livelli superiori forniscono un buon quadro per discutere di alternative o prioritizzazione

L'idea di avere un backlog "secchio" è qualcosa con cui la mia organizzazione è iniziata, ma da cui si è allontanata. Abbiamo risolto questo problema spostandoci su Area Paths by module. Ad esempio, disponiamo di un percorso di area Servizi Web, Interfaccia Web e Accesso ai dati per uno dei nostri progetti di team.

Potresti anche prendere in considerazione l'utilizzo degli elementi di lavoro Iniziativa e funzionalità di TFS 2013, ma per quanto ne so sono destinati anche a oggetti di lavoro finiti.