Al momento sono al 2/3 di Requisiti software agili: pratiche di requisiti snelli per team, programmi e Impresa e raccomando vivamente questo libro in quanto copre molti degli argomenti che riguardano il ridimensionamento del processo agile a più di un team e il mantenimento di backlog per i prodotti a livello aziendale (ovvero quelli che possono durare anni)
Anche se non ho incontrato la tua situazione specifica, quindi non posso davvero dire quanto bene il mio consiglio avrebbe funzionato nella pratica, sulla base della mia esperienza con Agile, combinata con la lettura esterna, questo è quello che suggerirei:
- Mantenere backlog separati per ciascun prodotto. Quindi avresti cinque backlog: P, A1, A2, B1, B2. In questo modo, ogni backlog indica chiaramente dove ti trovi nello sviluppo di quel prodotto e in che cosa stia andando avanti per quel prodotto.
- Quando hai troppe storie in un arretrato, riduci l'agilità generale perché hai più cose da gestire. Avere 5 prodotti diversi in un unico arretrato non sarà molto produttivo. Soprattutto se hai più di un proprietario di un prodotto. Quanto dovresti muoverti se avessi un unico arretrato e all'improvviso il tuo CTO ti viene incontro e dice: A2 è la tua priorità più alta, metti tutto il resto in attesa?
- Lasciare il backlog del prodotto a un livello piuttosto elevato (ad esempio non spezzare le cose fino a 1-3pt). Avere solo oggetti più grandi ridurrà di nuovo il numero di storie e i team dovranno affrontare e renderà molto più facile dare la priorità al lavoro.
- Crea 2 backlog di team: A e B. In base alle esigenze e alle priorità aziendali, dovresti riuscire a estrarre storie da P, A1 e A2 e trasferirle in A. E P, B1 e B2 verrebbero trasferiti in B.
- Idealmente si avrebbero solo diverse iterazioni di storie negli arretrati del team. In questo modo, man mano che le esigenze e le priorità aziendali cambiano, sarete in grado di adattare il volume di storie che tirate da ciascun backlog del prodotto.
- Questi backlog del team raccolgono storie di prodotti e possibilmente li suddividono in frammenti più fini con più dettagli definiti. Ma inserirai i dettagli solo quando il team è pronto a svolgere effettivamente il lavoro.
La cosa positiva è che avere backlog di prodotti separati significa che avrai 5 velocità e sarai in grado di prevedere esattamente quando ciascuna caratteristica per questi prodotti sarà consegnata.
La sfida sarà quella di standardizzare la scala dei punti tra i 5 progetti e 2 squadre perché se diversi prodotti / team usano una scala di punti diversa, la velocità sarà inutile. Il libro che ho menzionato sopra parla di alcuni modi per questa standardizzazione. Fondamentalmente, si desidera iniziare con lo stesso peso base (ad es. 1pt ~ 1 giorno di lavoro). Anche avere incontri scrum of scrums (possibilmente con lead tecnici) aiuterà con una pianificazione di livello superiore, equalizzando la scala dei punti e il coordinamento del lavoro tra i team.