Come faccio a tenere traccia delle richieste di modifica dell'interfaccia utente minuscole / piccole in Agile?

Problemi come questi sono il motivo per cui sono le tue retrospettive, perché non esiste un "unico vero modo agile" che funzioni al meglio per tutti nel mondo, o anche in ogni gruppo di un'azienda. Brainstorm alcune soluzioni, accetta di provarne una per una o due iterazioni, quindi valuta come andrà nella prossima retrospettiva e apporta le modifiche.

Se fossi seduto sulla tua retrospettiva, suggerirei probabilmente di creare una storia utente per iterazione per contenere tutte le modifiche minori all'interfaccia utente, in quanto ciò dovrebbe rispondere sia alla necessità di tenerne traccia che alla volontà di renderla una dimensione non banale . Ci sarebbe una discussione al riguardo. Forse ci sono preoccupazioni da affrontare. Forse alcuni membri del team preferirebbero una storia per cambiamento, anche se sarebbe estremamente piccola. Forse la mia idea susciterebbe un'idea ancora migliore. La tua squadra può capirlo. L'ho visto accadere decine di volte.

È probabilmente una modifica a una storia utente esistente.

es.

as a user
given I have some memberships
when click on the resign button
the status should read 'cancelled'
and an email should be sent
blah..

Le storie degli utenti possono essere molto piccole. Non lesinare sul materiale di monitoraggio o verrà solo sollevato come errore in QA

"i tested the page and it says cancelled instead of resigned as per the design"

O ci siamo persi tutti insieme

"i asked for that word to be changed and you forgot! I'm not paying for this!!"

Tuttavia, non modificare attività che sono già state avviate. Perderai il monitoraggio dei progressi e causerai problemi creando efficacemente bug perché l'attività era diversa quando completata.

È meglio fare un nuovo compito per la storia utente modificata. includere l'intera (nuova) user story nell'attività. tenere traccia di "cosa vorrei che il prodotto finale sia" separatamente

L'approccio più semplice con il minimo overhead e la maggior trasparenza è quello di creare una storia che non sia altro che "correggere i bug dell'interfaccia utente". Puoi elencare un numero specifico di bug che vanno alla storia in modo che sia chiaro quando la storia è completa.

Questo approccio presenta i seguenti vantaggi:

1. pochissimo overhead.
2. mantiene sotto controllo il numero di piccoli bug (es: non hai una montagna di piccoli bug da correggere dopo aver completato tutte le storie)
3. fornisce trasparenza nella quantità di sforzi richiesti per i bug introdotti
4. fornisce informazioni su quanto tempo è effettivamente dedicato alla risoluzione dei bug.

Come ci occupiamo di esso in Jira; e di estendere ciò che Karl Bielefeldt ha toccato nella sua risposta.

Nelle nostre retrospettive abbiamo deciso di gestire tutto ciò che è "imprevisto" (non parte degli impegni SP1 o SP2) come non pianificato. Non dimensioniamo il lavoro non pianificato. Creiamo un compito in Jira in modo da rendere l'argomento più tecnico e meno "Come un ...", quindi trascinarlo nello sprint.

Non ridimensionarli aiuta a non rendere il burn-down simile a un echiketch, ma possiamo mostrare nelle sessioni di revisione sprint quante storie non pianificate (non standardizzate) sono state introdotte, e quindi potremmo discutere di ogni possibile influenza che potrebbero aver avuto su l'impegno.

Per ripetere, tutto questo è stato deciso dal nostro team in una retrospettiva e, come ha detto Karl, può variare tra le squadre.

Se si tratta di cambiamenti molto piccoli come la formulazione, può anche essere annullato abbastanza facilmente, quindi non vedo la necessità di seguirli rigorosamente. Potrebbe esserci una storia che accumula molti cambiamenti simili e / o l'OP può sedersi accanto allo sviluppatore dicendole cosa cambiare (i commit faranno riferimento a quella storia).

Un'altra risposta potrebbe essere: Agile Software Development preferisce software di lavoro su documentazione ( link )