Entendendo User Stories

Rodrigo Yoshima – Técnico em Processamento de Dados pela UNESP, bacharel em Administração de

Empresas pelo Mackenzie-SP, certificado em UML 2.0 pela OMG e também certificado Scrum Master,
possui 14 anos de experiência em gestão e desenvolvimento de software em projetos de missão crítica
para grandes indústrias, bancos e hospitais. É instrutor de processos e arquiteto da ASPERCOM.

Fonte: revista Mundo Java nº 32.

Muitas empresas buscam modelos ágeis para desenvolvimento de software e esta busca
se deve principalmente à adoção e divulgação do Scrum como prática de gerenciamento de
projetos aqui no Brasil. Um pilar muito importante para qualquer metodologia ágil é a ordem de
construção das funcionalidades: no Scrum chamamos isso de "Product Backlog", no OpenUP
chamamos isso de"Lista de Itens de Trabalho", na FDD chamamos isso de "Lista de
Funcionalidades", no Extreme Programming a fila de construção não tem um nome definido, mas
seriam as histórias que ainda não fazem parte da iteração corrente. De qualquer forma, em todas
as metodologias ágeis nós trabalhamos com uma fila de construção composta por itens de
trabalho. Uma das maneiras mais comuns de manifestar esses itens de trabalho é utilizar User
Stories (ou histórias do usuário).

User Story é uma técnica leve e ágil que organiza o planejamento do projeto. Kent Beck
cunhou este termo dentro da metodologia Extreme Programming. O princípio básico desta
técnica é favorecer a comunicação. A comunicação"face-a-face" é a melhor maneira de
especificar juntamente com os usuários o que o software deve fazer. Assim, a técnica fortalece o
envolvimento dos usuários ou da área de negócios da empresa no desenvolvimento do projeto.

Na tabela 1 nós temos um exemplo de uma planilha com a Fila de Construção de um

software baseado em User Stories. Este exemplo foi retirado do artigo "Entregue Software
Funcionando! Gerenciamento de Projeto Ágil", da Mundo Java edição número 26. Nesta planilha,
ordenamos as histórias, separando-as em iterações de acordo com o tamanho funcional de cada
história (pontos) e na velocidade da equipe (quantos pontos a equipe consegue entregar dentro
da iteração).

ID Funcionalidade Iteração Pontos

1 Entrada do pedido(simples) 1 8
2 Interface de transmissão de dados vendedor <-> ERP 2 2
3 Integração do pedido (vendedor -> ERP) 2 5
4 Entrada do pedido: cálculo de preços e impostos 3 5
5 Integração de dados de preços (ERP -> vendedor) 3 2
6 Integração de dados de impostos (ERP -> vendedor) 3 2
7 Entrada do pedido: vendas parceladas 4 3
8 Entrada do pedido: limite crédito 4 3
9 Consulta informações do cliente 5 3
10 Integração de clientes (ERP -> vendedor) 5 5
11 Consulta informações de produtos 6 5
12 Integração de produtos (ERP > vendedor) 6 1
13 Consulta notas fiscais e integração (ERP -> vendedor) 7 5
Tabela 1. Exemplo de fila de construção com stories.
O que é uma User Story?
Segundo Kent Beck, o criador do conceito, uma Story é uma unidade funcional de
planejamento visível para o usuário/cliente. Essa definição não é muito amigável para quem está
iniciando na técnica, porém, é a melhor definição para as Stories. Olhe novamente a tabela 1.
Esta lista é um conjunto ordenado de itens a fazer, sendo que cada item traz valor para o
usuário/cliente. O usuário pode dar a sua opinião sobre o que é mais prioritário e o que deve ser
entregue antes ou depois. Isso auxilia o próprio usuário a planejar as iterações e os releases.
Além de uma planilha eletrônica é muito comum utilizarmos fichas pautadas para manifestar as
Stories. Ficha pautada (lndex Card) são cartões em papel à venda em qualquer papelaria.

