Histórias de usuário no Scrum: tudo o que você precisa saber

A meta é clara: você quer desenvolver um produto que ofereça alto valor agregado aos clientes. Você quer alcançar um resultado com o qual os membros da equipe e as partes interessadas fiquem satisfeitos. Mas como você atinge essa meta? Como você pode atender a todos os requisitos de um produto em etapas pequenas e completas? 

No Agile, as histórias de usuários provaram ser uma ferramenta eficiente para isso. Elas levam você passo a passo desde a primeira ideia até um produto pronto para venda. Mostrarei o que são histórias de usuários, como criá-las e como você pode se beneficiar delas.

A definição de histórias de usuários no Agile descreve os requisitos de um produto do ponto de vista do usuário. Em outras palavras, as histórias de usuários dizem a você quais recursos e funções um produto deve ter. Isso as torna uma ferramenta central para discutir e validar as necessidades dos usuários e trabalhar em sua implementação com um entendimento comum. 

As histórias de usuários oferecem uma linguagem universal que os membros da equipe, as partes interessadas e os clientes entendem e falam. Na prática, isso significa que você pode usar as histórias de usuários para desenvolver uma compreensão do produto desejado pelo cliente que deixe pouco espaço para mal-entendidos. 

Várias histórias de usuário juntas formam um caso de uso. As histórias de usuários têm sua origem no desenvolvimento de software Agile.

As histórias de usuários descrevem os requisitos e desejos de um resultado de projeto a ser criado a partir da perspectiva do cliente ou usuário. As histórias de usuários ágeis têm essa estrutura elementar:

OMS (função), deseja O QUE (meta/desejo) PORQUE (valor agregado)?

Vamos dar uma olhada mais de perto nos componentes individuais das histórias de usuários:

QUEM (USUÁRIO)

Você preenche o espaço reservado WER com o seu cliente ou um representante típico do seu grupo-alvo. O grau de detalhamento com que você descreve a OMS na história do usuário depende da própria história do usuário e do andamento do projeto. Portanto, seja detalhado o suficiente para criar uma história de usuário significativa.

O QUE (FUNÇÃO)

É aqui que você coloca os desejos do usuário. Você pode se perguntar o que o usuário espera ou precisa. Se o seu produto ainda estiver em fase inicial de desenvolvimento, você poderá formular suposições com base na sua experiência sobre as funções que o usuário espera. Se já houver um produto semelhante no mercado, você também poderá derivar as funções desejadas do feedback sobre esse produto.

POR QUE (VALOR AGREGADO)

Só o valor acrescentado mostra por que uma função é importante para o usuário. O PORQUÊ permite, portanto, uma reflexão honesta sobre o quão bem você conhece os requisitos de um cliente. Porque: É fácil incluir um requisito em uma User Story – por exemplo, porque o cliente expressa esse desejo. Mas só quando você entende por que o cliente precisa disso, você tem o contexto para implementar o requisito. Só então você pode questionar se a sugestão/desejo do cliente atende de forma eficiente à sua necessidade real - ou se pode haver uma maneira mais inteligente. Vamos ver um exemplo: 

O cliente quer uma capa de chuva para andar de bicicleta. Portanto, você poderia incluir agora o requisito “capa de chuva”. Ou você pode perguntar ao cliente por que ele precisa de uma capa de chuva. Digamos que o cliente responda “Porque não quero me molhar”. 

Isso significa que você não precisa necessariamente fornecer uma capa de chuva. Você também pode fornecer uma bicicleta com teto integrado. O importante é que a necessidade ou o problema do cliente seja resolvido com isso - ou seja, não se molhar. Quanto melhor você entender o “porquê”, melhor poderá projetar sua User Story.

O que são histórias de usuário no Agile (exemplo)?

Agora você conhece os componentes individuais das User Stories do Agile. Um exemplo de uma história de usuário Agile pode ser assim: 

Como CLIENTE Eu gostaria de UMA SENHA SEGURA***,*** PARA QUE OS DADOS DE MEUS CLIENTES SEJAM PROTEGIDOS.

Aqui está o “CLIENTE” o usuário, “UMA SENHA SEGURA” a função e “PARA QUE OS DADOS DE MEUS CLIENTES SEJAM PROTEGIDOS” o valor agregado. 

Ao trabalhar com histórias de usuários no Scrum, você adiciona critérios de aceitação a elas. Os critérios de aceitação descrevem os requisitos técnicos que as histórias de usuário devem atender no momento da aceitação. Em outras palavras: Os critérios de aceitação são os requisitos que você precisa para que uma história de usuário crie valor.

O significado das histórias de usuário Agile no backlog pode ser mais diferenciado. Porque: nos backlogs, as histórias de usuário podem não apenas descrever os requisitos, mas também representar um tipo especial de hierarquia. Há três tipos de hierarquia:

