CURSO CASOS DE USO EBOOK CASOS DE USO 

Home  Agilidade e Mindset 

AGILIDADE BACKLOG DESENVOLVIMENTO ÁGIL ENGENHARIA DE SOFTW… EPIC EPICO

ESTÓRIA DE USUÁRIO EXTREME PROGRAMMING

Epic, Feature e User Story (Epico, Funcionalidade e

História de Usuário)
O que são e como se relacionam estes três artefatos no
contexto de um product backlog

By Plínio Ventura On 24 May, 2019 Last updated 30 Dec, 2019

 6

Compartilhe!

 Facebook  Twitter  Google+  Pinterest

Com a popularização das práticas de

desenvolvimento ágil de software, a forma de
se pensar artefatos de software e de combinar
esses artefatos na produção de software tem
mudado também.

Atualmente, no Brasil e em todo o mundo, a

tríade Epic, Feature e User Story são os artefatos mais utilizados para
estruturação de backlog de produto (product backlog) e para uso em
backlog de sprints (sprint backlog).

Tendo a dizer que talvez pelo menos 50% das organizações que estando
estão caminhando para um processo produtivo orientado ao mindset
ágil estão utilizando esses artefatos para tratar o escopo de seus
produtos de software.

Para compararmos, antes de começarmos a falar mais sobre cada um

dos três artefatos, vamos fazer uma rápida comparação destes
artefatos com outros equivalentes utilizados em empresas com
processos mais tradicionais.

Um Epic é o equivalente ao conceito de Módulo.

Geralmente temos um sistema e esse sistema é dividido em módulos,

que agrupam funcionalidades (geralmente disponíveis através de
interface grá ca).

Uma Feature faz parte de um Módulo, e possui  seus Requisitos

Funcionais e suas Regras de Negócio.

Uma User Story é uma função da Feature, e está associada a ela.

Equivale aos Requisitos Funcionais de uma interface grá ca, por
exemplo.

Requisitos Não Funcionais geralmente atendem/suportam mais de um

Requisito Funcional ou funcionalidade do sistema.

Na visão dos três artefatos que estamos tratando neste post, os

Requisitos Não Funcionais equivalem a Features (a nal o aspecto não
funcional do produto também é parte do produto) e seu escopo é
representado em User Stories  (geralmente chamamos de “histórias
técnicas) quebradas e de menor tamanho.

Obs.: mas não é boa prática termos “histórias técnicas”, para isso
devemos usar artefatos como Spike, Technical Debt, Creep etc.

Abaixo segue um exemplo desta estrutura, e a correlação entre os

artefatos “novos e antigos”.

Vamos falar mais sobre isso neste post, continue conosco! 🙂

Relação com modelos tradicionais e
ágeis
Quando se fala sobre os artefatos Epic, Feature e User Story Story,
geralmente relaciona-se com os modelos de desenvolvimento ágeis.


/* “se o processo for ágil tem que usar História de Usuário,
senão não é ágil”. Na realidade, nem existe
desenvolvimento ágil. Agilidade é mindset! E este mindset
vai muito além da produção de software, se aplica até a
clínica veterinária, por exemplo */

Na realidade, do ponto de vista prático, não há muita diferença se

compararmos os artefatos que estamos tratando neste post com os
artefatos “mais tradicionais” (como comparamos anteriormente, na
imagem).

Importante car claro que podemos utilizar Epic, Feature e User Story em
projetos Waterfall, por exemplo.

A pergunta que sempre deve ser feita é: faz sentido?

E também podemos usar o conceito de Módulos,  Funcionalidades

Grá cas e Requisitos Funcionais e Regras de Negócio em projetos
“ágeis”.

XP e SAFe solidificaram estes artefatos

Um dos frameworks ágeis mais antigos e interessantes (na minha
opinião) é a XP, ou Extreme Programming.

A XP trouxe consigo o conceito de User Story e em sua loso a, o

mindset de que as histórias devem ser INVEST:
 I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable

Obs.: em outro post falaremos muito sobre cada uma das letras acima.

Além das histórias deverem ser INVEST, com a chegada do mindset

