> For the complete documentation index, see [llms.txt](https://guias.mosaico.gov.pt/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guias.mosaico.gov.pt/casos-de-estudo/como-o-ticapp-usa-a-ferramenta-agil-jira/gestao-do-backlog.md). # 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 epic. ### User story O user story corresponde a um requisito ou uma funcionalidade a que o produto deverá dar resposta (user story/job story) e que traz 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 concretizar a 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 a funcionalidade terem sido dados por concluídos, é reportada uma correção (erro/bug). ## Hierarquia A figura seguinte ilustra a hierarquia 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 de forma direta é entre o epic 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 só 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 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 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 de forma direta é 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 fazer um incremento no 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, e enriquece a informação 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 podem ser identificados 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 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 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 Oowner * 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”.