Histórias de usuários: a chave para aumentar a satisfação do cliente

A satisfação do cliente é uma das metas mais básicas de um negócio e pode ser alcançada fornecendo uma solução que atenda às necessidades dos clientes. Estruturas de desenvolvimento ágil, como Scrum e Kanban, contam com histórias de usuários para expressar os requisitos do usuário. Esta ferramenta simples se torna valiosa para a equipe de gerenciamento e desenvolvimento de produtos ao longo do trabalho. Neste artigo, forneceremos uma visão geral das histórias do usuário, por que elas são importantes, como elas são usadas e práticas recomendadas para escrever uma história eficaz que represente as necessidades do cliente.

O que é uma história de usuário?

De acordo com um dos iniciadores do movimento ágil Alistair Cockburn, "Um cartão de história é a promessa de uma conversa." Especificamente, é uma conversa com seu cliente que resulta em uma descrição de uma função de software da perspectiva dele. Esta é a base de uma história de usuário; uma parte essencial do ciclo de vida do desenvolvimento de software ágil e Lean . Temas, iniciativas, épicos e histórias são todos blocos de construção, de grandes a pequenos, que ajudam a organizar a funcionalidade necessária para construir uma solução de software centrada no usuário. Os termos podem parecer familiares em termos de literatura, e com razão. Uma história de usuário é uma narrativa simples, enquanto histórias relacionadas compõem um épico. Veja como esses termos trabalham juntos:

Temas: um propósito ambicioso ou uma meta de alto nível.
Iniciativa: uma coleção de épicos que ajudarão a alcançar o objetivo principal.
Épicos: uma necessidade de negócios de alto nível ou uma grande história de usuário. Eles são difíceis de implementar em uma única iteração. Por isso, são divididos em histórias menores. Um épico inteiro geralmente é incluído em um único lançamento.
Histórias de usuários: requisitos curtos ou cenários de usuário que fornecem algum valor e são escritos na perspectiva do usuário. Cada história é limitada por um sprint ou iteração.

Um exemplo disso pode ser visto aqui:

O tema (extrema esquerda) é a meta de negócios de alto nível composta por iniciativas associadas, épicos que apoiam essas iniciativas e histórias (extrema direita) que descrevem requisitos granulares.

Uma organização de desenvolvimento de software pode ter o objetivo elevado de modernizar sua solução. Para realizar esta tarefa, eles devem proporcionar uma experiência inesquecível ao usuário. Por exemplo, essa experiência de usuário deve fornecer uma interface web moderna, ser executada rapidamente e trabalhar em uma variedade de dispositivos de usuário. Neste cenário, cada um desses épicos será dividido em histórias específicas de usuários.

O que é um épico como história de usuário?

Um épico é uma necessidade de negócios de alto nível ou uma grande história de usuário. Eles são difíceis de implementar de uma vez só ou em uma única iteração. Por isso, são divididos em histórias menores. O benefício dos épicos é a capacidade de desenvolver e colaborar em ideias maiores antes de criar inúmeras histórias de usuários. O épico pode ser mantido como a ideia original, criando um ponto de referência futuro.

Qual é o propósito de uma história de usuário?

Uma história de usuário destina-se a ajudar no desenvolvimento de uma solução de software. Infelizmente, não é incomum desenvolver uma solução de software que simplesmente não atrai a base de clientes pretendida. As histórias de usuários são destinadas a mitigar esse risco, fornecendo uma compreensão clara e completa dos requisitos dos usuários finais que garantem que os recursos de software atendam às expectativas.

Como as empresas usam histórias de usuários?

As histórias de usuários são um dos principais artefatos usados no desenvolvimento ágil. Elas são criadas para descrever recursos e requisitos funcionais e não funcionais e compõem uma lista priorizada de funcionalidades destinadas ao desenvolvimento. Esta lista é chamada de backlog do produto.

As histórias de usuários se tornam parte de um mapa de história de usuário, um método usado para encomendar histórias de usuários ao longo de um eixo horizontal e vertical, a fim de representar diferentes níveis de usabilidade. O eixo horizontal percorre as atividades que explicam como o usuário interage com o sistema para realizar uma função. O eixo vertical representa níveis crescentes de complexidade. A primeira linha é uma representação fundamental da função. A próxima linha adiciona um pouco mais de funcionalidade e assim por diante. Cada história de usuário é atribuída a um ponto de história ou a uma estimativa teórica de esforço ou dificuldade que será necessária para desenvolver a funcionalidade. Muitas organizações usam ferramentas automatizadas de mapeamento de histórias. As ferramentas mais populares são Jira, Rally by CA, StoriesOnBoard e FeatureMap.

