Come usare le storie contro i compiti in Jira

Ci sono cinque tipi principali di problemi in Jira. Ti consiglio di restringere le tue scelte solo a questi:

1. Epic - Questi sono i tuoi principali bucket di lavoro. Possono essere flussi di lavoro di lunga durata come Prod Bugs o progetti rilasciabili. I primi non avrebbero una fixversion (rilascio), i secondi sì.
2. Storia - Una capacità. Mantenere il nome riassuntivo breve e conciso. Mettete il Come utente, voglio fare x, così posso y nella descrizione. Le storie sono un "deliverable", parte del vostro prodotto software, e dovrebbero essere rilasciabili. Dovrebbero avere una fixversion assegnata. Le storie dovrebbero anche ricevere punti.
3. Sub-Tasks - I sub-tasks suddividono un deliverable come una storia in compiti. Le sotto-attività non dovrebbero avere punti. (Jira non se lo aspetta e i punti nei tuoi report standard di Jira saranno sovrastimati se il tuo progetto è configurato per permettere alle sotto-attività di avere punti e la gente usa quel campo). Pure Scrum raccomanda di stimare le sotto-attività in ore. Il movimento #NoEstimates raccomanda di rinunciare a questa attività perché è uno spreco e generalmente non è necessario. (Questa è anche la mia esperienza.)
4. Task - I task sono task e non storie. Le attività non sono nemmeno sotto-attività, tuttavia le attività possono avere sotto-attività. Le attività dovrebbero anche ottenere punti. Buoni esempi di compiti sono la creazione di documenti, compiti operativi e altre attività di lavoro. I compiti dovrebbero essere elementi di backlog e relativi ad un progetto o prodotto. IMO non dovrebbero essere elementi legati all'amministrazione come incontrare Joe Schmoe o ritirare il bucato. Questo ti porta sulla strada del tracciamento del tempo ed è troppo in alto. Solo il lavoro legato al prodotto dovrebbe essere tracciato in Jira.
5. Bugs - I bug sono bug e non storie o compiti. I bug dovrebbero ottenere punti, e avere una versione/e di affetti e una versione/e di correzione. Ci dovrebbe essere anche un modo per indicare i bug di produzione rispetto a quelli di pre-produzione. Ho visto questo fatto in tre modi diversi: 1.) Creare un tipo di problema diverso chiamato Prod Bug 2.) Usare un campo Environment 3.) Creare un flag chiamato In Production Y/N.

Nei miei team le sotto-attività sono opzionali. Ho trovato che operare al livello più alto con la velocità è sufficiente per la pianificazione e la gestione. Come detto sopra, questo è in linea con il movimento #NoEstimates. A parte questo, voglio che i miei team tengano traccia di tutto il lavoro del prodotto in Jira in modo da poter gestire le aspettative su ciò che può essere fatto entro quando. Voglio anche che tutto il lavoro sia legato ad un Epic in modo da poter riassumere il nostro lavoro, ad esempio capire quanto lavoro di Keep-the-lights-on abbiamo.