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

*<mark style="color:blue;">Como \[perfil], quando \[situação], quero \[motivação e como], para que \[resultado esperado].</mark>*

### *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.&#x20;

### *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*:

<figure><img src="https://2869735785-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0oDmFsd3xf4yMMXZ1ctr%2Fuploads%2FxsQabfbfZmVhtXLkLtF3%2Fimage.png?alt=media&#x26;token=07e466d0-d366-4c24-894e-431ea7ae98a4" alt="" width="461"><figcaption><p>Hierarquia existente entre os vários tipos de issues do <em>Backlog</em></p></figcaption></figure>

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*](#associar-outros-issues)).

## Campos a preencher

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

<figure><img src="https://2869735785-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0oDmFsd3xf4yMMXZ1ctr%2Fuploads%2FBi9jQoO0Y6yecuUiWsob%2Ftable1.png?alt=media&#x26;token=9be0cc6f-4d7e-46b4-986f-464992a0e141" alt="" width="563"><figcaption><p>Obrigatoriedade dos campos para os diferentes tipos de <em>issues</em> do <em>Backlog</em></p></figcaption></figure>

\[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;
* &#x20;*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](#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*](#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*](#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*](#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*](#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*](#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](#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*.

<figure><img src="https://2869735785-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0oDmFsd3xf4yMMXZ1ctr%2Fuploads%2Fhur88wlHktEB3iAHxlJf%2Fimage.png?alt=media&#x26;token=2f38d989-a28c-468a-b312-9916224dba0b" alt="" width="563"><figcaption><p>Funcionalidade <em>checklist</em> </p></figcaption></figure>

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*:

<figure><img src="https://2869735785-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0oDmFsd3xf4yMMXZ1ctr%2Fuploads%2FSXPXcriYugnyJWRN8Fap%2Fimage.png?alt=media&#x26;token=c821ab68-56ec-4029-9e63-64c31309a9b7" alt="" width="563"><figcaption><p>Exemplo de <em>checklist</em></p></figcaption></figure>

<figure><img src="https://2869735785-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0oDmFsd3xf4yMMXZ1ctr%2Fuploads%2Fg0H7yDtl0YOK4ube9Mcy%2Fimage.png?alt=media&#x26;token=2f52394a-51e1-4bf8-ab0c-4a2094a94d45" alt="" width="563"><figcaption><p>Exemplo de <em>checklist</em></p></figcaption></figure>

<figure><img src="https://2869735785-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0oDmFsd3xf4yMMXZ1ctr%2Fuploads%2FVDxDwk9EjV4L69kzGpnK%2Fimage.png?alt=media&#x26;token=bf438245-de05-4b97-ac8d-4916b2641e72" alt="" width="563"><figcaption><p>Exemplo de <em>checklist</em></p></figcaption></figure>

## 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*.

<figure><img src="https://2869735785-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0oDmFsd3xf4yMMXZ1ctr%2Fuploads%2FZmoZt6f6rSjVIq0a8mLC%2Fimage.png?alt=media&#x26;token=d4f02bc1-d6bb-4394-aad0-c7ec28211966" alt="" width="563"><figcaption><p>Transição de estados entre <em>issues</em></p></figcaption></figure>

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