Modelo de mapeamento de história de usuário

Você também pode usar este modelo para construir seu próprio mapa de histórias. Você pode concluir o modelo usando o Microsoft Word ou recriá-lo usando notas Post-it grudadas em uma parede. Ajuste o número de caixas com base nas necessidades de desenvolvimento da sua organização.

Baixe o modelo do Word

Quais são as características de uma história de usuário?

Independentemente da estrutura ágil usada, Extreme Programming (XP), Kanban, DAD (Disciplined Agile Delivery), AMDD ou Scrum, as histórias de usuários são as mesmas. A história do usuário descreve o tipo de usuário: a persona, o recurso que deseja e o benefício que espera experimentar a partir do recurso. Uma boa história do usuário é escrita seguindo a estrutura do recurso de função (RGB):

Como , quero , para que .

A história do usuário deve ter as seguintes qualidades:

Ser completa o suficiente para demonstrar o valor do usuário.
Ser centrada no usuário.
Começar com um épico.
Ser curta, simples e clara.
Conter arquivos de suporte e documentação, se necessário.
Ser abrangente o suficiente para demonstrar valor, mas simples o suficiente para se desenvolver em uma única iteração.
Ser escrita com base nas sugestões de todas as partes interessadas.
Ser flexível e negociável sem afetar outras histórias ou recursos.
Ser fácil de testar.
Incluir critérios de aceitação (condições de satisfação) para os testadores.

Você pode ouvir os termos que histórias de usuários e requisitos do sistema usaram de forma intercambiável. Tradicionalmente, o desenvolvimento da Waterfallusa os requisitos do sistema para definir como uma solução de software deve funcionar. Eles entram em detalhes extensos que incluem riscos, escopo e outras diretrizes específicas para o desenvolvimento. As histórias de usuários, por outro lado, são simples, promovem discussões e apoiam a metodologia de desenvolvimento ágil, que abraça a colaboração e a mudança.

Como mencionado anteriormente, as histórias de usuários devem ser simples, mas completas. Por exemplo, uma boa história de usuário pode ser lida assim:

Como cliente do banco, quero poder depositar um cheque on-line, para que não precise ir até o banco.

Aqui está um exemplo de uma história de usuário que é detalhada demais:

Como cliente do banco, quero poder depositar um cheque on-line, visualizar e imprimir relatórios de depósitos para que não precise ir até o banco.

O que é um ponto de história?

Cada história de usuário é atribuída a um ponto de história associado, uma medição do esforço ou dificuldade necessário para desenvolvê-la e implementá-la. As equipes podem usar números de um dígito (1, 2, 3), múltiplos dígitos (100, 200, 300) ou qualquer outro formato de número escolhido. A proporção é o fator importante. Por exemplo, uma história que tem 200 pontos de história exigirá o dobro de esforço que uma atribuída a 100 pontos de história.

O que são critérios de aceitação do usuário?

Os critérios de aceitação, também conhecidos como condições de satisfação, garantem que a solução de software satisfaça as necessidades dos usuários finais ou das partes interessadas. Esses critérios podem incluir requisitos de desempenho, padrões, cenários e regras de comportamento do sistema. A equipe de teste usa critérios de aceitação para verificar se o desenvolvimento está concluído. Uma vez que esses parâmetros são cumpridos, a história ou recurso é considerado "concluído".

Como escrever uma história de usuário eficaz

Escrever suas primeiras histórias de usuário pode ser difícil, especialmente porque elas são a base para a funcionalidade do seu produto. As histórias de usuários são mais comumente desenvolvidas durante o estágio inicial de desenvolvimento e usadas no planejamento de iterações e sprints, mas podem ser criadas a qualquer momento (no início, para fornecer um escopo de todo o projeto/solução; na construção, para identificar novas histórias, remover histórias desnecessárias e dividir histórias em pedaços menores; transição) e adicionadas ao backlog para a próxima iteração.

As 10 dicas a seguir o ajudarão a criar histórias de usuários eficazes:

