Epic, Feature and Story – Épico, Funcionalidade e História

Com a popularização das práticas ágeis nesse processo de desenvolvimento de Produtos, mudou também a forma de como organizar o backlog e o trabalho a ser feito. Para isso, um modelo estrutural muito utilizado é o conjunto de Epic, Feature and Story – Épico, Funcionalidade e História.

Desenvolver algo requer estratégia, organização e estruturação do trabalho a ser feito. Faz-se necessário pensar na ordem das entregas e na divisão do esforço com base no valor de negócio. Isso não é diferente para o processo de Desenvolvimento de Produtos!

Neste artigo vamos entender a definição de cada um, exemplos práticos e e o papel do PO neste modelo de Gerenciamento de Backlog.

 

Definições e Responsabilidades

Não podemos esquecer que o Gerenciamento e Priorização do Backlog deve ocorrer com base no valor de negócio de cada item deste Backlog em direção ao objetivo final, que é o Produto em funcionamento.

A tríade Epic, Feature and Story é uma forma de estruturação bastante utilizada no modelo de trabalho ágil, porém não se restringe somente a esse universo. Esse modelo ajuda na quebra e organização do trabalho a ser realizado em alto, médio ou baixo nível.

Anteriormente às práticas ágeis, era muito comum organizar o trabalho a ser feito no modelo fase a fase do cascata ou utilizando as práticas da gestão de projetos com base no Backlog ordenado.

Vamos falar um pouco mais sobre o que representa cada um destes itens.

 

Assine nossa Newsletter e fique sempre atualizado com nossos artigos!

 

História de Usuário

Uma história de usuário (User Story) é a representação clara e informal que expressa a necessidade e/ou requisito de um potencial usuário. Também pode ser considerada uma parte de um objetivo final. A User Story é a menor unidade de trabalho com base na necessidade do cliente final que vai utilizar e/ou interagir com o Produto.

O Backlog do Produto normalmente é representado por uma lista de histórias ordenadas por valor de negócio. O Dono do Produto é o único responsável pelo Gerenciamento, Priorização e Atualização do Backlog, porém todas as partes envolvidas podem cooperar com suas ideias, sugestões e críticas.

Funcionalidade

A Funcionalidade ou Característica (Feature) é responsável por agrupar um conjunto de histórias de usuário. A Funcionalidade expressa uma função do Produto, da qual contém diversos requisitos funcionais com suas regras e exceções.

A Feature está relacionada a uma Funcionalidade em médio ou alto nível dentro do Produto e por isso precisa de requisitos funcionais e não funcionais expressos por User Story. Quando todas as histórias da Funcionalidade estiverem prontas, considera-se a Feature concluída.

A responsabilidade do gerenciamento do Backlog de Features também é do Product Owner e é altamente utilizado para organizar o seu dia a dia. Algumas organizações não utilizam a organização por Features, mas somente a relação Épico x Histórias.

Épico

O Épico (Epic) é uma grande parte do trabalho a ser realizado no Produto. É também conhecido como uma Grande História de Usuário, da qual expressa de forma macro a necessidade global.

O épico representa uma parte integral do Produto e deve ser suficiente para ter valor de negócio em sua utilização. Todos os épicos devem representar a entrega integral do Produto. Os Epics são formados por Features, ou seja, após a entrega de todas as funcionalidades, considera-se que o Épico esteja finalizado.

A responsabilidade do Gerenciamento do Backlog do Produto depende do modelo de Projetos da organização a depender da estratégia e direcionamento de Negócio.

• Em alguns casos o Product Owner é o próprio responsável, permitindo-o o total empoderamento sobre as decisões.
• Em outros locais, onde a organização mantém a estratégia do Produto na alta gerência, a responsabilidade do Gerenciamento dos Epics é do Product Manager, Business Owner ou algum profissional equivalente.

Estudo de Caso

Vamos pensar agora na estruturação do Backlog considerando a tríade de Épico, Funcionalidade e História. Essa organização pode nos ajudar a entender o Produto por subdivisões em rumo à sua completude.

