Daily Scrum Blog

Bem, meus caros, se eu tivesse uma reposta pronta para essa e outras dúvidas no Scrum Guide, confesso que seria um indivíduo bem mais feliz, mas infelizmente, esse não é o caso.

O que vou tentar fazer é mostrar como nós estamos fazendo para tentar resolver esse “problema” nesse momento.

Portanto, para começarmos a entender o “problema” e chegarmos numa possível “solução”, vejamos um exemplo de uma “user story” (história de usuário) de um produto, no qual os clientes, através de uma página WAP, poderão contratar um serviço de assinatura de vídeos mobile. Vejamos:

Como um usuário,
Eu quero contratar , através do Portal WAP, o serviço de assinatura de vídeos da categoria que eu escolher,
Para que eu receba diariamente em meu celular os videos dessa categoria.

E abaixo, o critério de aceitação da história acima:

Dado que o usuário acessa a home do Portal WAP
Quando ele clicar no botão “assinar” ao lado do nome da categoria desejada
Então ele deve ser assinado no serviço
E ser tarifado em $0,99
E receber um SMS contendo o texto “Parabéns! Você assinou com sucesso o serviço! Em breve você receberá os vídeos da categoria escolhida.”

Pois bem … Agora vamos supor que, durante o Planning Meeting, a equipe tenha estimado essa história em 5 pontos, levando em consideração o escopo detalhado no critério de aceitação acima.

O desenvolvedor então finaliza a implementação da história e QA começa a fazer a validação. Durante essa validação, um cenário que até então não estava sendo contemplado vem à tona.

O cenário em questão é “usuário sem crédito tenta assinar o serviço”, por exemplo.

O Product Owner então é notificado sobre esse novo cenário e confirma que para clientes sem crédito o comportamento esperado é realmente outro, ou seja, o cliente não recebe SMS, e sim vê a mensagem de erro em uma outra tela.

E agora?

Bem, na minha opinião, esse cenário que surgiu deveria virar uma outra história e ser estimada pela equipe como uma história nova do Backlog.

Antes de explicar porque eu penso dessa forma, vejamos antes como seria essa nova história:

Como um usuário sem crédito,
Eu quero, ao tentar assinar uma categoria, receber um SMS me informando que não tenho créditos suficiente para contratar o serviço
Para que eu saiba o motivo pelo qual eu não consegui finalizar a operação com sucesso.

E o critério de aceitação:

Dado que o usuário acessa a home do Portal WAP
Quando ele clicar no botão “assinar” ao lado do nome da categoria desejada
Então ele deve ser redirecionado para a página de erro que exiba a mensagem: “Erro! Você não possui créditos para assinar esse serviço. Recarregue seu celular e tente novamente!”

A alteração pode ser pequena, pode ser “ridícula”, simples de fazer, mas criando uma história isolada, independente e com valor, o Product Owner consegue ter mais facilidade e flexibilidade em decidir o que fazer com ela sem afetar o escopo da história original.

Por exemplo, ele pode decidir negociar com a equipe para colocar essa história no lugar de outra de pontuação igual ou apromixada e que ainda não tenha começado a ser implementada nessa Sprint. Ou então ele pode chegar à conclusão de que não faz mal incluir essa história no próximo Sprint, já que estamos entregando valor mesmo sem o cenário de cliente sem crédito.

Conclusão

O importante é ter em mente que não é proibido pensar em cenários que não foram previstos durante o Planning Meeting. Lembre-se que não aceitar bem às mudanças não faz parte do “Manifesto Ágil”.

O que não pode acontecer é a qualidade ficar ameaçada e corrermos o risco de não finalizarmos uma história que a equipe se comprometeu em entregar ao final do Sprint porque novos cenários não param de surgir aumentando o seu escopo.

Considerações finais

E você? Como você faz quando surgem “problemas” como esse? Você tem uma forma melhor de lidar com histórias que aumentam em escopo? Concorda com essa abordagem?

Compartilhe sua experiência!

“Inspect and Adapt” sempre!

Antes de começarmos a ver como escrever boas histórias, vamos primeiro lembrar qual a definição de “User Stories”:

User Stories são descrições simples, escritas sob o ponto de vista do usuário, normalmente no formato “Como um (usuário), Eu quero (funcionalidade), Para que (necessidade)”, que demonstram o conceito de uma funcionalidade.

É extamente isso e mais nada! “User Stories” não são descrições extensas e detalhadas sobre uma funcionalidade. Elas definem apenas o conceito dessa funcionalidade.

Ou seja, de uma forma simples e bastante objetiva, você consegue identificar qual é a funcionalidade, qual é o usuário que irá usar essa funcionalidade e porque ela deve ser criada. Informações bastante úteis para ajudar o Product Owner a priorizar cada item do Product Backlog.

Mas escrever boas “User Stories”, fáceis de compreender, pequenas o bastante para estimar e testar não é uma tarefa fácil. E pelo que tenho visto por aqui, essa não é uma tarefa que seja possível ficar sob responsabilidade única e exclusiva do Product Owner.

Tá … O ideal talvez fosse se as histórias já viessem devidamente quebradas ao máximo para o Planning Meeting, mas para que isso fosse possível, seria necessário que o PO tivesse um conhecimento um pouco mais técnico. E isso é muito difícil …

