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

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*”. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://guias.mosaico.gov.pt/casos-de-estudo/como-o-ticapp-usa-a-ferramenta-agil-jira/gestao-do-backlog.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.