Figura 1. Exemplo de User Story em ficha pautada.

Usar fichas pautadas não é um mito das metodologias ágeis! Eu uso e muitos projetos
que tenho contato também estão utilizando Stories em cartões. O motivo para fugir de planilhas
eletrônicas e ferramentas de gerenciamento de projeto é exatamente favorecer a comunicação
"face-a-face" com o usuário sobre algo palpável e visível fisicamente. Geralmente nós colocamos
os cartões fixados num espaço na parede da sala do projeto, onde todos podem ver. Visibilidade
é um ponto-chave! Em todo momento você e a sua equipe estarão com as Stories logo à frente.
Isso beneficia o foco nos objetivos da iteração e também facilita conversas com o cliente e entre
a própria equipe.

Logicamente que falamos num "ambiente Extreme Programming", no qual outras

práticas auxiliam uma comunicação rica com todos os envolvidos para o benefício do projeto. É
importante que a equipe esteja toda junta num mesmo espaço físico, que não exista barreiras e
facções dentro da equipe (divisões rígidas entre analistas, programadores, testers etc.) e
também é importante que o usuário/cliente participe ativamente do projeto. Além disso, mais
uma prática importante é suporte para este tipo de interação com o usuário/cliente: o contrato
de escopo negociável (vide referência). Nós utilizamos artefatos leves como um cartão para que
exista MUITA conversa quando aquele cartão for desenvolvido, focando o que é mais importante
para o usuário sem ter discussões contratuais ou dissensões sobre controle de escopo. Uma User
Story não é uma especificação formal, mas sim um convite a uma conversa rica que beneficia a
todos no projeto.

Dois conceitos importantes também são defendidos por Kent Beck: o usuário/cliente é o
responsável por escrever as histórias e elas devem ser estimadas rapidamente. O usuário se
responsabilizar por manter as Stories é uma prática importante: com isso, o usuário passa a
participar mais ativamente, controlando a equipe técnica (os desenvolvedores) dentro do
planejamento.

Sobre a estimativa, o peso funcional que você dá para uma Story é um importante
parâmetro para o usuário/cliente tomar decisões sobre o rumo do projeto. Essa decisão é
sempre baseada em retorno sobre investimento (ROI).

Figura 2. Um conjunto de Stories de um sofware de rede social.

Imagine o cenário descrito nas Stories da figura 2. Como o usuário é o responsável pelas
Stories, ele geralmente sabe o valor de negócio de cada cartão. A base do planejamento ágil é
tomar decisões a respeito do que entra na próxima iteração levando-se em consideração a
capacidade de produção da equipe (conhecido como velocidade) e o valor de negócio agregado.
Nesse exercício é imprescindível saber o tamanho funcional da história associado ao seu valor
para os usuários.

Levando-se em consideração que a cada iteração que termina temos software

funcionando para que o usuário/cliente use o que está sendo construído, esse contato com o
sistema sempre muda a "cabeça" do usuário e novas Stories emergem ou podem ser descartadas
(nem sempre mudanças são para aumentar o escopo). Criar histórias, quebrar histórias, fundir
histórias, rasgar histórias, atribuir peso funcional e saber o valor de negócio é a base para o
desenvolvimento ágil.

Existem algumas características sobre as histórias que permitem que elas sejam
estimadas rapidamente. Urna User Story tem que ser funcionalmente pequena para que a equipe
tenha segurança na sua estimativa. Se a história é grande demais será difícil estimá-la, assim é
melhor quebrá-la em histórias menores. A equipe é responsável por estimar o esforço. Como
podemos ver, a técnica é completamente relacionada com planejamento do projeto, sem precisar
de métricas dispendiosas e nem das famosas "gordurinhas" ou "pulmões" irracionais nas
estimativas tradicionais.

Características de uma User Story - INVEST

