La creazione del backlog è definita come un input da scrum. Alcune cose sono dette su come dovrebbe essere, ma non su come arrivarci. Il modo più agile è davvero quello di capire cosa funziona per la tua azienda.
La nostra azienda inizia con un elenco prioritario gigante creato dalla gestione del prodotto con l'input dei proprietari del prodotto. Questo elenco è ad un livello estremamente alto, come un intero nuovo prodotto o una caratteristica principale, alcune dozzine di storie di utenti vale la pena di lavoro distribuite su due o tre gruppi di mischia. Mettono in ordine di priorità quelle caratteristiche in base a ciò che ci farà guadagnare più denaro il prima possibile, o ci impediranno di perdere denaro.
Di tanto in tanto chiedono ai team di mischia una stima molto approssimativa, con una risoluzione di decine di settimane, su quanto ci vorrà. Se tale stima è ampia, ridurrà l'ambito fino a quando non soddisferà le esigenze del cliente o deciderà prima di fare qualcos'altro.
Una volta ogni dieci settimane, assegnano le epop di priorità più alta ai gruppi di mischia. I team li riducono al livello della user story, assegnano punti storia, coordinano le dipendenze da altri team e mettono in ordine le storie. A quel punto abbiamo un "vero" arretrato per squadra. La direzione rivede quell'arretrato per assicurarsi che le pietre miliari più piccole siano appropriate, che soddisfiamo le esigenze aziendali e che le stime funzionano con il loro piano più ampio. Di solito accettano il giudizio delle singole squadre in quel momento. A volte, la creazione dettagliata del backlog rivela problemi che la direzione deve ripensare ai livelli più alti.
Nel nostro arretrato ci sono anche articoli non di grandi dimensioni che i team di mischia creano se stessi basandosi solo sulla guida generale in corso da parte della direzione. Sono cose come bug o problemi di supporto che emergono, strumenti che pensiamo possano contribuire a migliorare la produttività o il refactoring. La regola sul nostro team di scrum è che chiunque può creare una User story per qualsiasi motivo in qualsiasi momento, ma il proprietario del prodotto decide quando è sufficientemente alta la priorità per essere coinvolto in uno sprint.
Abbiamo basato il nostro approccio su Scaling Software Agility di Dean Leffingwell: best practice per le grandi imprese . In realtà è venuto nella nostra azienda e ci ha addestrato quando abbiamo iniziato a lavorare agilmente, ma in una forma veramente agile, abbiamo evoluto i nostri processi per funzionare meglio per la nostra azienda e continuiamo a farlo.