Foco no Valor

Quando implantamos Scrum em uma empresa, podemos notar diversas mudanças no time logo nos primeiros Sprints: um nível maior de comprometimento, maior auto-estima, motivação. Entretanto, no decorrer das Sprints, devemos ter o cuidado de manter o foco do time no valor para o cliente.

Isso porque depois de anos e anos executando tarefas designadas por um gerente de projeto, é normal no calor de uma Sprint os membros do time passarem a trabalhar na forma "orientada a tarefas".

Mas isso realmente acaba se tornando um problema? No fundo não é desejável que o time execute todas as tarefas da Sprint Backlog? Sim, em termos.

Uma das prioridades em Scrum é entregar valor para o cliente, e isto só é possível através da realização de recursos de mais alto valor definidos por ele, com qualidade. Executar as tarefas pura e simplesmente, utilizando boas práticas de engenharia de software (testes unitários, design patterns, etc.) asseguram uma boa qualidade de código, mas não garantem qualidade no valor para o cliente.

Ao se desenvolver um item completamente, temos a garantia de que o fluxo do item está funcionando de acordo com as necessidades do cliente, o que se traduzirá como real valor para o cliente ao final da Sprint.

Então, como fazer com que o time enxergue a necessidade de se executar a Sprint de forma "orientada a itens ou features"? Obviamente uma das formas é explicando e mostrando a necessidade. Mas nem todo mundo entende a real necessidade desta forma.

Em uma recente implantação de Scrum em um cliente, me deparei com esta situação e resolvi propor um exercício para todos os "pigs": criarem User Stories juntamente com o Product Owner. E o exercício se revelou bastante interessante.

Utilizando algumas dicas postadas no artigo Focus on Value de Chris Sterling, pedi que todos os membros criassem uma declaração de valor para o produto, respondendo à seguinte pergunta:

"Quais valores ou benefícios este produto trará ao usuário?"

Em seguida, pedi que identificassem possíveis perfis de clientes para o produto e conforme os perfis iam surgindo, os discutíamos e se fossem válidos, os listávamos no quadro.

Finalmente, pedi que se separassem em grupos de acordo com a quantidade de perfis e cada grupo tratou de criar um User Story para o seu perfil, preenchendo as lacunas da seguinte frase:

"Eu, como <perfil>, gostaria de <recurso> para que eu possa <valor>!"

Quinze minutos depois, pedi que todos se reunissem novamente, e solicitei que cada grupo expusesse as User Stories criadas, uma por vez. Cada vez que o grupo expunha uma User Story, todos os outros membros discutiam sua validade e em caso positivo, passávamos a estória para uma lista que depois poderia ser utilizada pelo Product Owner gerar mais itens para o Product Backlog.

Embora alguns itens ainda não tenham sido aproveitados, o time pôde compreender um pouco melhor o conceito de "valor" para o cliente. E assim ficou mais fácil explicar a diferença entre o trabalho "orientado a tarefas" e "orientado a features". Ou User Stories.