Épicos: Os épicos são áreas funcionais amplamente definidas de um produto cujo escopo concreto pode ainda não estar claro.

Características: Os recursos são características específicas de desempenho em um épico.

Histórias: As histórias são histórias técnicas de usuários Agile e histórias de usuários dentro de um recurso.

Você pode implementar esses tipos de hierarquia em um sprint. Eles criam um benefício concreto para o usuário. 

Para que você possa escrever histórias de usuários úteis no gerenciamento ágil de projetos, é fundamental que haja discussões detalhadas com todas as partes interessadas. Isso deve proporcionar a você uma compreensão abrangente do grupo-alvo e do produto a ser criado. A partir disso, você pode derivar personas, por exemplo. 

Além disso, o chamado Critérios do INVESTpara criar uma história de usuário convincente:

Independente: Uma história de usuário deve ser independente de outras histórias de usuário. Isso significa que a implementação de uma história não deve pressupor que outra história tenha sido implementada anteriormente. Isso tem a vantagem de você poder priorizar as histórias de usuários ou removê-las do backlog a qualquer momento. 

Vamos dar outra olhada no exemplo da bicicleta. Digamos que você tenha decidido instalar um pequeno teto sobre o selim da bicicleta em vez de uma capa de chuva para que o cliente não se molhe mais. Então, essa seria uma história de usuário. Mas agora você percebe que primeiro precisa desenvolver um selim mais estável ao qual o teto possa ser fixado. Essa seria uma história de usuário diferente. Ambas as histórias se baseiam uma na outra. Isso é exatamente o que você deve evitar.

É claro que, às vezes, é inevitável que você tenha de fazer uma história de usuário antes de outra. Mas, como regra geral, evite histórias de usuários para as quais você tenha que implementar primeiro 20 outras histórias de usuários.

Negociável: Escrever User Stories pode demorar um pouco - mas depois não deve ser gravado em pedra. Isso significa: Proprietário do produto As partes interessadas e os desenvolvedores devem sempre discutir e refinar juntos uma história de usuário. 

Valioso: O resultado das histórias de usuários no gerenciamento ágil de projetos deve ter valor agregado para o cliente.

Estimável: Uma história de usuário convincente permite que a equipe de desenvolvimento estime quanto esforço será necessário para implementá-la.

Pequeno: Uma história de usuário deve ser tão “pequena” que possa ser realizada em um sprint.

Testável: As histórias de usuários no Scrum devem ser testáveis. Essa é a única maneira de verificar se elas realmente podem ser implementadas na prática.

Se você não estiver familiarizado com a escrita de histórias de usuários no Agile, elas podem parecer um trabalho extra para você. No entanto, as histórias de usuários fornecem às equipes um contexto importante para suas tarefas, esclarecendo ainda mais a importância de cada tarefa.

Basicamente, é assim que você se beneficia das User Stories:

Foco no usuário: As histórias de usuários são como uma lista de tarefas orientada a problemas. Sua equipe pode usá-las para controlar as tarefas e saber exatamente como atender às necessidades dos usuários.

Cooperação holística: As histórias de usuários mostram rapidamente a todos os envolvidos o rumo que as coisas estão tomando. Dessa forma, todos podem se unir e decidir repetidamente como o usuário obterá um valor agregado particularmente alto. 

Soluções criativas: Criar histórias de usuário no desenvolvimento do software Agile resultados criativos . Porque: eles fazem com que as equipes pensem criticamente sobre a melhor solução para o produto final.

Sucessos consistentes: Cada história de usuário é um pequeno desafio. Portanto, as equipes podem comemorar um pequeno sucesso após cada história. Isso motiva você durante todo o processo de desenvolvimento.

As histórias de usuários são uma ferramenta importante no trabalho das equipes ágeis. Elas mostram repetidamente em detalhes para quem você está desenvolvendo o quê e por quê. Isso não só ajuda você a criar um produto de alta qualidade, adaptado ao grupo-alvo, mas também a manter a equipe motivada durante todo o processo. 

Para que você tenha sucesso nesse nível macro de trabalho ágil, sua organização como um todo precisa pensar e funcionar de forma ágil. Para apoiar você e sua organização nesse sentido, trabalhamos com especialistas renomados para criar Projeto Scagile projetado. Ele mostra a você, em vários webinars, como abordar corretamente uma transformação ágil. O treinamento é gratuito. Fique à vontade para dar uma olhada!

Se você quiser perguntas mais variadas para suas retrospectivas, confira nosso post sobre isso: 32 novos métodos retrospectivos para iniciantes e profissionais (com, entre outros, o Mario Kart Retro, o Marathon Retro e o Elon Musk Retro).

A propósito, um dos melhores métodos para desenvolver de forma sustentável o mindset ágil dos membros da equipe é a implementação de um Health Check ágil. Nosso Kit de construção Team-Health Check gratuito pode te ajudar a fazer as perguntas certas - é só clicar.