Coloque os usuários em primeiro lugar: o objetivo de uma história de usuário é demonstrar a funcionalidade do ponto de vista de um usuário. Certifique-se de entrevistar ou fazer pesquisas com usuários e incluir informações factuais definidas pelo usuário. Em alguns casos, o usuário pode não ser uma pessoa, mas sim um sistema.
Defina personas: entender seus usuários é um elemento essencial para escrever uma história de usuário. Crie personagens fictícios que representem seu público-alvo final (o que pode incluir consumidores, compradores, compradores frequentes, contadores e profissionais de RH). Comportamentos de compra, problemas que eles estão buscando resolver e as metas gerais são todas informações importantes para ter sobre seu cliente ideal. Use esses nomes de persona em vez da função de usuário genérico ao escrever suas histórias.
Colabore: certifique-se de fazer com que todas as partes interessadas relevantes em uma sala colaborem durante a criação de histórias de usuários. Gerentes de produtos, engenheiros/desenvolvedores, testadores, suporte ao cliente, vendas e o cliente devem estar todos representados.
Mantenha a simplicidade: mantenha a história simples e clara. Use uma voz ativa e foque apenas em fatos importantes.
Comece com épicos e refine: comece com uma história de usuário maior para entender completamente a funcionalidade geral e, em seguida, aprofundar os detalhes do recurso real. Cada etapa de um processo maior deve se tornar uma história única. Este processo permite que você faça com que a história se encaixe em um único sprint ou iteração.
Inclua critérios de aceitação: escreva critérios de aceitação que definem o que constitui "concluído" para essa história em particular. Os critérios de aceitação são um colaborador perfeito para testar casos que a equipe de teste usará para garantir que o recurso esteja pronto para o usuário.
Comece com adesivos Post-it ou cartões de índice: quando as histórias de usuários surgiram pela primeira vez como parte da Extreme Programming (XP), elas foram capturadas em cartões de índice simples. Usar este método incentiva a colaboração e a discussão, a visibilidade e a transparência, e é uma maneira fácil de mover as coisas e o storyboard em um ambiente colaborativo.
Exiba histórias de usuários em uma área acessível: tornar a história do usuário visível em uma área aberta, como uma parede ou um quadro branco, incentiva a colaboração em todo o projeto de desenvolvimento. A exibição da história pode ser aprimorada com diagramas, maquetes, diagramas de fluxo de trabalho, mapas de histórias e esboços.
Receba bem o feedback: o desenvolvimento ágil abraça a flexibilidade. O feedback permite refinar a funcionalidade para garantir que o produto esteja entregando valor ao usuário.
Inclua estimativas de tempo: o tempo que leva para concluir o desenvolvimento com base na história de um usuário é importante para planejar iterações e lançamentos. Estimativas de tempo podem ajudar na atribuição de tarefas e subtarefas aos membros da equipe.

Existem duas técnicas principais que podem ajudá-lo na escrita de histórias de usuários:

Três Cs: inaugurada por Ron Jeffries em 2001, a fórmula Três Cs inclui, um cartão ou adesivo post-it, uma conversa entre os usuários, desenvolvedores, testadores e proprietários de produtos sobre o recurso e a confirmação de que o objetivo foi atingido.
INVEST: este critério, introduzido por Bill Wake em 2003 e popularizado pelo livro de Mark Cohn, User Stories Applied for Agile Software Development, avalia o valor de uma história de usuário garantindo que ela seja independente (pode ser desenvolvida em qualquer sequência), negociável, valiosa (para um usuário ou empresa), estimada (para conclusão), pequena (design, teste e código em uma única iteração), e testável.

Para saber mais sobre como escrever uma história de usuário e obter dicas e modelos para ajudá-lo a começar, leia How to Write a User Story in Software Development that Actually Focuses on the User.

Quem escreve a história do usuário?

Não se trata necessariamente de quem escreve a história do usuário, mas de quem está envolvido no processo de desenvolvimento da história do usuário. O objetivo é uma discussão colaborativa que resulta em uma história de usuário. Gerentes de produtos, engenheiros/desenvolvedores, testadores, suporte ao cliente, vendas, e o mais importante, o cliente, devem participar do processo. O gerente de produto ou proprietário do produto normalmente é proprietário das histórias do usuário durante todo o ciclo de vida do desenvolvimento.

Qual é a definição de concluído no método ágil?

Cada equipe terá sua própria definição de concluído ou completo no desenvolvimento ágil, e essa definição pode variar de acordo com o que está sendo avaliado para conclusão; uma história de usuário, sprint ou lançamento completo. Existem critérios que podem ser colocados em prática para garantir que um recurso ou função esteja verdadeiramente concluído. A lista de verificação de critérios pode incluir o seguinte:

