Esiste una regola empirica per eliminare una storia dall'arretrato?

A meno che tutti siano d'accordo sul fatto che la storia non è necessaria o indesiderabile, di solito non c'è bisogno o motivo per rimuoverla dall'arretrato. Per la specifica preoccupazione che sollevi, non vedo come la rimozione completa della storia di un utente possa far sentire l'utente più ascoltato. Detto questo, se è stato deciso (in ultima analisi dal Product Owner) che la storia non verrà elaborata (o rinviata a una "versione" successiva), la storia dovrebbe essere contrassegnata come appropriata piuttosto che costantemente rivalutato. Nella mia esperienza, non raggiungi mai il fondo dell'arretrato. È del tutto normale che una storia venga ripetutamente depolarizzata. Questo fa parte del processo della "squadra" (in senso lato) che capisce cosa è realmente importante. La maggior parte del resto di questa risposta riguarda davvero come affrontare il "rischio" di un "disimpegno" dell'utente.

Se un utente è in grado di "tracciare" la propria storia, probabilmente è (o almeno dovrebbe probabilmente) in grado di essere coinvolto (almeno come spettatore) nella prioritization processo. Quando la storia è stata aggiunta, avrebbero dovuto già conoscere la sua massima priorità. Se l'utente è coinvolto attivamente, presumibilmente ha altre storie che stanno per essere completate e dovrebbero avere pochi motivi per "disimpegnarsi". Se l'utente è coinvolto attivamente e tutti le storie degli utenti vengono depuritate, allora 1) questo è un problema in cui le funzionalità critiche per un particolare utente vengono deprioritizzate perché non è importante per altri utenti (o varianti peggiori di questo), o 2) il progetto non è realmente mirato alle preoccupazioni di quell'utente e il disimpegno è probabilmente una risposta appropriata.

Nel caso (1), se l'utente non è in giro per discutere sul motivo per cui una storia dovrebbe avere priorità più alta, coinvolgeteli. Come preludio a questo o più in generale, molto probabilmente in una riunione retrospettiva di sprint, ma ogni volta, dovresti far notare al team che ritieni che alcuni casi d'uso siano ignorati e che potenzialmente potrebbero produrre un sistema che è inutilizzabile per alcuni utenti. Se l'utente non è molto assertivo, tu o altri membri del team potrebbe essere necessario prestare le tue voci per discutere la prioritizzazione (ovviamente, assumendo che tu sia d'accordo con l'utente). Un lieve "coaching" peer-to-peer può anche essere utile se ti senti in grado di fare una cosa del genere, o puoi suggerirla a una persona più appropriata. Ad esempio, si potrebbe dire qualcosa sulla falsariga di "vogliamo costruire un sistema che funzioni per tutti ma siamo vincolati dal grado di stack, quindi dovresti parlare e aiutare le persone a capire l'importanza della storia utente X". I punti importanti da colpire qui sono: a) spiegare il processo in modo che l'utente comprenda come lavorare al suo interno, e b) incoraggiare l'utente a difendere per le storie che ritengono importanti.

Le cose diventano più complicate (ovvero più politiche) se l'utente è necessario per un esplicito (e in misura molto minore, ma non banale, implicita) il buy-in. In questo tipo di scenario alcuni "scambi di cavalli" possono essere appropriati, anche se questo di solito è un brutto segno. In definitiva, una tale decisione sarebbe giunta al Titolare del prodotto in quanto essi sono l'arbitro ultimo per la prioritizzazione. Dal momento che il valore del software che viene scartato o non utilizzato è del tutto negativo, può essere sensato fare alcune storie "non importanti" per ottenere un buy-in. Questo tipo di politica di solito avviene a livelli organizzativi più elevati rispetto a uno sviluppatore, ma si può sicuramente sollevare preoccupazioni sul fatto che il team potrebbe non riuscire a ottenere il buy-in dagli utenti. Questo va oltre Agile / Scrum. Metodologie agili cercano di usare trasparenza e coinvolgimento per evitare questi problemi. Nella mia esperienza di sviluppatore, all'interno di organizzazioni più grandi, ho dovuto continuamente e attivamente sostenere un maggiore coinvolgimento da parte degli utenti finali.

In qualità di membro del team IT, è la tua preoccupazione ma non la tua responsabilità a cercare di garantire l'impegno dei vari stakeholder aziendali. Direi che solo il proprietario del prodotto può rimuovere una storia dal backlog e loro devono parlare con la persona che ha presentato la storia, spiegare perché è stata respinta e sistemare le cose. Nulla potrebbe sembrare peggiore della percezione che l'IT stesse decidendo quali caratteristiche implementare.

È che è una decisione aziendale, basata sulla valutazione di quanto impegno (costo) richiede la storia rispetto a quanto valore offre la storia. In qualsiasi progetto agile ben gestito in un'organizzazione commerciale, arriverà un punto in cui il costo della prossima versione sarà superiore al valore commerciale fornito. A quel punto puoi scegliere di fare il prossimo rilascio o iniziare a passare il progetto al business come di consueto supporto e spostare eventuali storie incomplete a problemi di supporto alla produzione da prendere in considerazione. Forse, dopo alcuni mesi di BAU, la user story diventerà un problema e diventerà utile - su questa base mi piacerebbe non rimuovere alcuna storia a meno che non sia davvero senza speranza .

Mcottle ha già trattato il caso per le storie in buona fede che non hanno mai fatto uno sprint molto bene. Tuttavia, esistono casi reali in cui una storia utente può essere completamente rimossa dal backlog.

Non necessario

Queste sono storie che in origine si credeva fossero necessarie ma che non lo sono più.

Sostituito

Queste sono storie che coprono una piccola area funzionale ma il lavoro è stato riassunto da un'altra user story più grande.

De-ambito

Questo è un requisito valido ma che non è più soddisfatto dal tuo team. Ad esempio, potresti essere in un certo periodo costretto a progettare e scrivere del software, ma in seguito ad ulteriori analisi, hai deciso di acquistare qualcosa o esiste un software che può essere riutilizzato.

Il modo in cui gestirli dipende dallo strumento di gestione del progetto. Dove lavoro, abbiamo una iterazione di posta indesiderata per cose che sicuramente non faremo, che è tenuta separata dal backlog principale.