Como você já deve ter notado, User Stories é uma técnica leve para que os clientes e
usuários efetivamente direcionem o desenvolvimento. Os clientes e usuários é que estão no
controle do projeto. A equipe simplesmente desenvolve as histórias que foram atribuídas à
iteração corrente. O uso de fichas pautadas é indicado para favorecer as mudanças e o diálogo.
Sobre essas mudanças, na minha experiência, vejo que os usuários "sentem menos dor" ao
rasgar uma ficha pautada do que apagar ou alterar uma especificação com dez páginas. Em
desenvolvimento de software, TUDO sempre muda. Especificações nunca podem ser tomadas
como válidas até que se provem verdadeiras por meio de software funcionando.

Mike Cohn escreveu uma das literaturas mais importantes sobre User Stories (vide
referências). Na sua obra, ele também citou Bill Wake sobre as características de uma Story.
Basicamente Stories devem ser: independentes, negociáveis, ter valor para os usuários (value),
estimadas, pequenas (small) e testáveis (nos termos em inglês, chegamos ao acrônimo INVEST).

Apesar de ser difícil em alguns casos, busque ter histórias independentes uma das outras.
Se existe muita dependência entre histórias inevitavelmente você terá problemas para planejar e
estimar o projeto. Isso está retratado exatamente nas figuras 1 e 2, sobre a história "Consultar,
Escrever e Apagar Recados".

Figura 3. Quebrando histórias, mas gerando dependências.

Veja a figura 3. Conforme citado, histórias são quebradas ou agrupadas constantemente,

de acordo com o que ocorre no planejamento e conforme a vontade dos usuários. Neste caso, a
história "Consultar, Escrever e Apagar Recados" foi quebrada em "Consultar e Escrever Recados"
e "Apagar Recados". Isso pode ter sido feito simplesmente porque o usuário achou que apagar
recados não tem tanto valor de negócio e pode ser desenvolvido nas últimas iterações. Porém,
este tipo de quebra incluiu uma dependência. A história "Apagar Recados" não pode ser
desenvolvida antes de "Consultar e Escrever Recados", já que para apagar também é necessário
consultar. Se você parar para pensar, o peso funcional três também só faz sentido se "Apagar
Recados" vier depois de "Consultar e Escrever Recados". Este caso é bem simples, porém, em
sistemas mais complexos, algumas dependências não são tão óbvias. Lute para deixar as
histórias as mais independentes possíveis uma das outras.

Outra dica é evitar histórias do tipo "Manter Recados". Vocês devem estar se
questionando porque na figura 3 coloquei "Consultar, Escrever e Apagar Recados". Para
histórias e casos de uso é indicado evitar usar "Manter", "Gerenciar" e outros afins. Prefira
escrever no cartão exatamente o que a história faz, sem dar margens para interpretações
ambíguas. Não tem problema algum o nome da história ou caso de uso ser grande!

Outra característica importante é que histórias são negociáveis. Vamos repetir mais uma
vez: histórias não são especificações formais. Uma história simplesmente é a descrição sucinta
de determinada funcionalidade. O cartão da história simplesmente é um lembrete dizendo que
você deve discutir esse assunto com o usuário em momento oportuno (quando a história for
implementada). Nós tomamos algumas decisões quando estimamos a história e discutimos mais
quando a história está para ser implementada. Nessas conversas podemos enriquecer a história
escrevendo no cartão algumas decisões tomadas, podemos criar novas histórias e até mudar
histórias existentes. Tudo é fruto de negociação e descobrir "onde está o ouro".

Figura 4. Uma história com anotações e pendências após a estimativa.

“Onde está o ouro” versus “Eu quero tudo”

Você que está lendo este artigo pode ficar frustrado imaginando que o contrato de
escopo negociável é o "calcanhar de Aquiles" para adotar o desenvolvimento iterativo de fato.
Realmente é muito difícil e arriscado firmar o esforço num contrato de escopo fechado
utilizando Stories da maneira que estou descrevendo aqui. É fato que a maior parte do mercado
brasileiro hoje usa contratos de escopo fechado, principalmente nos grandes projetos (governo,
bancos, telecom, indústrias etc.). O contrato de escopo fechado promete "previsibilidade" no
desenvolvimento de software, porém esta forma de contratação parte de duas premissas muito
duvidosas: 1 — o cliente sabe exatamente o que quer; 2 — a equipe sabe estimar exatamente o
esforço de construção.
 Se você já trabalhou em dois ou três projetos de software, sabe perfeitamente que essas