Lean Thinking na produção de software, começou-se a perceber que,
conforme as “entrelinhas do manifesto ágil”, não havia sentido em gerar
desperdício pensando, escrevendo e discutindo histórias do futuro.

Mesclando Lean Thinking e mindset ágil, temos a conclusão de que

pensar em detalhes no futuro do escopo de um produto é desperdício
garantido.

Mas grande empresas, diferente de startups, precisam ter alguma visão

de médio/longo prazo em relação aos seus produtos.


/* executivos não pensam (e nem vão pensar tão cedo) em
entregas curtas, testes de hipóteses, feedback, e “no nal a
gente vê como ca”. E não acho que isso seja ruim, é
importante equilibrar as coisas */

Então conceitos como Epic e Features começaram a ser utilizados nos

backlogs de produtos das empresas que estavam utilizando Scrum, XP,
frameworks proprietários orientados à agilidade, dentre outros.

Mesmo sem os detalhes todos antes de começar a desenvolver o

software (como no mundo Waterfall), aquilo que é de curto prazo se
detalha, o que não é ca macro, mas não “invisível”.
Estas visão que os executivos tanto precisam é viabilizada através de
Epics e Features agrupados com contextos de produto (product backlog
que permite termos um product roadmap).

O ágil então começou a ser pensado para grandes empresas, e surgiu o

conceito de “ágil em escala“.

Hoje um dos frameworks mais difundidos para lidar com ágil em escala
é o SAFe (Scaled Agile Framework).

No SAFe Epic, Feature e User Story (tem outros artefatos, como Themes,
Tasks etc. mas não se aplicam neste post) são os principais artefatos de
especi cação utilizados.

Relação entre Epic, Feature e User

Story

Na imagem acima temos cinco artefatos/conceitos:

Theme (tema)
Epic (épico)
Feature (funcionalidade/característica)
User Story (história de usuário)
Task (tarefa)

Há uma relação de realização entre os artefatos (como podemos ver no

diagrama de classes que usei para representar na imagem acima).
O relacionamento entre os artefatos é:

1 Theme é realizado por 1 ou muitos Epics.

1 Epic é realizado por 1 ou muitas Features.
1 Feature é realizado por 1 ou muitas User Stories.
1 User Story é realizada por 1 ou muitas Tasks.

No tópico seguinte vamos entrar no detalhe sobre estas relações e nos

detalhes sobre cada artefato (Epic, Feature e User Story).

Neste post não vamos entrar no detalhe sobre o que é Theme (Tema) e
Task (Tarefa), mas segue uma de nição para contextualizar melhor
(caso você não conheça previamente do que se trata):

Theme (Tema): são assuntos nos quais os Epics (épicos) se

agrupam, e geralmente são de nidos conforme o contexto de
negócio em que o épico está. Por exemplo: numa empresa há uma
iniciativa de “Diminuir a inadimplência para vendas a prazo”. Isso
pode ser o tema, e todos os épicos agrupados neste tema são
orientados para realizar a visão do tema.
Task (Tarefas): são tarefas que devem ser realizadas para realizar
uma histórias de usuário (User Story). Uma histórias de usuário
agrupa todas as tasks referentes a ela. Por exemplo: no Sprint X de
uma equipe há uma histórias chamada “Filtrar lista de pagamentos
atrasados por age da dívida”, e para realizar esta histórias várias
tarefas tem que ser realizadas (estruturar query para buscar dívidas
por age, fazer tunning na base de títulos para atender a algum
requisito não funcional de performance, criar índices em algumas
tabelas do banco de dados, implementar testes unitários dos
métodos de busca etc.). Estas tarefas, necessárias para realizar a
histórias, são as tasks.

Epic, Feature e User Story

 
Abaixo, vamos abordar sobre algumas dimensões comuns, os três
artefatos.

Epic (Épico)
Objetivo
O objetivo de um Épico é realizar um tema de negócio. Podem haver 1 ou
mais épicos agrupados sob um tema.

Quando todos os épicos do tema estiverem concluídos, o tema está

nalizado.

Um épico agrupa 1 ou muitas features (funcionalidades/características)

