By Procurando ideias para melhor descrever os seus épicos ou iniciativas no seu portfólio? O Epic Hypothesis Statement do SAFe é um template que pode ser utilizado para capturar, organizar e comunicar informações críticas sobre o seu produto ou solução, facilitando o entendimento e alinhamento com os stakeholders.
Antes de apresentar o template, vejamos alguns conceitos sobre épico. Mike Cohn, autor e membro fundador do Agile Alliance e Scrum Alliance, define épico como sendo uma user story grande demais para ser implementada e que deve ser “quebrada” em user stories menores para entrega de valor. Já Jeff Patton, criador do User Story Mapping, não gosta da palavra “épico” e prefere utilizar os termos “atividade” e “tarefa do usuário” para referenciar um determinado conjunto de user stories e contextualizar todas as atividades que as pessoas/usuários estão fazendo.
Segundo SAFe, épico é um contêiner para uma iniciativa dentro de um portfólio. Por ter escopo e impacto considerável, épicos requerem a definição de um Minimum Viable Product (MVP) antes da implementação. Existem dois tipos de épico: Business epics fornecem diretamente valor de negócio, enquanto Enabler epics são usados para suportar o código existente, componentes e infraestrutura técnica. O SAFe deixa claro que épicos não são projetos.
Já deu para perceber que há diversas interpretações do significado de épico e dependendo da ferramenta utilizada para a gestão de produto e desenvolvimento pode confundir ainda mais. Os dois maiores players do mercado possuem a seguinte estrutura:
- Jira: Iniciativa > Épico > Story > Tarefas
- Azure DevOps: Épico > Feature > Story > Tarefas
Tanto “Iniciativa > Épico” quanto “Épico > Feature” estão no nível de portfólio, no Upstream workflow (no nível estratégico). Já os demais itens fazem parte do backlog do produto, no Downstream (nível operacional). O que o SAFe chama de épico pode ser interpretado como uma iniciativa (no Jira) e é assim que eu trabalho com Product Owners na definição de hipóteses de um novo produto.
Epic Hypothesis Statement Template
Descrição do Épico
Um elevator pitch descreve o épico em uma forma clara e concisa. O objetivo é expor a iniciativa ou solução em poucos segundos através de um discurso curto apresentando a visão do produto. Pense no elevator pitch como uma forma de vender a sua ideia e considere que há outras iniciativas disputando atenção dentro do portfólio de produtos da empresa. Utilize a criatividade para vender o seu produto para investidores (internos ou externos).
Para <um cliente>
Que <faz alguma coisa ou tem um problema que necessita ser resolvido>
O(a) <solução ou nome do produto>
é um(a) <alguma coisa – o COMO>
que <provê o seguinte valor, principais benefícios>
diferente <do competidor, da solução atual ou de uma solução não existente>
nossa solução <faz algo melhor, nosso diferencial – o PORQUÊ>
Existem diversos templates de elevator pitch e você pode utilizar o que melhor se adequa ao seu produto. Lembre-se que essa descrição transmitirá a ideia da solução proposta para todos os stakeholders, alinhando as expectativas e engajando as pessoas através do seu propósito.
Resultados do negócio
Os benefícios mensuráveis que o negócio pode antecipar se as hipóteses do produto forem verdadeiramente comprovadas.
Sugere-se a utilização de verbos como “aumentar” ou “diminuir” algo como parte da definição de um resultado específico através da utilização do modelo de metas SMART.
Principais Indicadores
As primeiras medidas que ajudarão a prever a hipótese do resultado do negócio. Os indicadores representam COMO os resultados do negócio serão comprovados.
É provável que a primeira release do produto seja um MVP, então identifique quais indicadores podem apontar se devemos ou não continuar o desenvolvimento da solução planejada, se o produto deve sofrer alterações ou até mesmo seja necessário desenvolver uma nova solução. Definir indicadores é fundamental para evitar desperdícios (tempo, dinheiro, recursos) com a continuação da implementação de um produto que não atenderá às expectativas do negócio.
Requisitos não funcionais (RNFs)
Parece óbvio, mas é comum Product Owners e times ignorarem requisitos não funcionais de um produto (e isso pode dar uma baita dor de cabeça no meio do desenvolvimento). Analisar e definir RNFs ainda nas etapas iniciais envolve discussões técnicas com o time que podem influenciar na arquitetura e tecnologia a serem utilizadas, permitindo identificar a viabilidade técnica da solução proposta antes mesmo de desenvolvê-la.
Os principais requisitos não funcionais são: segurança, confiabilidade, desempenho, manutenção, escalabilidade e usabilidade.
Reflexão final
O Epic Hypothesis Statement proposto pelo SAFe auxilia no entendimento e na priorização de cada iniciativa dentro de um portfólio ao definir a visão do produto, os resultados para o negócio e indicadores que medirão as hipóteses quando o produto ou o seu MVP estiver em produção. Se a sua empresa já possui um processo para gestão de portfólio, ótimo! Se não tem, tudo bem. O importante é entender cada proposta de produto dentro do seu portfólio, comparar as alternativas e priorizar as que gerarão (hipoteticamente) os melhores resultados para a empresa e os clientes.
Evite iniciar o desenvolvimento de um produto cujo propósito e benefícios para o negócio não estão claros e muito menos sem saber como os resultados esperados serão medidos. Invista tempo em discovery para evitar desperdícios lá na frente e não tenha medo de cancelar uma iniciativa cuja hipótese foi comprovada ser falsa (lembre-se do Manifesto Ágil: Responder a mudanças mais que seguir um plano). Defina o template com critérios que façam sentido para o seu contexto (o Epic Hypothesis Statement é somente um exemplo) e garanta que estejam acessíveis para stakeholders avaliarem e tomarem decisões estratégicas.
Referências
User Stories, Epics and Themes
By