Epics ágeis: definição, exemplos e templates

Resumo: um epic ágil é uma quantidade de trabalho que pode ser dividida em tarefas específicas (chamadas de histórias do usuário) com base nas necessidades/solicitações dos clientes ou usuários finais. Os epics são uma prática importante para equipes ágeis e de DevOps.

Ao adotar a agilidade e o DevOps, um epic serve para gerenciar tarefas. É uma quantidade de trabalho definida que pode ser dividida em tarefas específicas (chamadas de "histórias" ou "histórias do usuário") com base nas necessidades/solicitações dos clientes ou usuários finais.

Os epics são uma maneira útil de organizar seu trabalho e criar uma hierarquia. A ideia é dividir o trabalho em partes menores, para que os projetos grandes possam sair do papel e que você possa continuar gerando valor para os clientes com frequência. Os epics ajudam as equipes a dividir o trabalho e continuar trabalhando para alcançar um objetivo maior.

Manter a agilidade ao organizar tarefas grandes, como os epics, é um trabalho épico (o trocadilho foi intencional). Aprender como os epics se relacionam com práticas recomendadas ágeis e de DevOps saudáveis é uma habilidade essencial, não importa o tamanho da sua empresa.

Um epic é uma grande quantidade de trabalho que pode ser dividida em uma série de histórias menores ou, às vezes, chamadas de "itens" no Jira. Os epics geralmente englobam várias equipes, em vários projetos, e podem até ser monitorados em vários quadros.

Epics são quase sempre terminados após uma série de sprints. À medida que uma equipe aprende mais sobre um epic por meio do desenvolvimento e comentários dos clientes, as histórias dos usuários vão ser adicionadas e removidas conforme necessário. Este é o segredo dos epics ágeis: o escopo é flexível, com base no comentário dos clientes e no ritmo da equipe.

Suponha que é 2050 e você trabalha para uma empresa de viagens espaciais recreativas. A empresa faz cerca de uma dúzia de lançamentos por ano, então cada um deles por si só não é a coisa mais importante de um ano. Ainda assim, está longe de ser mera rotina e vai levar muitas horas/pessoas para ser concluído. Esse tamanho é perfeito para um epic.

Um exemplo de epic: “Lançamento de turismo espacial em março de 2050” com histórias para itens de trabalho de rotina, além de histórias destinadas a melhorar os principais aspectos do lançamento, desde clientes que compram passagens para viagens espaciais até o lançamento do foguete em si. Assim, várias equipes contribuem para este epic trabalhando em uma ampla gama de histórias.

A equipe de software que cuida da venda de ingressos para o lançamento de março de 2050 pode estruturar seu epic da seguinte forma:

Ao mesmo tempo, as equipes de propulsão podem contribuir para o mesmo epic com estas histórias:

Um epic deve informar à equipe de desenvolvimento tudo de que ela precisa saber para ter sucesso. De uma perspectiva prática, ele é o nível superior da hierarquia de trabalho. No entanto, entender como um epic se relaciona com outras estruturas ágeis proporciona um contexto importante para o trabalho diário de desenvolvimento.

• Um roteiro de produto é um plano de ação relacionado a como um produto ou solução vai ser desenvolvido ao longo do tempo.
• Um tema é uma meta organizacional que impulsiona a criação de epics e iniciativas.
• O roteiro do produto é expresso e visualizado como um conjunto de iniciativas representadas em uma linha do tempo.
• Dividir as iniciativas em epics ajuda a manter o trabalho diário da equipe, expresso em histórias menores, conectado às metas gerais da empresa.

Um conjunto de epics concluídos impulsiona uma iniciativa específica, que mantém o produto global em desenvolvimento e evolução com as demandas do mercado e dos clientes sobre temas organizacionais.

A partir do exemplo acima, um tema seria aumentar os lançamentos de ônibus espacial; o roteiro acompanharia o aumento dos lançamentos de três por trimestre para quatro; as iniciativas seriam reduzir os custos e aumentar as vendas de ingressos; e cada epic seria um componente das iniciativas.