que estão no contexto do épico.

Exemplo: para o tema  “Diminuir a inadimplência para vendas a prazo”

temos um épico chamado “Implementação de políticas de trava de
parcelamento para clientes com nota abaixo de 8”.

Duração
A duração de um épico deve ser maior que 1 mês, mas não maior que 3
meses.

Maior que 1 mês, pois a boa prática de previsibilidade preza que uma
feature não tenha mais que 1 mês, e um épico deve ter no mínimo 1
feature.
Menor que 3 meses pois a boa prática preza que, em contextos ágeis,
trabalhemos com horizontes de 3 meses, revisitando a estratégia do
produto a cada trimestre (quartil).

Medida de Tamanho
Um épico deve ser estimado utilizando técnicas como Tamanho de
Camisa, ou Contagem de Pontos de Função Indicativa.

Nível de Gestão
Épicos são de nidos no nível estratégico de uma empresa (com
ressalvas para contextos de startups, onde são poucas as pessoas e a
cultura da empresa já nasce [ou pode nascer] ágil).

A realização de um épico gera como efeito direto a realização de uma

ação estratégica da empresa, através da entrega de um produto novo ou
incrementos num produto existente.

Épicos são gerenciados em nível de portfólio de produto, geralmente por

um Product Manager (Gerente de Produtos) ou pro ssional equivalente.

Medida de Progresso
O progresso da produção de um épico deve ser deve ser o progresso da
conclusão das features agrupadas nele, que o realizam.

O progresso em termos de efetividade de resultados do produto para o

negócio deve ser medido através de ferramentas como KPIs ou OKRs.

Responsável
O pro ssional responsável por gerenciar o progresso da produção dos
épicos e a e ciência/e cácia do ponto de vista de resultado de negócio,
deve ser alguém como um Product Manager (Gerente de Produto).

Em algumas empresas esse papel pode ser o PO (Product Owner) ou BO

(Business Owner).

Feature
(Funcionalidade/Característica)
Objetivo
O objetivo de uma Feature é realizar um Épico, podem haver 1 ou mais
features agrupados sob um Épico.

Quando todas as Features do Épico estiverem concluídas, o épico está

nalizado.

Uma Feature agrupa 1 ou muitas User Stories (histórias equivalem a

requisitos funcionais) que estão no contexto da Feature.

Exemplo: para o épico “Criação do dashboard de vendas” temos uma

feature chamada “Implementar dashboard de vendas mensais de
varejo”.

Duração
A conclusão de uma feature deve ser menor que 1 mês e maior que 1
semana.

Menor que 1 mês, pois a boa prática de previsibilidade preza que uma
feature não tenha mais que 1 mês (do contrário tem status de épico),
além do fato de que maior que isso, fatalmente gerará uma
funcionalidade altamente acoplada.
Menor que 1 semana pois a boa prática preza que, em contextos ágeis,
menor que 1 semana é pequeno demais para a entrega ter status de
feature (passa a ser uma história), podendo gerar funcionalidades sem a
completude necessária para ser uma entrega de valor.

Medida de Tamanho
Uma feature deve ser estimada utilizando técnicas como Tamanho de
Camisa, ou Contagem de Pontos de Função Estimativa.

Nível de Gestão
Features são de nidas no nível estratégico/tático de uma empresa
(salvo no contexto de startups, onde são poucas as pessoas e a cultura
da empresa já [pode nascer] nasce ágil).

A realização de uma feature gera como efeito direto a realização de uma

ação tática da empresa, através de um incremento de um produto.

Nível de Controle
Features são gerenciadas em nível de programa de produto, geralmente
por um Product Manager (Gerente de Produtos) ou mesmo pelo PO
(Product Owner).

Medida de Progresso
O progresso da produção de uma feature deve ser deve ser o progresso
da conclusão das user stories (histórias) agrupadas nela, que a realizam.

O progresso em termos de efetividade de resultados do produto para o

negócio deve ser medido através de ferramentas como KPIs ou OKRs.

