No Scrum, estimar o valor é imprescindível para o andamento do projeto. Afinal, a estimativa ajuda o Product Owner a entender o valor de cada item e a organizar o Backlog do Produto. Para isso, existem as Histórias do Usuário e os Critérios de Aceitação.

Primeiramente, antes de falar sobre as histórias, você precisa entender o Backlog do Produto como o artefato mais importante do Scrum: é uma lista ordenada de requisitos do produto que será construído. Suas funcionalidades, características, tecnologias, melhorias e correções são descritas nesta lista, que será organizada de acordo com a prioridade, o risco e o valor do negócio. Tudo isso deve se alinhar à Meta do Produto, ou seja, o objetivo geral do projeto.

Em um primeiro momento, o Backlog do Produto apenas estabelece os requisitos que inicialmente já são conhecidos e melhor entendidos, tanto pelo cliente, quanto pela equipe. É um documento dinâmico, cuja função é reconhecer o que precisa podem adicionar ao produto para que ele seja mais útil e competitivo. A qualquer momento, o Product Owner pode atualizá-lo de acordo com seus próprios critérios e métricas.

Os recursos adicionados ao Backlog são comumente escritos em formato de Histórias de Usuário. O backlog aponta os incrementos que serão construídos, classificados na ordem relativa que devem ser construídos. O Product Owner é responsável por definir para a Equipe de Desenvolvimento quais Histórias são prioridade. 

O que são Histórias do Usuário?

Uma história é uma breve descrição onde se explica de forma clara e concisa, a necessidade sentida por um usuário final, do ponto de vista dele. O futuro produto deverá fornecer uma funcionalidade que atenda essa carência.

No exemplo a seguir, você consegue visualizar bem como elas são escritas:

“Como leitor, quero pesquisar pelo nome do livro para ver qual é seu preço.”

Ou seja, a fórmula é:

Como {papel}, quero {fazer algo}, para que {propósito}.

Depois de feita a descrição, vem a fase das conversas, que negocia e documenta todos os detalhes da solução na forma de Critérios de Aceitação. Neste momento de discussão, acontece toda a compreensão a respeito do que a funcionalidade precisa conter para gerar valor ao negócio e retorno do capital investido. O Time e o Product Owner, através das Histórias, criam a solução que o cliente necessita. Tendo isso em mente, seguem para os Critérios de Aceitação.

Critérios de Aceitação

Existe uma forma simples de definir os Critérios de Aceitação da História: escrever atrás do post-it uma lista com os itens do negócio que mostram como utilizar a função que será construída. Dessa maneira, o Product Owner juntamente com o cliente validam se a História foi concluída de forma satisfatória.

A descrição mostra resumidamente o requisito ao qual a História de Usuário vai resolver. Do mesmo modo, os Critérios de Aceitação precisam ser curtos e diretos, trazendo uma listagem simples dos itens que auxiliarão na validação e conferência da história e. Eles servirão para lembrar os requisitos de negócio que o produto precisa atender, como por exemplo: 

• Critério 1: a pesquisa deve ser pelo nome do livro; 
• Critério 2: o resultado deve mostrar o nome do livro ao lado do preço;
• Critério 3: caso o livro não seja encontrado, devemos informar que o livro não está disponível na nossa loja. 

Para complementar o entendimento das Histórias, o Product Owner pode ainda definir especificações do negócio, protótipos, ou outros documentos específicos.

Confira 5 dicas para criar boas Histórias do Usuário

Bom, agora que você já sabe para que servem as Histórias do Usuário e como definir os Critérios de Aceitação, vamos às 5 dicas práticas essenciais para construir histórias realmente úteis:

1. As histórias não devem falar com precisão da funcionalidade

Na verdade, elas são como um lembrete de que existe a demanda desta função, ou como uma promessa de discutir sobre essa parte do produto que é desejável. Portanto, não precisam ser completas e detalhadas ao ponto que os Desenvolvedores não precisem de mais detalhes. Pelo contrário, constituem apenas o “pontapé inicial” do desenvolvimento. Só serão úteis quando seguidas por diversas conversas entre as partes interessadas, que vão discutir os detalhes necessários para sua construção. Sendo assim, a história deve encorajar os Desenvolvedores a pedirem mais detalhes ao cliente, promovendo mais comunicação entre eles.

2. O ideal é que cada história caiba em um post-it 

Cada história deve ter o tamanho certo para um desenvolvimento incremental e iterativo. Dessa forma, o futuro Planejamento da Sprint se torna mais fácil. 

3. Utilize Personas

Personas definem perfis que representarão os seus clientes, pois são construídas com base nos seus interesses, práticas e necessidades. São um poderoso instrumento para conhecer seu usuário final, e por esse motivo auxiliam na definição de Histórias do Usuário. 

4. Toda boa história deve ser INVEST

Ou seja, as histórias devem ser: 

• Independentes. Quer dizer, as histórias não são dependentes entre si, seu desenvolvimento é criado apenas com base no valor e importância;
• Negociáveis, pois essa etapa é apenas um ponto de partida onde devem ser considerados os desejos do usuário;
• Valiosas, e no caso, cada item contribui para o valor do produto, normalmente sendo a base para a ordem do desenvolvimento;
• Estimáveis, ou seja, os Desenvolvedores precisam ser capazes de estimar o seu tamanho;
• Pequenas, pois dessa forma serão reduzidas as incertezas;
• Testáveis. Deve ser possível validar se atingem os critérios de aceitação. 

 

5. Saiba diferenciar Histórias de Usuário e Épicos

É natural dentro de um processo iterativo que uma história acabe se dividindo em outras. Épico é uma espécie de História do Usuário que é muito grande, não foi detalhada ou ainda gera muita incerteza. Dessa forma, não poderá ser transformado em incremento do produto. O trabalho da equipe, diante de um Épico, é dividi-lo em histórias menores, mais detalhadas e compreendidas com mais facilidade.

 

Gostou das dicas? Comente aqui! Ficou com alguma dúvida, tem uma sugestão, ou outro ponto de vista? Se esse for o caso, também não deixe de comentar.

 

Até mais!