Como usar histórias vs. Tarefas em Jira

Existem cinco tipos de edições principais em Jira. Eu recomendo que você reduza suas escolhas para apenas estes:

1. Epic - Estes são os seus principais baldes de trabalho. Eles podem ser workstreams de longa duração como Prod Bugs ou projetos liberáveis. O primeiro não teria uma versão de correção (release), o segundo teria.
2. Story - Uma capacidade. Mantenha o nome do resumo curto e conciso. Coloque o Como usuário, eu quero x, para que eu possa y na descrição. As histórias são um "deliverable", parte do seu produto de software, e devem poder ser lançadas. Elas devem ter uma versão de correção atribuída. As histórias também devem ter pontos.
3. Sub-Tarefas - Sub-tarefas dividem um deliverable como uma história em tarefas. As sub-tarefas não devem ter pontos. (Jira não espera isto e os pontos nos seus relatórios Jira padrão serão sobreavaliados se o seu projeto estiver configurado para permitir que as sub-tarefas tenham pontos e que as pessoas usem esse campo). Pure Scrum recomenda estimar as sub-tarefas em horas. O #NoEstimates recomenda o movimento, pois é um desperdício e geralmente não é necessário. (Esta também é a minha experiência.)li>Tasks - Tasks are Tasks and not Stories. As Tarefas também não são subtarefas, no entanto, as Tarefas podem ter subtarefas. As Tarefas também devem ganhar pontos. Bons exemplos de tarefas são a criação de documentos, tarefas operacionais, e outras atividades de trabalho. As tarefas devem ser itens de atraso e relacionados a um projeto ou produto. IMO eles não devem ser itens relacionados à administração como reunir-se com Joe Schmoe ou pegar a roupa suja. Isto leva você para o caminho do rastreamento do tempo e é muito sobrecarregado. Somente trabalhos relacionados a produtos devem ser rastreados em Jira.>li>Bugs - Bugs são Bugs e não Histórias ou Tarefas. Bugs devem ganhar pontos, e ter uma ou mais versões afetadas e uma ou mais versões corrigidas. Também deve haver alguma forma de denotar bugs de produção vs. pré-produção. Eu já vi isso ser feito de três maneiras diferentes: 1.) Criar um tipo de problema diferente chamado Prod Bug 2). Usar um campo de Ambiente 3.) Criar uma bandeira chamada In Production S/N.

In my teams sub-tasks are optional. Eu descobri que operar no nível mais alto com velocidade é suficiente para o planejamento e gerenciamento. Como mencionado acima, isto está em linha com o #NoEstimates movement. Fora isso, quero que minhas equipes rastreiem todo o trabalho do produto em Jira para que possamos gerenciar as expectativas sobre o que pode ser feito até quando. Eu também quero que todo o trabalho seja ligado a um Épico para que possamos resumir nosso trabalho, por exemplo, entender o quanto temos de manter as luzes no trabalho.