Responsável
O pro ssional responsável por gerenciar o progresso da produção dos
épicos e a e ciência/e cácia do ponto de vista de resultado de negócio,
deve ser alguém como um Product Manager (Gerente de Produto).

Em algumas empresas esse papel pode ser o PO (Product Owner) ou BO

(Business Owner).
User Story (História de Usuário)
Objetivo
O objetivo de uma
User Story é
realizar uma
Feature e podem
haver 1 ou mais
histórias
agrupadas sob
uma Feature.

Quando todas as
histórias da
Feature estiverem
concluídas, a
feature estará
nalizada.

Uma história de usuário agrupa 1 ou muitas Tasks (tarefas são micro

atividades que precisam ser realizadas para que a história se realize)
que estão agrupadas na história.

Exemplo: para o Feature “Implementar dashboard de vendas mensais de

varejo” temos uma história chamada “Implementar indicador de vendas
por região”.

Duração
A conclusão de uma história deve ser menor que 1 semana e maior que
1 dia.

Menor que 1 semana, pois a boa prática de estimativas e controle preza

que uma história não tenha mais que 1 semana (do contrário tem status
de feature), além do fato de que maior que isso, fatalmente gerará uma
história altamente acoplada.
Maior que 1 dia pois a boa prática preza que, em contextos ágeis, menor
que 1 dia é pequeno demais para a entrega ter status de história (passa
a ser uma task), podendo gerar requisitos sem a maturidade que uma
história INVEST demanda.

Medida de Tamanho
Uma história deve ser estimada utilizando técnicas como Story Points,
Business Complex Points, ou Contagem de Pontos de Função Detalhada.

Nível de Gestão
User Stories são de nidas no nível operacional de uma empresa.

A realização de uma história gera como efeito direto a realização de uma

ação tática da empresa, através de realização de requisitos necessários
para materializar uma feature.

Nível de Controle
User Stories são gerenciadas em nível do time do produto (time Scrum,
por exemplo), geralmente por um PO (Product Owner) ou até mesmo
pelo time de desenvolvimento.

Medida de Progresso
O progresso da produção de uma história deve ser deve ser o progresso
da conclusão das tasks (tarefas) agrupadas nela, que a realizam.

O progresso em termos de efetividade de resultados do produto para o

negócio deve ser medido através de ferramentas como KPIs ou OKRs.

As histórias sensibilizam pouco os resultados do produto, geralmente o

lançamento da feature na qual as histórias pertencem é que sensibiliza
os indicadores do negócio.

Responsável
O pro ssional responsável por gerenciar o progresso da produção das
histórias deve ser alguém como um Product Owner (Dono do Produto)
ou papel equivalente.
Product Backlog x Sprint Backlog
Projetos ou esteira de
produtos (Squad por
exemplo) que rodam sob
o framework Scrum
utilizam os conceitos de
Backlog de Produto
(product backlog) e
Backlog do Sprint (sprint
backlog).

O objetivo é organizar o
trabalho a ser feito, de
maneira sistematizada, em um backlog bem priorizado e estimado,
dentro da realidade.

Para contextualizar apenas (não vou entrar no detalhe das

características dos tipos de backlog citados acima), o backlog de
produto é composto por épicos e features, enquanto o backlog do sprint
é composto de histórias .


/* mas se você car com dúvida sobre o assunto pode usar
os comentários que posso ajudar */

Conclusão
Falamos um pouco sobre Epic, Feature e User Story.

São três dos principais níveis de granularidade de artefatos de

especi cação de produtos que usamos atualmente, principalmente em
projetos realizados em contextos ágeis.
Obviamente que o assunto não se esgota aqui, este post é apenas uma
referência geral, há muito o que falar.

Fique à vontade para usar os comentários, no que eu puder ajudar ou

simplesmente trocar ideias, co à disposição!

E devemos lembrar sempre: agilidade não tem a ver com as tecnologias,

métodos ou técnicas aplicadas para desenvolver o software.

Agilidade é mindset, mentalidade, forma de pensar.

E melhor que usar Epic, Feature e User Story, é pensar verdadeiramente

ágil!

Abraço!

Junte-se a milhares de leitores inteligentes e receba nossas novidades direto no seu e-

