Gestão do Backlog

Tipos (Epic, User Story, Task, Bug)

Epic

No jira qualquer ação de trabalho tem o nome de issue. O epic é um issue que reflete o foco de negócio para o produto, de forma mais abrangente. Corresponde a uma iniciativa do negócio que se pretende ver concretizada no produto a desenvolver.

Os user stories e as tasks ficam associados ao épico.

User Story

O user story corresponde a requisito ou funcionalidade a que o produto deverá dar resposta (User Story / Job Story) e que trás valor para o utilizador.

Como [perfil], quando [situação], quero [motivação e como], para que [resultado esperado].

Task

Uma user story dá origem a uma ou mais tarefas, tantas quanto as necessárias para a concretização da story no produto final. As tarefas podem corresponder a tarefas do processo de reseach e design thinking (empatia, definição, ideação, protótipo e testes), análise, desenvolvimento, testes, passagens e outros tipos de trabalho a realizar. Deve estimar-se o esforço de cada tarefa em story points para ser possível planear o trabalho que se faz em cada sprint e medir a velocidade da equipa.

Bug

Quando é encontrado um problema no produto desenvolvido, após o requisito ou funcionalidade ter sido dado por concluído, é reportada uma correção (erro / bug).

Hierarquia

A figura seguinte ilustra a hierarquia existente entre os vários tipos de issues do Backlog:

No Jira, a única hierarquia que se estabelece diretamente é entre o Épico e a User Story. As restantes relações de hierarquia são manuais e estabelecidas por recurso à funcionalidade de Link issues (associar outros issues).

Campos a preencher

Consoante o tipo de issue, há campos que deverão ser preenchidos.

[1] As tarefas são estimadas em unidades de valor abstratas, tais como story points, com base na utilização de um modelo de pesos relativos. O significado dos story points é determinado pela Equipa (ex. níveis de complexidade de implementação).

Algumas notas transversais sobre o preenchimento dos seguintes campos:

  • Description – incluir User Story / Job Story, critérios de aceitação, link para protótipo e para qualquer outro documento relevante;

  • Priority – selecionar entre Highest, High, Medium, Low, Lowest;

  • Business Unit Value – auxiliar à ordenação em hierarquia dos issues nas pesquisas, deverá ser preenchido unicamente pelo Product Owner;

  • Status – de acordo com o ciclo de vida (Ciclo de vida);

  • Sprint – preenchido apenas quando o issue for incluído no Sprint Backlog.

Epic

  • Issue Type = Epic;

  • Components = Epic.

No caso de existir um Epic dividido num conjunto de Epics, deverá ser criada a respetiva relação através da funcionalidade de Link issues (Linkar outros issues).

Story

  • Issue Type = Story;

  • Components = Story.

No caso de existirem relações ou dependências com outras Story, deverá ser criada a respetiva relação através da funcionalidade de Link issues (Linkar outros issues).

Task

  • Issue Type = Task;

  • Description – incluir descrição completa que permita identificar exatamente o âmbito da tarefa;

  • Linked issues – garantir a relação com a respetiva Story e outras tarefas com as quais existem relações de dependência (Linkar outros issues);

  • Components – selecionar entre Backend, Data Analytics, Deployment, Development, Frontend, Functional Analysis, Segurança, UX/UI.

É fundamental compreender o contexto do produto no qual a tarefa se insere, a fim de garantir que a sua execução corresponde a um incremento funcional do produto final. Para tal, é essencial identificar com que story esta tarefa está relacionada, devendo ser criada a respetiva relação através da funcionalidade de Link issues (Linkar outros issues).

Bug

  • Issue Type = Bug;

  • Description – incluir descrição completa que permita identificar exatamente qual o problema e como replicar o mesmo;

  • Linked issues – garantir a relação com a respetiva Story e outras tarefas com as quais existem relações de dependência (Linkar outros issues);

  • Components – selecionar entre Backend, Data Analytics, Deployment, Development, Frontend, Functional Analysis, Segurança, UX/UI;

  • Environment – informação adicional que permita replicar o problema;

  • Fix versionsRelease onde vai ser corrigido o erro;

  • Affects versionsRelease onde ocorre o erro.

Associar outros issues

No Jira, a única hierarquia que se estabelece diretamente é entre o Epic e a Story. As restantes relações de hierarquia (Hierarquia) são manuais e estabelecidas por recurso à funcionalidade de Link issues.

Assim, é fundamental criar as seguintes relações através da criação de links com outros issues:

  • Relação de hierarquia StoryTask (importante para garantir o contexto de negócio da task a realizar);

  • Relação de hierarquia StoryBug (importante para garantir o contexto de negócio do bug a corrigir);

  • Relação entre TaskTask (se são ambas essenciais para a concretização de um incremento ao produto, por exemplo, tarefa de UX – tarefa de FE – tarefa de BE);

  • Relação entre TaskBug (se aplicável);

  • Relação entre quaisquer issues (representativa das dependências entre si).

Associar checklists

O Jira permite definir uma checklist com um conjunto de tópicos a confirmar ou executar, para reutilização em vários issues. Tem a vantagem de ser definida uma única vez e permitir fazer referência a esta sempre que for necessário, enriquecendo a informação que consta do issue.

Um conceito essencial ao agile, a Definition of Done, corresponde a um exemplo prático da utilização de uma checklist. Mas até uma característica ou comportamento repetitivo do produto pode ser identificado como uma checklist. O importante é não esquecer de selecionar a checklist em todos os issues onde esta deverá ser aplicável.

As figuras seguintes ilustram alguns exemplos de checklist:

Ciclo de vida

Estados de issues (Scrum)

  • To Do - A tarefa aguarda o início da sua execução. Este é o estado de todos os issues que estão no Backlog. Quando selecionada para o Sprint Backlog a tarefa continua neste estado até que alguém comece a trabalhar sobre ela durante o Sprint;

  • In Progress - A tarefa está a ser correntemente trabalhada por alguém;

  • Blocked - Existem dependências internas / externas que têm de ser desbloqueadas / concluídas para que a tarefa deste issue possa continuar;

  • Peer Review - Passo intermédio antes de colocar o issue em review que faz com o que os trabalhos sejam revistos por colegas (pares);

  • Review - O desenvolvimento da tarefa terminou, mas o código desenvolvido está à espera de revisão por parte do Product Owner;

  • Closed - Todo o desenvolvimento está concluído, e o conteúdo realizado nesta tarefa pode passar para o ciclo de CI/CD normal, se aprovado pelo Product Owner.

Nota importante: A tarefa só é colocada “In Progress” aquando da sua execução, pois este estado refere-se ao ciclo de vida da tarefa. Quando está a ser realizada a validação pelo par deve manter-se em “Peer Review”. Quando está a ser realizada a validação pelo product owner deve manter-se em “Review”.

Last updated