O foco aqui não é falar de processo ou do agile, até porque não é a minha especialidade, mas vamos mencionar rapidamente, para introduzirmos o User Story no contexto.

No processo de desenvolvimento em cascata (antes ou sem as metodologias ágeis), havia a necessidade de gerar um documento inalterável com os requisitos do produto. O que problema era que o pensado, planejado e documentado, raramente se materializava no produto entregue, gerando frustração no time, no gerente, e principalmente no cliente.

Assim, quando o agile ganhou seu espaço nas empresas, o documento de documentações técnicas tornou-se uma história contada de um usuário. Porque o detalhamento técnico pode vir em um segundo momento, quando a mesma já for priorizada e tiver o seu desenvolvimento próximo de iniciar. Até lá, tudo pode mudar, exceto o problema que o usuário quer resolver, e a sua hipótese de solução.

O que são histórias de usuário / User Stories?

Histórias de usuários são descrições curtas e simples de um “recurso desejado”, contadas pela perspectiva da pessoa que “deseja o recurso”.

Por conta disso, toda User Story possui um formato único:

• Como *<tipo de usuário>***, quero *<alguma funcionalidade>* para que *<algum motivo>*.**

Colocando em exemplos…

• Como um usuário, quero enviar múltiplos arquivos de uma única vez para a minha timeline do Facebook, para que eu possa publicar mais e mais rápido.
• Como um PRO, quero poder selecionar uma região para impulsionar os meus serviços, para que possa ser achado rapidamente por possíveis clientes.
• Como um usuário, quero agendar uma corrida para um horário específico, para que eu possa garantir que terei um motorista naquele momento.

Como criar uma User Story de sucesso?

Para que uma História do Usuário seja bem sucedida, você pode utilizar um guia, o acrônimo INVEST:

• Independente: São auto-suficientes, e não são muito impactados, caso alguma decisão técnica seja tomada na sprint.
• Negociável: Deve permitir espaço suficiente para inspecionar e adaptar a implementação com base em restrições e requisitos de negócios
• Valioso: Cada User Story precisa demonstrar o valor proposto para o seu tipo de usuário na entrega.
• Estimado: Precisa ter informações o suficiente para gerar confiança no time, tanto na hora de estimar o tempo de implementação da tarefa, até mesmo para desenvolver e testar a mesma.
• Dimensionada (Sized to Fit): Quebrar um grande valor em pequenos valores incrementais que possam ser concluídos em uma sprint.
• Testável: Saber com clareza o que é necessário para satisfazer as necessidades dos usuários e como vamos verificar se elas foram atendidas.

O que são Epics? Por que eles são tão importantes para uma Pessoa de Produto?

Existe uma definição vinda de Mike Cohn (um dos maiores nomes do Scrum), que um Epic é uma grande User History.

“When a story is too large, it is sometimes referred to as an epic.”

Novamente, não quero entrar em Agile, pois é um guarda-chuva que não é o propósito desse episódio, mas em linhas gerais, podemos assumir que o(a) PM deveria focar inicialmente bem mais em clarificar seus Epics, antes de pensar em quebrá-los em User Stories para o seu time.

Sabemos, que em algumas situações, uma história pode ocupar mais de uma sprint, e em determinados cenários, será realmente dificil saber quando aquele projeto ou funcionalidade ficará disponível para ser utilizada pelo usuário. Por conta disso, você organiza em Epics, para “trackear” a funcionalidade como um todo, mesmo com múltiplas stories.

https://www.yodiz.com/blog/what-is-epic-in-agile-methodology-definition-and-template-of-epic/

Nesse momento, você deve estar precisando de um exemplo, então vamos lá:

Epic: Upload paraAlbúm de fotos User Story: Como usuário, quero subir minhas fotos para que fiquem salvas na nuvem. User Story: Como usuário, quero subir múltiplas fotos de uma única vez para que fiquem salvas na nuvem rapidamente. User Story: Como usuário, quero nomear o meu álbum para que eu possa encontrá-lo facilmente. User Story: Como usuário, quero remover uma foto do meu álbum para que mantenha o álbum organizado. User Story: Como usuário, quero remover meu álbum para que ele não esteja mais disponível na nuvem.

O grande problema com o Epic + User Stories

