È una storia utente o un bug?

Scrum non si preoccupa del tipo. Una caratteristica, una storia, un bug, una cosa, un oggetto, un caso d'uso ... Qualsiasi cosa può vivere nel backlog del prodotto. Quindi non importa cosa li chiami.

Gli oggetti in cima dovrebbero avere un livello di dettaglio abbastanza decente in modo da poter prevedere quanto necessario e in modo che il team di mischia ne sappia abbastanza per iniziare il lavoro e stare tranquillo che saranno in grado di completare fine dello sprint (che non significa necessariamente che sia completamente definito, purché la squadra sappia che sarà in grado di perfezionare le cose finali durante lo sprint). Questa è l'idea alla base della pianificazione e del perfezionamento just-in-time. Gli articoli più in basso nella lista possono avere molti meno dettagli, dato che hai ancora tempo per perfezionarli nel tempo.

Se hai scelto di utilizzare User Stories come formato, in generale c'è un certo livello di dettaglio che ha ancora senso, quindi il livello successivo è generalmente specificato in casi di test utili o criteri di accettazione.

Dovresti dare un'occhiata ai tuoi criteri di accettazione per le tue storie, queste ultime sembrano davvero le fasi più dettagliate che hai descritto. Specifica per Esempio e la notazione "Given ... When ... Then ..." si adatterebbe molto bene.

Abbina solo il livello necessario per fornire il tuo livello di previsione e stima. Se un criterio di accettazione specifico potrebbe costare un sacco di tempo in più, puoi scomporlo nella sua storia. Puoi sempre abbatterlo in qualsiasi momento successivo, quindi fallo solo se ne hai bisogno adesso per impostare l'ordine di implementazione.

Ricorda che, mentre raffini il tuo arretrato nel tempo, potresti effettivamente raggiungere un livello di dettaglio più vicino al tuo livello BUFD, ma se lo fai, assicurati che sia in qualche forma di specifica eseguibile o sotto forma di casi di test che vuoi eseguire, in questo modo non crei molto lavoro duplicato.

Strumenti come Specflow e Cetriolo possono davvero aiuto in questo. Le specifiche vengono automaticamente associate ai test unitari e ai test di integrazione, in modo tale da vedere automaticamente quando il lavoro è finito, osservando i test che stanno superando. Ciò elimina molti sprechi associati alle tradizionali definizioni dei casi d'uso. Permette anche di scrivere le tue storie ad alto livello, poi quando vai nei dettagli, è specifico e facile da convalidare.

La mia esperienza; Sebbene in RTC ci sia un oggetto "bug / difetto" (lo strumento di collaborazione utilizzato per catturare le storie degli utenti sul mio posto di lavoro) i miei collaboratori taggano per la maggior parte come un "compito" generale, indipendentemente dal fatto che possa essere considerato un bug (o gruppo di bug) o un'attività non bug.

Abbiamo uno strumento in stile Trac per tenere traccia della scoperta e della risoluzione dei bug, ma quando prendiamo questi bug, replichiamo la descrizione in RTC, e di solito la elenchiamo solo come 'task', per scopi di uniformità. Può sembrare contro-intuitivo descrivere i bug in due punti, ma questo è utile per il monitoraggio delle ore se non altro. E elencare tutto come un "compito" aiuta i superiori con le loro domande ... Almeno, questo è quello che ci dicono.

Quindi un esempio di SuperEpic potrebbe essere Open Source Proof of Concept , Epic potrebbe essere Email app on Android , la trama sarebbe Composing and Sending e un'attività sarebbe Compose screen should show recipient instead of sender .

Riguardo al tuo caso d'uso ... È un bug? Sicuro. È una user story? Sembra uno. Perché non entrambi?

Questa è la mia opinione, comunque. Ma l'hai chiesto!

In primo luogo, penso che l'uso del termine "bug" sia un po 'off. Ci sono alcune domande qui su Programmers su questo ( 1 , 2 , 3 ). In generale, la parola "bug" si riferisce a un difetto nel codice. Il software non fa ciò che ci aspettiamo: si blocca, produce risultati errati o qualcosa del genere. Preferisco usare la parola "difetto" e questo un'altra risposta suggerisce "errore" come termine corretto , quando si tratta di discutere di un'ampia gamma di problemi che si presentano nel processo di sviluppo.

Piuttosto che cercare di classificare il tuo cambiamento come una user story o un bug univoco, lo classificherei come un difetto nella tua user story originale. La tua storia utente originale o alcuni aspetti di essa, come i criteri di accettazione, la suddivisione dei compiti, o forse solo una rottura della comunicazione che portano a un malinteso - a prescindere, sembra che l'attività di raccolta e scomposizione del requisito è stato il problema.