09 User stories
9.1 O que é uma User Story
Uma user story é uma ou mais sentenças na linguagem cotidiana ou comercial do usuário final ou usuário de um sistema que captura o que um usuário faz ou precisa fazer como parte de uma função de seu trabalho. As User stories são usadas com a metodologia de desenvolvimento ágil como base para definição de funções que um Sistema de negócios pode providenciar, além de facilitar a administração de requisitos. Ela captura o “quem”, “o quê” e “porquê” de um requisito de uma maneira simples e concisa, frequentemente limitado em detalhes pelo que pode ser escrito à mão em um pequeno bloco de notas em papel.
O Product Owner, baseado em sua interação com os stakeholders, conhecimento de negócios e expertise, além das entradas do time, desenvolve User Stories que formarão o início do Backlog do Produto Priorizado para o projeto. O Backlog do Produto Priorizado representa a soma total do que pode ser completado no projeto. O objetivo deste exercício é criar User Stories refinadas e elaboradas que possam ser aprovadas, estimadas e confirmadas pelo Time Scrum. Às vezes, o Product Owner pode trazer um Analista de Negócio para ajudar na elaboração das User Stories.
Mesmo o Product Owner tendo a responsabilidade primeira na elaboração das User Stories e frequentemente realizando esse exercício por conta própria, um Workshop de redação de User Stories pode ser realizado, se assim o desejar. Nas situações da vida real, as User stories são normalmente escritas por ou para usuários de negócios ou clientes como a maneira principal de influenciar o funcionamento do Sistema a ser desenvolvido. As User stories podem ser escritas também por desenvolvedores para expressar requisitos não-funcionais (segurança, performance, qualidade, etc) No entanto, é tarefa primária do gerente do produto garantir que essas stories sejam capturadas.
# |
Backlog Item (User Story) |
Story Point |
1. |
As a Teller, I want to be able to find clients by last name, so that I can find their profile faster |
4 |
2. |
As a System Admin, I want to be able to configure user settings so that I can control access. |
2 |
3. |
As a System Admin, I want to be able to add new users when required, so that... |
2 |
4. |
As a data entry clerk, I want the system to automatically check my spelling so that... |
1 |
9.2 Criando uma user story
As User Stories aderem a uma estrutura específica, predefinida, e são uma forma simples de documentação dos requisitos e das funcionalidades desejadas pelo usuário final. Uma User Story discorre sobre três coisas acerca dos requisitos: Quem, O quê e Porquê. Os requisitos expressados nas User Stories são afirmações curtas, simples e de fácil entendimento. O formato padrão predefinido resulta em uma comunicação aprimorada entre os stakeholders e melhores estimativas pelo Time. Algumas User Stories podem ser grandes demais para serem trabalhadas numa só Sprint. Essas User Stories maiores são geralmente denominadas Epics. Uma vez que as Epics surgem no Backlog do Produto Priorizado a fim de serem completas numa próxima Sprint, elas são decompostas em User Stories menores.
O Backlog do Produto priorizado é uma lista dinâmica que é atualizada continuamente devido a repriorização, além de User Stories novas, refinadas e as vezes apagadas. Essas atualizações do backlog são tipicamente o resultado da mudança dos requisitos de negócio.
Uma vez que o representante do cliente elabora uma user story, ela é escrita num bloco de notas com o nome e uma descrição breve. Se o desenvolvedor e o representante do cliente acharem a user story deficitária de alguma maneira (muito grande, complicada ou imprecisa), ela será reescrita até que se torne satisfatória – geralmente com a utilização das guias INVEST (mais informações sobre o INVEST abaixo). Comumente, user stories não devem ser definidas depois de anotadas, uma vez que os requisitos tendem a mudar ao longo do ciclo de vida do desenvolvimento, que os processos ágeis tratam de forma a não os esculpi-los em pedra antecipadamente.
9.3 Formato
"As a <role>, I want <goal/desire> so that <benefit>" (como um <função>, eu quero <meta/desejo> pois isso <benefício>)
Exemplo de uma User Story:
Como um Administrador de Banco de Dados, eu devo ser capaz de reverter um número selecionado de dados para que a versão desejada deles seja restaurada.
9.4 Critério de Aceitação da User Story
Cada User Story tem um critério de aceitação associado. As User Stories são subjetivas, portanto os critérios de aceitação providenciam a objetividade necessária para uma User Story ser considerada Pronta ou Não Pronta durante a Revisão da Sprint. Os critérios de Aceitação dão clareza ao Time acerca do que é esperado de uma User Story, remove ambiguidades de requisitos e ajuda no alinhamento das expectativas. O Product Owner define e comunica o Critério de Aceitação para o Time Scrum. Nas reuniões de Revisão da Sprint, o Critério de Aceitação provê o contexto para que o Product Owner decida se uma User Story foi completada satisfatoriamente. É importante e uma responsabilidade do Scrum Master a garantia de que o Product Owner não modifique o Critério de Aceitação de uma User Story comprometida no meio de uma Sprint.
9.5 INVEST
Letter |
Meaning |
|
Description |
I |
Independent (Independente) |
|
A user story deve ser independente, de uma maneira que não haja qualquer dependência inerente a outra user story. |
N |
Negotiable (Negociável) |
|
As User stories, até que façam parte de uma iteração, podem sempre ser mudadas e reescritas. |
V |
Valuable (Valiosa) |
|
Uma user story deve entregar valor ao usuário final. |
E |
Estimable (Estimável) |
|
Você deve sempre ser capaz de estimar o tamanho de uma user story. |
S |
Scalable (small sized) (Escalonável – pequeno) |
|
As User stories não devem ser tão grandes que se torne impossível de planejar/dividi-las em tarefas/planejar com um certo nível de certeza. |
T |
Testable (Testável) |
|
A user story ou sua descrição relacionada deve providenciar a informação necessária para que se faça possível o teste de desenvolvimento. |