K21
  • Quem somos
  • Coaching & Consultoria
  • Treinamentos
  • EVDnC
  • Conteúdo
    • Tudo Sobre
    • Blog
    • Podcast
    • Cases
    • eBooks
  • Área do aluno
    • Portugal
    • Espanha
    • Latam
    • Estados Unidos
K21
  • Quem somos
  • Coaching & Consultoria
  • Treinamentos
  • EVDnC
  • Conteúdo
    • Tudo Sobre
    • Blog
    • Podcast
    • Cases
    • eBooks
  • Área do aluno
Siga nossas Redes Sociais:
Ir para o conteúdo
K21 Logo K21 Logo

Product Backlog: Épico, História de Usuário e Tarefas

Product Backlog: Épico, História de Usuário e Tarefas

Product Backlog: Épico, História de Usuário e Tarefas

  • 17/janeiro/2020
  • 3:53 pm

Você provavelmente já ouviu falar sobre product backlog, épico, história de usuário (user story) e tarefas, certo? Há muita confusão com esses termos. Agora, vamos às definições!

Escute o artigo e tire suas dúvidas sobre Product Backlog!

Backlog do Produto – Product Backlog (PB)

Ele é o conjunto de todas necessidades dos consumidores e do negócio que serão resolvidas pelo produto. Ele é mantido valorado e priorizado pelo Product Owner. Não é obrigatório utilizar o formato de História de Usuários no Product Backlog.

Épico – Epic

É uma história de usuário que ainda não foi detalhada, é muito grande ou ainda possui muita incerteza e portanto não pode ser transformada em incremento do produto. O épico deve ser fatiado em histórias de usuário menores.

Um exemplo de épico poderia ser: Eu, enquanto deficiente visual, desejo que meu ambiente de trabalho seja mais acessível para que eu não dependa tanto de outras pessoas.

História de usuário – User Story (US)

Tratamos a história de usuário nos artigos O que é a User Story?, Como é a User Story? e História de Usuário: Evitando Disfunções.

Muito resumidamente, a História de Usuário é um formato sucinto para escrita dos requisitos necessários para a construção de um produto. Ela deve ser compreensível para o clientes e consumidores. Exemplos de histórias de usuário para o épico apresentado acima:

História 1: Eu, enquanto deficiente visual, desejo que os locais que eu tenho que ir sejam acessíveis para que eu não tenha que passar pelo constrangimento de ficar perguntando para as pessoas sobre os locais onde quero ir.

História 2: Eu, enquanto deficiente visual, desejo chegar facilmente à saída de emergência, pois não quero morrer em um incêndio.

Perceba que um bom Product Owner pode fatiar a história ainda mais se tentar entender a parte mais importante do problema mais importante do cliente mais importante. Por exemplo:

História 1.1: Eu, enquanto deficiente visual, desejo chegar facilmente aos banheiros para que eu não tenha que passar pelo constrangimento de ficar perguntando para as pessoas sobre os locais aonde quero ir.

História 1.2: Eu, enquanto deficiente visual, desejo chegar facilmente aos elevadores para que eu não tenha que passar pelo constrangimento de ficar perguntando para as pessoas sobre os locais aonde quero ir.

História 1.3: Eu, enquanto deficiente visual, desejo chegar facilmente às salas de reunião para que eu não tenha que passar pelo constrangimento de ficar perguntando para as pessoas sobre os locais aonde quero ir.

Pode fatiar mais ainda. Digamos, que a maioria dos deficientes visuais estão no 5º andar.

História 1.1.1: Eu, enquanto deficiente visual que trabalha no 5º andar, desejo chegar facilmente aos banheiros para que eu não tenha que passar pelo constrangimento de ficar perguntando para as pessoas sobre os locais aonde quero ir.

Tarefas – Tasks

Tarefas são itens técnicos necessários para que uma História de Usuário se transforme em incremento do produto. Exemplo de tarefas da História 1.1.1:

  • Adquirir módulo de sensor de presença;
  • Adquirir alto-falantes;
  • Fazer o design das novas placas;
  • Criar os modelos de engenharia;
  • Montar as placas;
  • Instalar as placas nos banheiros do 5º andar; etc.

A hierarquia

A hierarquia que temos com a histórias de usuário é essa:

4 caixas uma com a notação de banco de dados. Cada elemento é explicado no texto com as suas conexões. Hierarquia do Product Backlog.

Hierarquia de Product Backlog, Épicos, Histórias de Usuário e Tarefas

O Backlog do Produto é a coleção de história de usuários que deveremos fazer. Um backlog do usuário possui de 1 até N Histórias. O backlog não precisa conter épicos. Normalmente times que trabalham com o escopo totalmente flexível e constante validação de hipóteses mantém um backlog extremamente enxuto, sem épicos.

