Tracciamento e priorità di PBI quando è diviso per piattaforma

Ci sono due situazioni che devi differenziare:

1. La storia è stata stimata abbastanza piccola da essere eseguita in uno sprint (insieme ad altre storie) e sono stati creati diversi compiti per implementarlo per le diverse piattaforme.
   In questo caso, se non hai finito per tutte le piattaforme, la tua storia non viene completata e non puoi rivendicare i suoi punti. Questo è un normale errore di stima che può verificarsi per qualsiasi storia.

2. L'originale storia di "tutte le piattaforme" è stata ritenuta troppo grande per essere completata in una sola volta ed è stata divisa per rendere il lavoro più gestibile.
   In questo caso, è del tutto normale che non tutte le storie "specifiche della piattaforma" siano completate nello stesso sprint. Quello era il punto principale della divisione della storia genitore. Diamine, potrebbero non essere tutti pianificati per essere avviati nello stesso sprint.
   In questo caso, ogni storia "specifica per piattaforma" deve essere stimata da sola e dovresti dimenticare di aver mai fatto una stima per la storia principale. Una volta che la storia di una piattaforma è terminata, quei punti sono guadagnati.

Per quanto riguarda la priorità delle storie divise, questo dovrebbe basarsi sul valore che ha per il business. Ad esempio, se è noto / stimato che il 60% della base utenti accederà al sistema tramite il sito Web, l'80% utilizza un telefono basato su Android e solo pochi utenti dispongono di un telefono basato su iOS, quindi l'ordine logico dal punto di vista commerciale sarebbe implementare le versioni Android e web molto presto (e probabilmente in questo ordine), mentre la versione iOS può andare molto più indietro nel backlog.

La risposta di Bart van Ingen Schenau è stata eccellente. Aggiungerò solo alla sua risposta affermando che in sostanza la storia originale era troppo grande per essere una storia ed era, di fatto, un'epopea o una caratteristica. Quindi quello che stai facendo è più in linea con ciò che chiamiamo "slicing verticale", per creare una storia "giusta dimensione" che potrebbe essere completata entro uno sprint. Dici che "usiamo dividere per piattaforma e creare una carta diversa per ognuno, ma quando lo sprint termina, e solo due delle tre carte sono fatte, non posso segnare la carta principale come" Fatto "(almeno Penso di sì) e sembra che siamo in ritardo. "

Sembra che tu abbia l'impressione che, a meno che tutte e tre le piattaforme non siano pronte contemporaneamente, non potresti rilasciare. Ma perchè no? Come dice Bart, se l'80% della tua base di clienti utilizza Android, e puoi terminarlo in uno sprint, potresti rilasciare quella nuova funzionalità all'80% dei tuoi clienti dopo uno sprint. Pertanto, ti stai comportando in un modo in linea con il principio agile di rilascio frequente.

Al contrario, se si tenta di mantenere grandi storie e non verranno rilasciate fino a quando l'intera operazione non verrà completata, si ritarderà il rilascio da 2 settimane a 6 settimane. Ciò è contrario al principio agile.

Ho l'impressione che la tua discussione su "spaccare storie" possa essere guidata dalla funzionalità dell'applicazione che stai usando (come Rally) per tracciare il tuo lavoro. In tal caso, e si sta utilizzando una funzionalità di suddivisione nativa per lo strumento, fare attenzione a non consentire allo strumento di determinare il processo. Ricorda: Individui e interazioni su Processo e Strumenti. Ho visto molte volte che i maestri di scrum cominciano a prendere decisioni su come gestire argomenti come questi basandosi su ciò che fa il loro strumento, piuttosto che su ciò che ha senso da una prospettiva agile.

in genere avremmo creato un "feed di notizie" di Epic o Feature che comprendeva le tre piattaforme e le singole storie per ogni piattaforma. Se, tuttavia, è necessario ottenere prima tutto l'Andriod, e questo lascerebbe molte caratteristiche "parzialmente complete" nell'arretrato, e per qualche motivo questo causa problemi di gestione, allora creeremmo Epics separati per piattaforma in modo che potessimo dimostrare il progresso e il completamento di tali caratteristiche per piattaforma. In questo modo, stiamo lavorando in modo coerente con principi e valori agili mentre utilizziamo le funzionalità dello strumento a nostro vantaggio.

La prima cosa da riconoscere è che è tutta una questione di dimensioni del PBI. Se ogni modifica specifica della piattaforma è ridotta, è possibile disporre di un solo PBI per la funzione e quindi delle attività per apportare ogni modifica specifica della piattaforma. Questo è perfettamente ragionevole.

Se le modifiche sono più complesse tali che ciascuna piattaforma merita il proprio PBI, la "caratteristica" in realtà dovrebbe essere una caratteristica / epica. O è intrinsecamente "grande" e nebuloso, e non si tiene traccia di quelli come parte di uno sprint. In sostanza, devi solo aggiungere i PBI specifici della piattaforma ai tuoi sprint per adattarli. Forse puoi fare in modo che iOS esegua questo sprint e affronteresti lo sprint Android successivo. Va bene e in effetti anche comune. Ecco perché vedrai le funzionalità nelle app multipiattaforma distribuire su una sola piattaforma all'indirizzo un tempo, a volte con mesi tra il roll out su altre piattaforme. Il fatto che siano controllati da una feature o da un epico consente di vedere che sono correlati, ma che non sono vincolati da tale relazione, in modo tale che l'erogazione di una piattaforma dipende dalla consegna degli altri.