Para pensarmos na estruturação do Backlog, vamos combinar as definições com o estudo de caso abaixo:

O Banco da Família decidiu criar um novo produto de Financiamento Estudantil para Ensino Básico Privado. A ideia é ajudar pessoas de baixa renda a conseguirem investir nos estudos das crianças e adolescentes.

Para tal, existem 3 níveis de ensino: Ensino Básico, Ensino Fundamental 1, Ensino Fundamental 2 e Ensino Médio.

Foi solicitada a criação de um Produto interno do Banco para gerenciamento de todo esse financiamento, taxa de retorno, inadimplência, verificação e verificação de crédito, além de permitir o acompanhamento dos Gerentes do Banco na iteração com o cliente e o adolescente. O contexto do Produto se limita ao uso interno do banco, não havendo plataforma de acompanhamento para os usuários externos (clientes finais).

Imaginando toda esta estrutura e com esta Iniciativa/Projeto voltada para a boa imagem do banco e uma taxa de retorno de médio e longo prazo, vamos estruturar um breve Backlog.

Epics Backlog

Inicialmente deve ser pensado nos possíveis Épicos, ou seja, nas histórias em alto nível e sem muitos detalhes. Aqui não tem uma regra específica se estes épicos serão por linha de negócio, módulos ou por grandes funcionalidades do Produto a ser criado.

Foram pensados os seguintes épicos:

• Financiamento Estudantil
• Acompanhamento de Retorno Financeiro
• Validação de Crédito e Controle de Fraudes
• Verificação de Inadimplência
• Refinanciamento
• Relatórios Gerenciais

Features Backlog

Uma vez que os épicos foram definidos com base na linha de negócio, serão necessários pensar nas Características e Funcionalidades que cada épico terá. Vamos lembrar aqui que as Features fazem partes do Módulo – que são os épicos – e seu objetivo é completar um épico a partir das suas funcionalidades.

Para expressar exemplos de Features, escolhemos apenas 1 Épico para o exercício não ficar muito complexo:

• Financiamento Estudantil
  • Parametrização de eventos e taxas
  • Atendimento ao cliente
  • Registro de Cliente
  • Registro de Aluno
  • Registro de Escolas credenciadas

Storys Backlog

Por fim, vamos às famosas Histórias de Usuários. Aqui a ideia é pensar em histórias contadas pela perspectiva dos usuários. A história é uma função da Feature e equivale aos requisitos funcionais. Cada histórias contém suas regras e validações que são expressas pelos critérios de aceite.

Voltando ao exemplo anterior e considerando somente uma das Features levantadas, temos:

• Financiamento Estudantil
  • Registro de Escolas credenciadas
    • Registrar escola
    • Buscar escola
    • Editar escola
    • Remover escola
    • Buscar diretoria de ensino
    • Vincular diretoria de ensino
    • Complementar turmas

 

A atuação do Dono do Produto com Épicos, Funcionalidades e Histórias

Note que, apesar da solução parecer sistêmica (e provavelmente será), o título de cada épico, funcionalidade ou história não mostra isso, mas sim uma mensagem observada do ponto de vista do usuário. O Dono do Produto precisa entender que quem vai definir a solução e a melhor forma de desenvolver o produto será o time de desenvolvimento.

O Product Owner precisa ter a capacidade de entender e conversar com os usuários, levantar os épicos, funcionalidades e histórias consistentes conforme tudo que apresentamos por aqui, além de priorizar o Backlog do Produto com qualidade. Lembrando que todas estas atividades devem ser realizadas buscando o respectivo Valor de Negócio do Produto.

Sendo o PO o principal responsável por todas estas atividades, aprender sobre essa tríade ou qualquer outro modelo de estruturação de Backlog é imprescindível para um bom trabalho no modelo ágil, bem como a transparência e apresentação do trabalho a ser realizado para o time de desenvolvimento.