Ao criar um epic novo, considere outras ferramentas de planejamento e organização que a sua equipe já pode estar usando. Criar epics relacionados às metas trimestrais ou aos OKRs de uma equipe é um ótimo começo. Ao criar um epic, considere os seguintes pontos:

• Relatórios – Crie epics para os projetos que os gestores e executivos vão ter interesse em monitorar.
• Contação de histórias – Use os epics e as histórias que desenvolvem deles, como um mecanismo para contar a história de como você chegou no estado atual de uma função ou produto.
• Cultura – Deixe a cultura organizacional ditar o tamanho e a granularidade dos epics.
• Tempo – A maioria das equipes de desenvolvimento usa estruturas de estimativa em vez de tempo, mas vale a pena se certificar de que os epics vão levar algumas semanas para serem concluídos. Não muito longos, nem muito curtos.

Veja como os Epics funcionam no Jira.

Dividir um epic em histórias mais práticas ajuda a entender um projeto e manter o ritmo, mas pode ser uma tarefa intimidante para quem nunca fez isso antes. Não há uma solução única para criar histórias a partir de um epic, mas há muitas boas opções a serem consideradas:

• Função ou persona do usuário – Crie uma história única para cada persona do usuário. "Login mais rápido para visitantes novos", "Login mais rápido para clientes fiéis", etc.
• Etapas ordenadas – Divida o processo e crie uma história para cada etapa.
• Cultura – Deixe as normas da equipe ditarem se uma história é uma tarefa rápida ou um projeto de uma semana.
• Tempo — Exceto se combinado de outra maneira, desenvolva histórias que possam ser concluídas em um sprint ou menos.

Não há nenhuma definição universal que trace o limite entre uma história maior e um epic. Em geral, qualquer escopo de trabalho que a equipe estima levar “semanas” (ou mais) para concluir, em vez de “horas” ou “dias”, deve ser considerado um epic e dividido em histórias menores.

Os gráficos de burndown podem ser usados para visualizar epics e manter as equipes motivadas e os executivos interessados informados. Um bom gráfico de burndown é onde a agilidade da organização realmente aparece.

Um gráfico de burndown de epic mostra a quantidade real e a estimada do trabalho a ser feito em um sprint ou epic. O eixo "x" horizontal em um gráfico de burndown indica o tempo, enquanto o eixo "y" vertical indica histórias ou itens.

Use o gráfico de burndown para monitorar o trabalho total restante e projetar a probabilidade de atingir a meta do sprint. Ao monitorar o trabalho restante durante a iteração, a equipe pode gerenciar o progresso e responder de acordo.

Ao monitorar um gráfico de burndown, fica claro como a equipe está progredindo e onde estão os bloqueadores. Ter esses pontos de dados visíveis mantém a sintonia e facilita uma conversa aberta sobre a evolução do produto e as previsões de conclusão. Sem mencionar que a transparência gera confiança!

Saiba como configurar gráficos de burndown no Jira Software

Depois de entender a arte de criar epics e histórias, você vai querer ir além e otimizar usando a automação. Aqui estão três das regras de automação mais comuns usadas para sprints no Jira.

1. Adicione automaticamente três histórias na criação de um epic. Vá para a regra.
2. Feche automaticamente histórias quando o epic é marcado como feito. Vá para a regra.
3. Altere o status de um epic quando o status de um dos itens vinculados for alterado. Vá para a regra.

Veja essas regras de automação e outras centenas na biblioteca de templates do Jira Automation.

Ir para a biblioteca

Os epics não são a base absoluta de um programa ágil, mas o guia prático para a maioria das equipes ágeis e de DevOps. Compreender onde eles se encaixam em um programa ágil saudável dá o contexto para o trabalho, e a divisão de cada um deles em histórias dá o ritmo.