premissas são folclore. Nem o cliente sabe exatamente o que quer e nós sempre temos um grau
de confiança inaceitável nas nossas estimativas de longo prazo. Essa é a maior razão para o seu
gerente colocar 50%, 100% e até 150% de "gordura" ou "pulmão" no valor da proposta para o
cliente. E esse é o resultado: tentar forçar a "previsibilidade" num contrato de escopo fechado
gera projetos mais caros e clientes muito insatisfeitos. Na maioria das vezes isso acontece
porque o cliente se envolve timidamente no projeto, tomam suas especificações funcionais como
verdade absoluta e dizem: "Eu quero tudo!!!", não se importando se a solução vai resolver os
problemas ou não.

Na verdade, um projeto de software tem uma peculiar característica de "constante

investigação". Ken Schwaber chama isso de "inspeção e adaptação". Em termos mais práticos, o
dia-a-dia de uma equipe de desenvolvimento de software é "checar se estamos no caminho certo
e ajustar o rumo sempre que necessário". Desenvolvimento de software é um processo criativo
de pesquisa, então, especificações pactuais "gordas" que "apodrecem" no nosso controle de
versão nos ajudam pouco para o sucesso do projeto. Em projetos de software bem-sucedidos é
comum o produto final ser bem diferente da idéia concebida inicialmente. Durante o
desenvolvimento do projeto, uma sugestão de solução nos leva a novos problemas ocultos que
não podem ser ignorados e a outras possibilidades de solução ou "atalhos" que devemos
aproveitar. Dentro do desenvolvimento iterativo, esses problemas e atalhos se tornam muito
claros.

O cliente "querer tudo" sem dar margem para conversa não é saudável para nenhum
projeto. Ao invés disso, o cliente deveria participar ativamente do projeto para "querer o
melhor" e auxiliar a equipe de desenvolvimento a encontrar "onde está o ouro". Muitas
literaturas citam a regra de Pareto sobre um projeto de um software: 20% das funcionalidades
agregam 80% do valor do software, isto é, todo software possui um pequeno conjunto de
funcionalidades que resolverão praticamente todos os problemas dos usuários. Podemos
considerar que uma boa equipe de desenvolvimento de software é aquela que sabe descobrir
quais funcionalidades fazem parte desses 20% mais importantes! Para isso, nós utilizamos as
Stories com um sentimento de experimentação e fugimos de "especificações lavradas em
cartório" que temos que seguir. Stories devem ter um enfoque informal, devem ser discutidas,
devem ser fáceis de criar, priorizar, manusear e descartar (uma ficha pautada é perfeita para
isso!).

Acredito que muitas empresas ainda vão demorar bastante para mudar sua visão sobre
desenvolvimento de software. É impressionante a falta de sentido que existe na contratação de
grandes projetos de software com contratos de escopo fechado: o cliente acaba pagando ao
fornecedor por um software que não vai resolver de fato seus problemas de negócio e ainda por
cima arca com 50%, 100%, 150% de "gordura" embutida na proposta.

User Stories evoluem o software “organicamente”

Comentei várias vezes aqui a importância do próprio usuário escrever e ser responsável
pelas histórias. Numa equipe de desenvolvimento ágil, o usuário ou cliente está sentado no
banco do motorista e dirige o desenvolvimento utilizando Stories. Encare as histórias como
pedidos de criação ou alteração feitos pelos usuários. Eles podem pedir novas funcionalidades,
alterações e até remoções de funcionalidades já existentes dentro do processo iterativo. Com
isso, o software evolui do nada em direção à melhor solução em constante inspeção e adaptação.