É aí que entra uma das características mais legais do Scrum e de qualquer metodologia ágil: o trabalho colaborativo.

Por que histórias pequenas?

Histórias pequenas tendem a ter estimativas mais reais. Na minha opinião, se uma história tem uma estimativa de mais de 8 pontos é porque ela é grande demais e, provavelmente (nem sempre), o time não foi capaz de compreendê-la.

Histórias pequenas minimizam estimativas na base do chute …

Histórias como “Gerenciar usuário” e “Mecânica de nãoseioquê” são exemplos clássicos de histórias grandes.

À propósito, querido(a) Product Owner, antes que eu me esqueça, coloque em sua blacklist as palavras “Mecânica”, “Gerenciar” e outras do mesmo naipe. Gerenciar o que? É pra cadastrar? Atualizar? Remover? Pior ainda é a tal da mecânica … muito vago, não dizem nada … ou pior, dizem muito.

Histórias como essas necessitam de diversos cenários para serem especificadas, e isso não é nada bom. Histórias pequenas, por outro lado, são transparentes, dificilmente escondem outras funcionalidades.

Não seria perfeito se cada história tivesse um único cenário? Veremos que isso é possível e bastante saudável.

O que esperar do Product Owner?

Bem, espera-se que a PO conheça o produto do qual ele é responsável e crie um Product Backlog, devidamente priorizado, com todos os itens (funcionalidades) que o produto deveria ter.

Normalmente esses itens criados pelo Product Owner são histórias grandes ou “épicos”. Não espere mais do que isso.

Epics são “User Stories” grandes demais para serem estimadas devidamente. Elas costumam esconder diversas funcionalidades que seriam facilmente quebradas em outras histórias menores.

Mas até aí tudo bem. É normal que, no início, o Product Backlog tenha histórias grandes, mas é essencial que elas sejam quebradas em histórias menores antes de cada Sprint Planning Meeting.

Chega de teoria. Quero exemplos!

Ok. Vejamos abaixo o Backlog de um produto VAS fictício destinado a clientes da operadora ATL que desejam receber notícias por SMS:

Analisando a história 1 “Assinar serviço”, podemos ver que o usuário precisa passar por algumas etapas até ser assinado no serviço. Ele precisa solicitar a assinatura, o sistema precisa enviar um SMS pra ele responder e confirmar a solicitação, o sistema provavelmente vai precisar validar se a resposta é válida e enviar uma mensagem de erro caso seja. Enfim … olha o Epic querendo trollar a gente aí …

É aí que entra em ação aquele trabalho colaborativo que falei mais acima. É a hora, normalmente antes do Sprint Planning Meeting, quando a equipe (PO + Dev team) trabalha junta para quebrar ao máximo cada história de modo que elas fiquem mais fáceis de estimar.

Vejamos então esse mesmo Backlog com a história “Assinar serviço” quebrada em outras histórias menores:

Viram que a história “Assinar serviço” gerou quatro histórias? E todas pequenas, independentes e com valor de negocio! Além disso, cada história tem apenas um único cenário; aliás, o suficiente.

Uma dica muito importante para facilitar a decomposição das histórias é primeiro listar todos os cenários da história maior. Você verá que cada cenário vira um provável candidato à história.

Mas peraí! O que é essa coluna “Theme” no Backlog?

Temas nada mais são que agrupadores de histórias. Eles ajudam a organizar uma série de histórias que juntas formam uma única funcionalidade com extremo valor de negócio.

Ao quebrarmos histórias em várias menores, corremos o risco de perdermos o tal ”Big Picture”, ou seja, a visão do todo. Os temas nos ajudam a resolver esse problema.

Mas e quanto a história mãe, a que gerou as outras histórias? Já que não irei usá-la (por isso a quebramos), posso removê-la do Backlog?

Na minha opinião, acho melhor deixá-la exatamente aonde está, principalmente para fins de histórico. Agora, se ela está te incomodando, você pode criar uma coluna para categorizar os itens em “Epics” e “Stories” e criar um filtro para escondê-la.

Conclusão

Apesar de não ser uma tarefa fácil, vimos que é totalmente possível quebrar histórias maiores em pequenos pedaços.

Os ganhos são vários:

• Histórias pequenas são transparentes; não há detalhes implícitos. É muito fácil se perder nos detalhes de histórias grandes.
• Histórias grandes aumentam o risco da equipe não conseguir entregar nada no final do Sprint.
• Histórias pequenas têm poucos cenários, normalmente um único cenário que cabe perfeitamente no mesmo cartão da história, facilitando assim o acesso as informações por parte da equipe. Tudo num único cartão. Nada de extensas documentações.
• O processo de criação de histórias menores aumenta a comunicação e promove a colaboração da equipe.
• Histórias pequenas facilitam a redução de escopo, se necessário. O P.O pode dizer que nesse sprint não é necessário se preocupar com os tratamentos de erros, por exemplo. E essa mudança não interfere em nada mas outras histórias. Não é preciso remover cenários ou fazer qualquer tipo de alteração no escopo das outras histórias.

É isso aí, pessoal! Por hoje é só.

Como o tema “User Stories” é bastante extenso e rico, por isso a enorme quantidade de material na internet, voltarei a falar sobre o assunto muito em breve.