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!
Neste Artigo
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:
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.
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 fatiá-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!