O desenho da figura 5 nos mostra o cliente à esquerda passando as histórias para a

equipe que incorpora essas solicitações no software (logicamente para isso temos muita
conversa). Note como o software vai crescendo "organicamente" conforme as histórias são
implementadas sob ordem do cliente dentro do desenvolvimento iterativo. Ao fim de cada ciclo,
o usuário vê o resultado ($$$) da incorporação das suas histórias no software, direcionando a
criação das novas histórias para a próxima iteração.

Figura 5. O cliente direcionando e a equipe incorporando histórias no software.

Muitas equipes com as quais tenho contato têm dificuldade em compreender a criação de
software dessa maneira orgânica e crescendo de dentro para fora. Elas têm dificuldade em
compreender um design emergente. Algumas equipes acostumadas com processo de
desenvolvimento cascata realmente acreditam em muitas fases dentro do desenvolvimento que
são dependentes uma das outras. Como exemplo, algumas equipes acham que o banco de dados
deve ser modelado antes de pensar nas funcionalidades e processos. Outras equipes acreditam
que todos os requisitos devem ser levantados antecipadamente, ou que TODA a arquitetura deve
estar no lugar antes de começar a desenvolver. Porém, com a tecnologia e com as ferramentas
que temos nas mãos atualmente, não é necessário ter fases dependentes para produzir o
software. Isso é a base para o tão falado desenvolvimento iterativo. Com uma simples história na
mão e um mínimo de decisões arquiteturais é possível entregar software funcionando para o
usuário, nem que seja uma única tela. A partir deste ponto, novas histórias são incorporadas,
evoluindo as decisões, o design e a arquitetura da aplicação.
Stories acompanham testes de aceitação
O simples nome de uma User Story na maioria das vezes é muito pouco para se
direcionar uma implementação. Quando um usuário escreve no cartão uma história "Criar o
Perfil na Rede Social" os objetivos desta "Solicitação" devem estar claros. O que o cartão
representa deve estar claro!

Uma das dúvidas mais freqüentes para quem tem o primeiro contato com User Stories é
“Onde está a especificação? Onde estão os requisitos?”. Se citamos aqui que uma Story nada mais
é que uma solicitação de construção ou alteração do sistema, que outros subsídios temos para
implementar essa solicitação?

Algumas dessas dúvidas são respondidas por meio dos critérios de aceitação da Story.
Para deixar claro para os usuários e definir para o desenvolvimento o que uma história
representa, critérios de aceitação são essenciais. Critérios de aceitação são os parâmetros
definidos pelo usuário que dizem quando aquela Story está PRONTA. Isso é importante para os
desenvolvedores, pois fornecem critérios objetivos para saber quando uma Story está finalizada,
sem margem para relativismos.

Assim como a própria Story, os critérios de aceitação preferencialmente devem ser

escritos pelos usuários no verso do cartão.

Geralmente os critérios de aceite são capturados e aprofundados quando a Story vai ser
desenvolvida, porém isso não é regra. Também capturamos critérios de aceite ao estimar a
história, ao planejar a iteração e até ao criar o cartão. A qualquer momento podemos colocar
critérios no verso dos cartões para se lembrar de características que vão se transformar em
testes de aceitação.

Figura 6. Critérios de aceite no verso do cartão.

Veja a figura 6. Note que os critérios tornam claros os testes de aceitação que validam se
a Story está pronta. Ao mesmo tempo, os critérios declaram objetivamente o que "Criar o Perfil
na Rede Social" significa na "cabeça" dos usuários sem margens para dúvidas ou má
interpretação. Quando esta Story estiver pronta, a demonstração da funcionalidade para os
usuários sempre se baseará nos critérios de aceitação acordados. Mas e se os usuários ao verem
essa funcionalidade rodando nos questionarem sobre o"Álbum de Fotos"que deve existir no
perfil? Opa! Isso não está definido nos critérios de aceite e nem constou nas conversas sobre a
história. Seria uma nova história! Veja a figura 7.

