Já entendemos o que é uma história no Scrum e como trabalhar histórias usando o INVEST. Vamos agora dar uma olhada em como classificar essas histórias.

Como já vimos, histórias são os requisitos do projeto/produto sendo trabalhado. As histórias são mantidas no Product Backlog e ordenadas de acordo com a prioridade de trabalho. Assim é natural termos diversas histórias para trabalhar em nosso Backlog.

Considerando que produtos são criados ou desenvolvidos com a colaboração de todo o time, além de agentes externos, como stakeholders, gerentes de produto, etc., todos devem ser incentivados a darem as suas contribuições como histórias. Entretanto, somente o PO pode incluir histórias no Product Backlog, visto que é dele a responsabilidade pelo ROI da empreitada. No ScrumHalf, por exemplo, qualquer participante do projeto pode escrever e sugerir uma história, mas somente o PO pode aceitar histórias. Ou seja, histórias propostas tem um repositório próprio, onde podem ser avaliadas pelo PO e aceitas no Product Backlog, se assim ele desejar.

Tanto o proponente de uma história como o PO podem classificar a história para facilitar o entendimento da mesma em seu contexto. No caso do ScrumHalf, as histórias podem ser classificadas como Feature, Épico, Bug ou Técnica. Cada uma das classificações possui um ícone específico, que é apesentado no Product Backlog para facilitar o trabalho do time.

Features são as histórias padrão de um projeto. Ou seja, tem como resultado alguma funcionalidade ou característica nova que é claramente percebida como valor pelo cliente. Além disso, já estão no nível correto de abstração para que o DevTeam possa trabalhar. Independentemente de seu tamanho, atendem ao INVEST e quando Preparadas poderão ser incluídas em uma Sprint.

Épicos são histórias ainda muito grandes, em um nível de abstração muito alto ou que careçam de detalhamento maior. Ou seja, para serem trabalhadas, ainda terão que ser melhor detalhadas e, na maioria das vezes, particionadas em histórias menores, que atendam ao INVEST.

Bugs, como o próprio nome já diz, são problemas encontrados no trabalho desenvolvido e que precisam ser corrigidos para que o produto se comporte de forma correta. São correções que o time precisa realizar.

Técnicas são de uma forma geral associadas a requisitos não funcionais de um projeto, ou seja, atividades a serem feitas que não traduzem diretamente valor para o usuário ou cliente, como atividades ligadas a infraestrutura do projeto/produto ou tecnologia utilizada, p.ex. Em projetos de software é comum serem classificadas como Técnicas histórias ligadas a infraestrutura do projeto e da equipe, refatoramento, mudanças de tecnologia e spikes. Alguns times classificam bugs também como histórias técnicas. No ScrumHalf preferimos separar, pois entendemos que Bugs devem ser destacados de forma a merecer atenção diferenciada do Time como um todo.

E o seu time? Já trabalham classificando Histórias? Como distinguem os diversos tipos visualmente? Que tipos de histórias são consideradas Técnicas? Conta para a gente aí nos comentários.

Bom Scrum. 🙂