Caso existam épicos no backlog, ele pode ser fatiado em N histórias de usuário. Todavia, o épico pode ser descartado caso se conclua que ele não será capaz de trazer os benefícios inicialmente imaginados.

Uma história de usuário pode ser dividida em N tarefas técnicas. Todavia, quando o Product Owner faz um bom fatiamento das histórias de usuário, o time tem um fluxo de valor muito bem mapeado no Quadro de Tarefas. Quando eles dominam as ferramentas e técnicas necessárias para a construção e conhecem o contexto em que atuam, menor será a necessidade de quebrar a histórias em tarefas.

É possível ainda organizar as histórias de usuários em Entregas (Releases). Conceitualmente toda história de usuário que virou produto/serviço e foi entregue para o consumidor final é uma Entrega.

Conceitualmente só existem esses quatro níveis na hierarquia de histórias de usuário, mas há muita confusão. Uma boa parte dela gerada quando as pessoas começam a utilizar ferramentas de gestão de projetos ágeis antes de conhecer os conceitos.

Confusão gerada pela nomenclatura das ferramentas

O quadro abaixo apresenta alguns dos nomes utilizados pelas ferramentas mais conhecidas no mercado: Scrum Half, Microsoft Azure Boards (Antigo Team Foundation Service – TFS), Rally (antigo C.A. Agile Central), Atlassian Jira, IBM Rational Team Concert (RTC), Trello e VersionOne.

Na imagem, podemos ver que NÃO há uma padronização e isso acaba gerando uma grande confusão nas pessoas.

Nomenclatura das Ferramentas. Em Azul o nível de Produto, Serviço ou Projeto. Em vermelho o nível de Épico, Amarelo o nível de História e verde as tarefas.

Nomenclatura das Ferramentas. Em Azul o nível de Produto, Serviço ou Projeto. Em vermelho o nível de Épico, Amarelo o nível de História e verde as tarefas.

Algumas dessas ferramentas tem o início do controle no portfólio de projetos. Algumas aceitam personalização tanto de nomes, quanto de estruturas. Logo, caso a sua empresa utilize alguma delas, você pode ter uma hierarquia diferente da que está sendo apresentada aqui.

Para alguma delas como a IBM Rational Team Concert (RTC), tudo é um item de trabalho. Você pode ou não ter épicos, pode ou não ter subtarefas, etc.

Das ferramentas apresentadas no quadro acima, a Scrum Half utiliza a nomenclatura mais próxima dos conceitos da Agilidade. Em uma história você pode marcá-la como Épico e quebrá-la futuramente. Você também pode utilizar o conceito de Entrega (Release) se necessário.

Conclusão

Alguns conceitos de Métodos Ágeis podem ser difíceis quando estamos começando. Principalmente, se estamos vindo do mundo da Gestão de Projetos. Com o tempo nos acostumamos com os novos conceitos.

Ainda ficou com alguma dúvida sobre esse tema? Deixe aqui nos comentários.

Aproveito para convidá-lo para participar do nosso treinamento de Certified Scrum Product Owner (CSPO) e já aprenda na prática como criar boas histórias de usuário.

Veja também o nosso blog mais artigos sobre o papel do Product Owner.

Quer entender mais sobre gestão de produtos? Ouça o episódio do Love The Problem!


Autor(es)

Avelino Ferreira

Agile Expert e Trainer na K21, Avelino é desenvolvedor de software por formação, já passou por diversos papéis em diferentes organizações: Programador, Líder Técnico, Gerente de Projetos, Scrum Master, Product Owner e Gestor. Durante a carreira, auxiliou empresas a adotarem o Rati...

Creative Commons License
Esta postagem se encontra sob a licença
Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Comentários