Figura 7. Nova Story "Subir e Remover Fotos do Álbum" e seus critérios de aceite.

Na figura 7 criamos mais uma história evitando "manter/gerenciar...". Veja como fica
mais claro declarar que a história significa "Subir e Remover Fotos do Álbum". "Manter Álbum" é
um termo genérico demais que pode gerar muitas dúvidas com relação ao que o cartão significa.

Onde está a especificação do projeto?

Outra razão de utilizarmos fichas pautadas é que as histórias são simplesmente
descartadas depois que são incorporadas no sistema. No fim da iteração, todos os cartões
implementados e aceitos pelo usuário vão para o lixo. Como a história nada mais é que uma
alteração programada que muda o estado do sistema (ver artigo nas referências), depois que ela
cumpriu seu papel ela não tem mais propósito algum. Muitos outros artefatos leves também são
descartados depois que cumpriram seu propósito (vide meu artigo "Modelagem Ágil",
MundoJava 27).

Porém, nós precisamos ter a falada especificação para saber o que o sistema faz, certo?
Essa especificação formal auxiliará nas construções futuras, principalmente para correções e
evoluções. Sim! Nós precisamos ter um registro, uma especificação funcional, algo que valide se
o sistema está se comportando da maneira esperada.

A notícia estranha é que nós "agilistas" adoramos especificar! Nossa especificação é

muito formal. Nossa especificação é muito completa e abrange todas as áreas do sistema. Nossa
especificação é tão formal que até o próprio computador compreende. Nos dois últimos artigos
que escrevi, "Requisitos Executáveis com FIT" (MundoJava 31) e "O ciclo ágil de um dia"
(MundoJava 29), defendi o uso do Desenvolvimento Orientado a Testes (TDD) e o
Desenvolvimento Orientado a Comportamento (BDD) como forma de especificação.

"Agilistas" fogem de longos documentos de especificação e preferem conversar "face-a-

face" com o usuário para levantar requisitos. Porém, registramos essas decisões e esses
requisitos por meio de testes automatizados (sejam unitários, funcionais ou testes de aceitação).
Com isso, nossa especificação acaba sendo executável e muitas vezes dentro do próprio código,
correndo menos riscos de ficar defasada como geralmente ocorre com os longos documentos
apartados do código.

De qualquer forma, também é possível aplicar a técnica de User Stories mesmo quando
não se utiliza TDD ou BDD para ter especificações executáveis. Você usa as histórias para os
usuários guiarem o desenvolvimento, dentro do planejamento iterativo do projeto, e ao
desenvolver a Story você cria e/ou atualiza os artefatos e especificações que estão fora do código
(casos de uso, diagramas, testes etc.). Não é em todo sistema que é possível aplicar
especificações executáveis sobre testes automatizados, porém, devemos nos esforçar ao máximo
para melhorar nossa cobertura de testes automatizados e vigiar para que não tenha muitas
especificações defasadas ou inúteis no nosso repositório de projeto.

Conclusão
User Stories são pilares importantes para a adoção de métodos ágeis, principalmente
porque auxiliam o cliente a participar ativamente do projeto com uma prática que fornece poder
e liberdade. As maiores causas de falha dos projetos são: a falta de participação dos usuários e a
adoção de processos de desenvolvimento que distanciam eles. Processos iterativos mostram seu
maior valor com participação ativa dos usuários.

Referências
 COHN, MlKE (2004). Users Stories Applied for Agile Software Development.
 BECK, KENT (2004). Extreme Programming Explained.
 SCHWASER, KEN (2004). Agile Project Management with SCRUM.
 CALÇADO, PHILLIP (2008). User Stories are Just Schedulable Change: http://fragmen-
tal.com.br/2008/10/01/user-stories-are-just-schedulabie-change/
 IMPROVE IT. Sobre contrato de escopo negociável: http://www.improveit.com.br/xp/
praticas/contrato