Quando le versioni agili si estendono su più sprint

Alla fine di un'iterazione, non è necessario rilasciare un prodotto software. Scrum chiama questo un Incremento e altre metodologie possono avere nomi diversi. Lo scopo è lo stesso: alla fine della tua iterazione, avere qualcosa che si trova in uno stato che potrebbe essere consegnato a un cliente o utente.

Non posso parlare delle specifiche di Service Now (e questa community non fornisce supporto per prodotti o strumenti specifici ), ma ciò che desideri dovrebbe essere raggiungibile. Attualmente utilizzo Jira, quindi posso descrivere il nostro flusso lì.

Gli elementi del backlog iniziano in Open. Quando uno sviluppatore taglia un ramo (per un cambio di codice) o inizia a lavorare su un oggetto (per qualcosa che non è un codice), il ticket viene spostato su In corso. Quando il lavoro è in fase di revisione, passa a Sotto revisione. Una volta che il team di sviluppo dice che è fatto, va a QA Review (io lavoro in un settore regolamentato, quindi abbiamo bisogno di un test indipendente di tutto il lavoro) e poi Ready for Release. Rimane lì fino al momento del rilascio, a quel punto le cose vengono spostate su Rilasciato e quindi cadono dal tabellone. Qualsiasi oggetto che si trova in "Pronto per il rilascio" è considerato fatto e conta per il nostro burn-down.

Consiglierei di consultare i canali di supporto per il tuo strumento. La mia raccomandazione sarebbe quella di avere una colonna "Done" che indica che il lavoro è stato svolto, tuttavia lo definisci ed è pronto per il rilascio. Quindi, essere in grado di mettere l'oggetto in uno stato "Rilasciato", a quel punto cade dal tabellone. Idealmente, le cose fatte saranno contate per gli elementi completati nel tuo sprint, ma vorrai anche che rimangano sulla scacchiera fino a quando non saranno effettivamente rilasciati e il team di rilascio potrà spostarli nello stato rilasciato. I filtri possono mostrare / nascondere questi dal team di sviluppo, se necessario.

Se lo strumento che hai non supporta il tuo processo, allora hai delle decisioni da prendere. Secondo me, gli strumenti (soprattutto quelli costosi) dovrebbero essere conformi al modo in cui lavori. Tuttavia, potresti non essere in grado di cambiare semplicemente lo strumento e non vuoi combattere lo strumento, ma renderà il tuo lavoro più difficile. Quindi è necessario valutare i flussi di lavoro che lo strumento ti dà e vedere se c'è qualcosa di paragonabile. Forse piccole modifiche al tuo processo, magari in concomitanza con le modifiche alla configurazione degli strumenti, possono portarti a qualcosa che funziona bene.

"Fatto" non significa necessariamente "schierato". Il punto di Scrum è di avere un incremento di software potenzialmente cedibile , fatto, funzionante. Il tuo programma di rilascio non ha davvero nulla a che fare con il tuo programma di sprint. Ci sono molte organizzazioni che mantengono ancora una release trimestrale o annuale, mentre realizzano il loro software in una serie di sprint di due settimane. Gli elementi del backlog "Fatto" non vengono trasferiti nel prossimo sprint, indipendentemente dal fatto che siano rilasciati o meno.

In definitiva, questo si riduce alla definizione di fatto. Se la tua definizione di Fatto include "Distribuito in produzione", probabilmente è un errore, in quanto in realtà non dovrebbe essere un qualificatore se qualcosa è "fatto" o meno. Anche se il tuo programma di rilascio corrispondesse al tuo programma di sprint, non saresti ancora in grado di contrassegnare nulla come "completato" fino alla fine dello sprint, che rischierebbe seriamente di rovinare il tuo burndown.

Lungo e breve, basta divorziare completamente dai due concetti. Il tuo PBI è finito quando è semplicemente in uno stato rilasciabile. Quando o se mai verrà rilasciato non importa.