mail (é grátis)!

Email*

Digite o seu melhor e-mail

CADASTRAR

Marketing by

Related Posts via Categories

FAQ05 – Perguntas e Respostas sobre Agilidade
Todo MVP (Produto Mínimo Viável) tem que ser um software?
Mestres, Overdose e Efeito Pendular na Produção de Software
7 dicas sobre desenvolvimento ágil de software
 SCRUM e RUP – O SCRUM matou o RUP?
O papel do Gerente de Projetos na agilidade
O papel do Analista de Requisitos na agilidade
Pesquisa sobre agilidade nas empresas
O que é Backlog? Entendendo o backlog no desenvolvimento de
software
Analista de Infraestrutura e Requisito Não Funcional

 Agilidade backlog Desenvolvimento Ágil Engenharia de Software Epic Epico

estória de usuário Extreme Programming

11 Comments Até o Momento 🔒 Privacy Policy 

1 Login

 Recommend 1 t Tweet f Share Sort by Best

Join the discussion…

LOG IN WITH
OR SIGN UP WITH DISQUS ?

Name

Carlos Eduardo De Ponte Mundic • 2 months ago

Excelente artigo!!! Muito didático e elucidativo!!! Parabéns!!!
△ ▽ • Reply • Share ›

Plínio Ventura Mod > Carlos Eduardo De Ponte Mundic

• 2 months ago
Olá Carlos!

Obrigado pela visita, que bom que o conteúdo lhe foi útil.

Abraço!
△ ▽ • Reply • Share ›

Plínio Ventura Mod > Carlos Eduardo De Ponte Mundic

• 2 months ago
Obrigado pela visita Carlos, abraço!
△ ▽ • Reply • Share ›

Leonardo brigido • 5 months ago

Ainda não ficou claro a feature, no caso de um casamento por
exmplo como seria a feature?
△ ▽ • Reply • Share ›

Plínio Ventura Mod > Leonardo brigido • 5 months ago

 Plínio Ventura Mod > Leonardo brigido • 5 months ago

Olá Leonardo!

Não sei se entendi bem. Mas suponhamos que

"Casamento" seja o Épico. Para viabilizá-lo, teríamos
Features como: Comprar apartamento, Viajar na Lua de
Mel, Ter filhos etc.

É por aí sua dúvida?

Abraço!
△ ▽ • Reply • Share ›

Leonardo brigido > Plínio Ventura • 5 months ago

Casamento - épico
DEFINIR LOCAL E DATA - historia
FAZER A LISTA DE CONVIDADOS - historia
CONTRATAR BUFFEt - historia
CONTRATAR MÚSICOS - historia

Aonde pode ter uma feature?

△ ▽ • Reply • Share ›

Plínio Ventura Mod > Leonardo brigido

• 5 months ago
Leonardo,

Nesta lista não vejo Features. Apenas um

Épico e Histórias, como definiu. Pode agrupar
suas Histórias em Features, por exemplo:

Casamento
-> Realizar Recepção (Feature)
-> DEFINIR LOCAL E DATA
-> FAZER A LISTA DE CONVIDADOS
-> CONTRATAR BUFFEt
-> CONTRATAR MÚSICOS

Abraço!
△ ▽ • Reply • Share ›

Carolina • 6 months ago

Muito bom o conteúdo, fico com dúvida em como quebrar em US
quando a demanda é complexa e vai levar mais de uma sprint (de
duas semanas), nesse caso a US levaria mas de uma semana,
conforme descrito.
△ ▽ • Reply • Share ›

Plínio Ventura Mod > Carolina • 6 months ago

Olá Carolina!

Um PIB (Product Item Backlog - pode ser uma História de

 Usuário) que leva mais de um sprint (considerando uma
média de 15 dias de timebox) provavelmente pode ser bem
melhorada, para ficar menor e ativar valor mais rápido, com
menos risco.

Se quiser exemplificar o seu contexto, de repente lhe dou

alguma dica sobre como melhorar isso.

Abraço!

© 2020 - Até o Momento. All Rights Reserved.

Website Design: BetterStudio