Um erro que muitos times cometem é não fecharem o escopo do Epic, inserindo novos User Stories o tempo todo, o que faz a funcionalidade nunca ficar pronta, as métricas de processo ficarem prejudicadas e dar uma sensação que o time não entrega.

Por exemplo, o item acima, onde colocamos 5 Histórias do Usuário para 1 Epic. Ao longo do processo, poderíamos ainda inserir:

User Story: Como usuário, quero reorganizar minhas fotos no meu álbum para que ele fique mais organizado. User Story: Como usuário, quero remover múltiplas fotos do meu álbum para que mantenha o álbum organizado rapidamente. User Story: Como usuário, quero reorganizar meus álbuns para que eles fiquem mais organizados.

Para evitar que isso aconteça, você precisa deixar o escopo do produto e da funcionalidade muito claro. E qualquer ideia a partir daí, jogar em novos User Stories (isolados, sem precisar pertencer a uma EPIC). Elas serão priorizadas e quando for o momento certo, serão implementadas.

Uma dica para que isso não aconteça, é você definir no seu briefing do Epic, o MVP, ou seja, o mínimo viável desse EPIC, para que o time não fique pensando em melhorias e extras, ao invés focar em entregar o básico com a melhor experiência possível.

O que User Story tem a ver com Backlog e Roadmap?

Você que trabalha com produto, deve ouvir o tempo todo Backlog e Roadmap, certo? Confesso que ouvia mais a palavra Roadmap, mas ela tem sido realmente menos comentada, por conta de não termos o ano engessado, passando a ter um Roadmap mais ágil, ou se preferir, mais responsivo.

Podemos assumir que Roadmap é o mapeamento (acho que o map já deixa isso claro né?) das grandes entregas, das grandes funcionalidades, ou redesigns preparados para o ano.

O problema é que injusto demais você saber o que vai entregar daqui a 3 Quarters (trimestres). Por isso, algumas empresas passaram a utilizar a inteligência durante suas sprints, para gerar previsibilidade de entrega. Saca só!

Meu time de projeto e agile me avisa que a velocidade do meu time é entregar 20 tarefas, sendo uma relação de 1:5 para o meu epic. Ou seja, a velocidade do meu time é atender 4 Epics por sprint.

Sendo assim, considerando uma sprint semanal, eu tenho 16 Epics por mês, me dando 48 Epics por trimestre (3 meses). Está me acompanhando?

Acontece, que isso tudo vai variar, de acordo com interesse dos sócios, desejo do time, requisitos dos clientes, priorização pelo time do suporte ou o time de negócios, entre outros fatores.

Então, eu não consigo, nem devo organizar a casa para 48 Epics nos próximos 3 quarters. Pois é desperdício intelectual, já que as coisas mudam rapidamente, e o efeito cascata se torna exponencial.

Então, nesse caso, vou te dar uma dica matadora do que fazer na sua empresa!

Se fossemos fazer um evento de lançamento como a Apple e o Google fazem todo ano, quais seriam as funcionalidades apresentadas?

Essa pergunta me ajuda a pensar em Grandes lançamentos para o ano, e quebro em grandes lançamentos para o trimestre. Todo quarter eu preciso fazer um ou dois grandes lançamentos de funcionalidades para o usuário.

-Mas Bernard, você disse que consegue entregar 48 Epics, por que lançar só dois?