O código está escrito?
O código foi testado?
O recurso atende aos critérios de aceitação?
O recurso se integra e funciona com a solução existente?
As especificações técnicas do produto foram atualizadas?
A documentação do produto foi atualizada?

Casos de uso e histórias de usuário são a mesma coisa?

Os termos história do usuário e caso de uso são semelhantes, mas os casos de uso contêm detalhes muito mais granulares em comparação com uma história de usuário. Uma história de usuário é escrita durante uma discussão colaborativa e representa a perspectiva de um usuário. Ela inclui o objetivo e os critérios de aceitação do usuário.

Casos de uso e histórias de usuário são a mesma coisa?

Essas mesmas informações estão incluídas em um caso de uso, mas o caso de uso vai ainda mais fundo e descreve os requisitos funcionais da solução, incluindo todos os caminhos da interação usuário/sistema e possíveis riscos. Muitos projetos de desenvolvimento integrarão a criação de histórias do usuário, o mapeamento de histórias e os casos de uso para construir um produto completo e minucioso.

Exemplos, benefícios e desafios da história do usuário

As histórias de usuários geralmente são escritas com base em atributos funcionais. Por exemplo: "Como cliente, quero depositar um cheque eletronicamente, para evitar dirigir até o banco ou caixa eletrônico." No entanto, existem características não funcionais, ou restrições técnicas, que também são importantes. Usando este mesmo exemplo bancário, as restrições mais técnicas podem ser escritas da seguinte forma: "Como cliente, quero depositar 12 cheques em uma única transação eletrônica." Entender os detalhes específicos (que podem parecer mais técnicos) permite que a equipe de desenvolvimento pense nas restrições que pode ter que colocar em uma história de usuário aberta para torná-la viável.

Modelos de história de usuário e outros modelos ágeis estão disponíveis para download aqui.

Benefícios da história do usuário

As histórias de usuários são um elemento comum do desenvolvimento ágil e usá-las adequadamente oferece amplos benefícios para aqueles que estão desenvolvendo a solução e para o cliente que usa o software.

Benefício do cliente	Benefício do fornecedor de software
Encontre maior valor na solução de software.	Aumente a vantagem competitiva.
Crie um relacionamento positivo e colaborativo com o fornecedor.	Incentive a colaboração e a cooperação.
Aumente a satisfação.	Impulsione a transparência.
Elimine detalhes técnicos para incluir clientes e partes interessadas não técnicas.	Reduza o risco.
Concentre-se nas necessidades do cliente.	Aumente a satisfação do cliente.
	Concentre-se no valor.
	Evite ajustes desnecessários no backlog.
	Elimine detalhes técnicos que podem dificultar a colaboração.
	Desenvolva soluções criativas.
	Apoie a flexibilidade do desenvolvimento ágil.

Desafios da história do usuário

Como em qualquer projeto de negócios, há desafios que surgem. O livro User Stories Applied for Agile Software, de Mike Cohn, identifica o principal problema no desenvolvimento de software com esta simples observação: "Os requisitos de software são um problema de comunicação". O processo de desenvolvimento da história do usuário destina-se a sanar esse desafio, mas o aumento da comunicação pode parecer tedioso para algumas partes interessadas internas. Desafios da história do usuário

Os desafios adicionais incluem o seguinte:

Garantir que a história do usuário seja abrangente o suficiente para demonstrar valor, mas simples o suficiente para se desenvolver em uma única iteração.
Concentrar-se em como construir e incluir detalhes técnicos que são desnecessários nesta fase do desenvolvimento.
Conversas e colaboração podem parecer demoradas e assustadoras.

As histórias de usuários ajudam a impedir que as organizações de desenvolvimento de software adotem uma abordagem tendenciosa e orientada por requisitos e mudem para uma abordagem colaborativa e centrada no usuário. Elas são simples, diretas e representativas das expectativas do cliente. Essa tática incentiva conversas entre partes interessadas internas e clientes, resultando em um produto mais competitivo que é valioso para as pessoas mais importantes da sua empresa: os usuários.

Melhore a visibilidade de histórias de usuários com o Smartsheet for Software Development

Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.

Ligue os seus colaboradores, processos e ferramentas com uma plataforma simples e fácil de utilizar.

Experimente o Smartsheet gratuitamente Get a Free Smartsheet Demo