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:

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.

Obrigatoriedade dos campos para os diferentes tipos de issues do Backlog

[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 versions – Release onde vai ser corrigido o erro;

• Affects versions – Release 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 Story – Task (importante para garantir o contexto de negócio da task a realizar);

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

• Relação entre Task – Task (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 Task – Bug (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.

Funcionalidade checklist

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:

Exemplo de checklist

Exemplo de checklist

Exemplo 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.

Transição de estados entre issues

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”.