User Stories: Não Crie Godzillas!
Hoje de manhã eu acabei iniciando um debate interessante com o Antônio Carlos via twitter. Tudo começou quando o Fernando Meyer postou uma foto dos cartões que ele usa para planning poker. O meu primeiro comentário foi sobre as cartas com valores exorbitantes como 40 e 100.
Qual o problema destes valores?
Eles são um sintoma de um problema. São um bad smell. Dado que toda história tem algum valor para o usuário do sistema, como alguém pode ter no mesmo sistema, na mesma iteração, duas histórias que valem 2 e 100? Existem tarefas que realmente envolvem tão pouco esforço que o numero é baixo. Mudar um texto para itálico, por exemplo, mas se isso é um dois o que seria tão grande a ponto de ser (40/2 =) 20 vezes mais trabalhoso e ainda assim ser considerado uma história?
Possibilidades:
- Histórias mal formuladas: O analista de negocio cria histórias que não possuem valor nenhum e/ou histórias que não são atômicas.
- Incerteza: Os desenvolvedores fazendo a estimativa de tamanho da história não tem idéia de como fazer aquilo e chutam o tamanho para o alto, o mais alto que conseguirem.
O primeiro problema é muito comum –tem um post nos rascunhos sobre minhas experiências recentes com este. Analistas –especialmente os com experiência em desenvolvimento- tendem a pensar em tarefas que são decomposições funcionais e não partições verticais dos sistemas. Invés de pensas no ponta-a-ponta da tarefa eles criam histórias apenas sobre um pedacinho específico. No outro lado da moeda o analista não consegue particionar o sistema em histórias. No final os cartões trazem histórias gigantescas.
É fácil estimar histórias pequenas. Na verdade o princípio que move as estimativas de métodos ágeis é que é muito mais fácil estimar alo pequeno do que algo grande. O problema é que estimar o tamanho uma história grande é muito difícil.
A solução neste caso provavelmente passa por ter histórias melhor definidas. É claro que vão existir histórias que são tão simples que até um 2 é muito para elas, nesse caso use algo menor como um numero abaixo da sua menor história “normal” (quase sempre isso quer dizer 1).
A segunda causa é bem simples de resolver, creio. A incerteza é algo comum, especialmente antes de executar algumas histórias para saber onde se pisa. Neste caso ao invés de se chutar a estimativa para a Lua com um 100 você pode começar usando uma carta que deixa claro que não se consegue estimar este cartão com as informações atuais:
E prosseguir criando um spike com objetivo de obt6er mais dados sobre aquela tarefa. Estimar um spike é bem mais simples do que uma história.
Mas e para estimarmos em alto-nível estas histórias enormes, confusas e distantes? Algo assim não é história, é um épico. Neste caso estimativas de alto nível são aceitáveis enquanto o épico estiver no backlog mas antes de serem agendados os épicos são desmembrados em histórias.
July 10th, 2008 at 3:13 pm
Totalmente de acordo. E é exatamente assim que estimamos aqui. Na verdade, o alarme sempre dispara quando uma estória é maior do que “13″ pontos. No começo chegamos a tentar algumas histórias com 40, mas não funcionou bem: prejudicou a comunicação em torno da estória, o time não soube como dividir o trabalho entre os membros e o histórico de capacidade do time foi para o buraco.
Em outro time, mais inexperiente, a incerteza fez com que a maior parte das tarefas ficasse acima de 20 pontos. Ruim e nem Scrum Master nem PO agiram para corrigir isso. No mais, Phillip, acho que cada time pode interpretar o tamanho de um ponto de maneira diferente. Se um time achar razoável estimar estórias tão grandes, ok.
July 10th, 2008 at 3:14 pm
Aliás, não dá para ver as fotos dos cartões porque o twitter do Fernando Meyer são protegidos.
July 10th, 2008 at 5:57 pm
Oi, Marcos,
Os números são relativos mas o bad smell está na distribuição. Dizer que algo é vinte vezes maior que outra coisa é bem diferente do que dizer que algo é quatro vezes maior. Quanto você chega a este nível de incerteza é melhor parar de estimar o tamanho e buscar mais informação sobre a história.
Se algum time usa 100 como a menor unidade e vai até, não sei, 2000 é posível entender. Quando alguém começa com 2 e vai até 100 tem algo errado. É 20x versus 50x -mais que o dobro de incerteza.
[]s
July 10th, 2008 at 5:58 pm
Ah, e a foto é praticamente do mesmo deck que eu usei abaixo, a foto abaixo é do Cainã
July 11th, 2008 at 11:51 am
Pois é, quando começamos a trabalhar o novo time de publicação, e, simultaneamente, o primeiro trabalho usando scrum para a maioria, usei um conceito que tirei do livro do MikeCohn, “uma história maior que 13 é algo que precisa ser melhor explicado”. De lá pra cá, tivemos realmente muito poucas histórias que entraram no sprint acima disso. Um único caso, foi uma história de 20 que por coincidência ou não, não foi entregue. É bem verdade que lembrando do backlog não lembro de nenhuma história com mais de 40.
Sinceramente, acredito que acima de 20, usar 40, 100 ou ? serve apenas pra comparar - é essa história aqui é complicada, mas essa outra é bem mais.
O que você comentou dos spikes realmente funciona. Se uma história de 20 não pode ser decomposta ou entendida, é necessário um spike para entendê-la melhor, colocar uma história de 20 no sprint é ter certeza que não se sabe o que deve ser feito.
p.s.: falo isso baseado na escala que usamos na gcom, como você disse, que começa em 10, 100 etc tem que usar outras medidas.