9 Comentários

  1. José Augusto Rodrigues Neto 01/07/2020 em 11:45- Responder

    Grande Avelino.
    Obrigado pela referência ao nosso ScrumHalf. Você realmente captou bem o espírito da coisa: sermos bem aderentes ao Scrum, de forma ajudar os times a praticarem agilidade da forma correta, evitando o fake agile. Lógico que oferecemos alguma flexibilidade, e até a possibilidade de utilizar somente o Kanban. Mas a ideia central é realmente apoiar quem quer fazer Scrum mesmo.
    Muito obrigado pela referência e por valorizar o produto nacional em um mercado tão competitivo.

    • Avelino Ferreira 01/07/2020 em 19:52- Responder

      Isso ai José. Ponto positivo e muito importante que você trouxe.

  2. Pedro Cortez 07/07/2020 em 20:44- Responder

    Muito bom o artigo. Curti bastante a comparação das ferramentas tb

    • Avelino Ferreira 14/07/2020 em 18:28- Responder

      Fala Pedro. Como vão as coisas? Que bom que você curtiu. Um grande abraço para você.

  3. Leandro Farias 14/07/2020 em 11:10- Responder

    |Fala pessoal, muito bom o artigo. O comparativo e a analogia feito com o quadro de ferramentas fez o cérebro explodir de tão bom que foi!

    Muito obrigado pelo conteúdo TOP.

    • Avelino Ferreira 14/07/2020 em 18:28- Responder

      Que bom que você gostou. Muito obrigado pelo feedback. Se tiver qualquer conteúdo que você queira que exploremos um pouco mais é só deixar aqui no comentário.

  4. Rafael Barreto 28/07/2020 em 15:02- Responder

    Excelente comparação entre as ferramentas, sempre tive dificuldades em entender aonde cada item se encaixava.

  5. MARA CELIA LOURDES ULLOA 28/10/2020 em 10:46- Responder

    Me ajudou muito!! Obrigada por compartilhar seu conhecimento!

    • Avelino Ferreira 28/10/2020 em 14:37- Responder

      Olá Mara. Se tiver qualquer dúvida, pode mandar aqui.

Deixar um comentário Cancelar resposta

Pesquisar
Categorias
  • 4 Domínios da Agilidade
  • Agile Coach
  • Agile Design Thinking
  • Agilidade
  • Artigos em Áudio
  • Cultural
  • Desenvolvedor
  • Desenvolvimento
  • Design Thinking
  • Escalar a Agilidade
  • Eventos
  • eXtreme Programming
  • Facilitação
  • Fit For Purpose
  • Flight Levels
  • Gestão
  • Gestão de Conflitos
  • Kanban
  • Management 3.0
  • Marketing
  • Métodos e Frameworks
  • Métricas
  • Negócio
  • OKR
  • Organizacional
  • Papéis
  • Práticas Ágeis
  • Product Owner
  • Produtos
  • Retrospectivas
  • RH Ágil
  • Scrum
  • Scrum Developer
  • Scrum Master
  • Software Ágil
  • Técnico
  • Testes
  • Testes Automatizados
  • Time
  • Trabalho Remoto (Home Office)
  • Uncategorized
K21 © 2019- Todos os direitos reservados
Saiba mais sobre Transformação Ágil

Obrigado!

Quem Somos

  • Nosso Time
  • Contato
  • Clientes
  • Política de Privacidade
  • Código de Conduta

Serviços

  • EVDnC
  • Transformação Ágil
  • Coaching
  • Trilha de Agilidade
  • Treinamentos

Eventos

  • RH Ágil
  • Product Summit

Contato

  • FAQ
  • WhatsApp
© 2013 - 2021 Todos os direitos Reservados
Business Evolution powered by True Agile
Cookies e Privacidade
Nós usamos cookies para lhe oferecer a melhor experiência digital durante sua navegação. Ao clicar "Aceitar Cookies", você consente com todos os cookies utilizados, em conformidade com nossa Política de Privacidade.
DetalhesAceitar Cookies
Cookies

Visão Geral

Este website utiliza cookies com intuito de melhorar sua experiência de uso e navegação. Estes cookies são organizados em diferentes categorias. Aqueles categorizados como necessários são armazenados no seu navegador pois são essenciais para o correto funcionamento das páginas e não armazenam informações pessoais ou que possam identificá-lo de alguma forma. Utilizamos alguns cookies chamados de third-party, ou seja, de outros sites, para auxiliar com outras funcionalidades não essenciais. Eles se encontram nas outras categorias listada abaixo. Explicações sobre cada categoria também podem ser vistas na lista. Optar por não autorizar estes cookies pode afetar sua experiência com algumas funcionalidades, como áudios do Spotify e Voozer, ou vídeos do  Youtube e Vimeo.
Necessários
Sempre habilitado

Cookies obrigatórios são essenciais para o funcionamento do website. Sem eles, aspectos visuais do site e algumas funcionalidades de segurança podem ser comprometidos. Importante: estes cookies não armazenam informação pessoal.

Marketing

Cookies nesta categoria são utilizados para exibição de campanhas publicitárias possivelmente do seu interesse, além de armazenar dados para envio de mailing entre outros serviços.

Performance

Cookies de performance são utilizados para compreender e analisar os principais índices de performance do website, com o intuito de auxiliar na melhoria da experiência de uso e de navegação.

Preferências

Os cookies de preferências são utilizados para armazenar preferências do visitante, permitindo que ele próprio faça escolhas de personalização de conteúdo ou conveniência de funcionalidades (como idioma desejado, por exemplo).

Funcionais

Cookies funcionais ajudam a realizar certas operações, como quando um visitante deseja compartilhar um artigo em suas mídias sociais, curtir e comentar artigos, entre outras.

Salvar e aceitar

veja a agenda completa