Essa pergunta que é a chave. Sei que terei muitas outras coisas para melhorar, lançar, corrigir ao longo do trimestre, mas quero garantir que um grande lançamento esteja inserido nele, fixo. O resto todo pode ser responsivo (alterado no planejamento do quarter.

Pensar em um grande evento de lançamento, nos ajuda a pensar no que realmente é grande, no impacto que isso vai causar no usuário, na melhor janela para enviar esse e-mail para os clientes comunicando o lançamento. Tudo isso nos ajuda muito a estruturar o ROADMAP.

Então, pensar em lançamento atuaria diretamente em EPICS e ROADMAP.

Q1: Feature 1, Feature 2 Q2: Feature 3, Feature 4 Q3: Feature 5, Feature 6 Q4: Feature 7, Feature 8

Então, você já tem mapeado as funcionalidades mais importantes que você vai lançar. Só que isso não é o suficiente para apresentar para um board. Então, você pode ainda destacar as Super Features, ou seja, o LANÇAMENTO DO ANO.

Q1: Feature 1, Feature 2 Q2: Feature 3, SUPER Feature 4 Q3: Feature 5, Feature 6 Q4: SUPER Feature 7, Feature 8

-Bernard, e se me perguntarem do resto?

Você vai dizer que faz o planejamento de 2 em 2 quarters, e vai ajustando, conforme a cadência do time. Assim, você pode apresentar o planejamento do seu Backlog para esse trimestre, e o que está planejado para o trimestre seguinte.

Então, Epics são expostos para os stakeholders, shareholders e até clientes (sim, temos empresas que deixam alguns Epics públicos), através de um Roadmap (lembrando que existem fixos e responsivos), User Stories são internos, para que o time possa entender o valor do que realmente está sendo implementado, na perspectiva do usuário. Enquanto o Backlog é a sua visão micro e curto prazo, do que precisa ser feito, para que você priorize e garanta a melhor forma de execução possível.

Critério de Aceitação

Alguns User Stories são bem complexos, e complexidade traz confusão, a kriptonita da clareza. Para resolver isso, um dos reforços da clareza da entrega do User Story é o Critério de Aceitação, onde produto e designer podem atuar lado-a-lado para criar esse documento.

Dentre todos os benefícios, um Critério de Aceitação tem 3 que valem ser destacados:

1. Ajudar programadores e testadores a planejarem os testes
2. Ajudar o time a entender melhor o objetivo da user story
3. Ajudar o P.O. a detalhar em alto nível o que é necessário para entregar valor ao cliente

Antes de mostrarmos um exemplo de um critério, vale lembrar que a História do Usuário responde essas 3 perguntas:

1. Quem é o ator? Ou seja, quem utilizará a funcionalidade?
2. Qual a ação que o ator executará?
3. Qual o objetivo da ação?

Então, a partir daí, utilizamos o Acceptance Criteria ou Critério de Aceitação, para detalhar melhor itens de usabilidade, desempenho, funcionalidade, tratamento de erros, entre outros.

Para fazer isso, você pode usar o seguinte formato:

Cenário - O nome do comportamento que será descrito Argumento - O estado inicial do cenário Quando - Ação específica que o usuário faz Então - O resultado da ação em "Quando" E - Usado para continuar qualquer uma das três declarações anteriores

Exemplo:

História do usuário: Como usuário, desejo poder solicitar o dinheiro da minha conta no caixa eletrônico para poder receber o dinheiro da minha conta rapidamente e em lugares diferentes.

Critérios de aceitação 1: Argumento: que a conta é digna de crédito E: o cartão é válido E: o distribuidor contém dinheiro Quando: o cliente solicita o dinheiro Então: verifique se a conta é debitada E: garantir que o dinheiro seja dispensado E: verifique se o cartão é devolvido

Por fim, o critério pode ser algo simples, como o exemplo acima, até mesmo formatos de moeda ou tempo, permissionamentos de usuários envolvidos, fluxos alternativos, entre muitas outras variáveis. Escolha com sabedoria quais Histórias merecem esse detalhamento, e o nível de detalhamento, para que você não gaste mais tempo e recurso do que deveria, e principalmente, que você não confunda o time, mais do que explique.

Conclusão

Se você veio de projeto, agile ou já tem grande experiência com PO, esse post pode ser algo óbvio, mas para muitos PMs ou pessoas que estão querendo migrar para esse setor, não é.

Uma coisa bacana sobre User Story é que raramente ela precisa de um Briefing. Já um Epic, raramente é iniciado sem um.

Para muitos o PRD (Product Requirement Document) morreu, pois era um documento tradicional de tudo e bastante detalhado que terá no produto. Particularmente, ele existe e está mais forte que nunca.

O PRD envolve hoje o seu Backlog e suas priorizações, assim como seus Epics e respectivos briefing, inclusive com os User Stories vinculados e Critérios de Aceitação.

De nada adianta você ser a pessoa por trás da estratégia, se você não sabe como passar isso para o time com clareza, e principalmente, saber como eles vão receber essas informações e entregar isso com qualidade para o usuário final.

Afinal, é a história do usuário, e a gente quer que ela seja feliz né?