No Scrum nosso de cada dia, existe um papel que eu considero o mais difícil de todos: o Product Owner (daqui pra frente, P.O). No Scrum, o P.O. representa o interesse do cliente e é o responsável por definir a visão do projeto, traçar uma estratégia para atingir essa visão incluindo histórias no backlog e definir o que será desenvolvido e entregue nos Sprints pelo time. Ou seja, ele é o responsável direto pelo ROI (Retorno do Investimento).
O meu post hoje foca na visão do projeto e as dificuldades em criá-la, principalmente para um produto já existente, que é o caso da empresa onde trabalho, que há algum tempo resolveu adotar o Scrum.
A visão do projeto é basicamente o que o nome diz: é o motivo para ele existir, sua filosofia e seus conceitos de negócio. No cenário de projetos, existe uma característica que os difere de produtos: projetos tem início, meio e fim. Já para produtos, que é o nosso caso, o P.O. deve não apenas criar uma visão, como também uma expectativa a longo prazo para o produto, e definir limites. Até onde é responsabilidade do produto e até onde queremos chegar.
Essa visão deve ser adaptativa, pois o mundo muda muito rápido, e agilidade em mudar de rumo é vantagem competitiva hoje. Nisso, o Scrum ganha de longe de outras metodologias: você tem entregas em sprints curtos e a próxima entrega ainda será definida, o que dá muita margem para mudanças.
E como fazer quando você quer migrar pro Scrum e você não tinha apenas um stakeholder, de um produto que já existe há pelo menos cinco anos, mas sim vários ?
A primeira coisa a se fazer, acredito, seria pegar todos os requisitos pendentes, ou seja, os já existentes do sistema e organizá-los em histórias, do tipo: “Eu como usuário gostaria de assistir vídeos no linux (em flash)”, ou “Eu como Product Owner gostaria de disponibilizar o player para que outros sites possam incluí-lo (embedded)”. Com todas essas histórias que o produto tinha pela frente postas no papel você consegue ter uma visão geral da direção que o produto estava seguindo.
Descobrindo essa direção você pode: ou se ater à direção atual ou definir uma nova e criar novas histórias para que o produto começe a mudar de direção. O importante é ter essa direção, que não é fácil, diga-se de passagem. Com a direção definida você provavelmente terá agora mais facilidade em estimar o valor de negócio de cada história (valor esse de 0 a 100). O valor de negócio é uma métrica de quanto uma história traria de valor para a empresa em comparação com outra.
Para iniciar essa definição, pegue a história que tenha o menor valor de negócio e estime um número baixo para usar de referência, como 2 por exemplo. Daí, vá pegando as outras histórias e comparativamente dando seus valores de negócio. Rapidamente você terá um quadro bem definido com quais histórias provavelmente você irá atacar nos próximos sprints e conseguirá antever pelo menos 2 ou 3 entregas.
Nisso, é hora de comunicar ao time a estratégia do produto e as histórias que você pretende atacar no futuro próximo. No Sprint Planning 1, que é a primeira de duas reuniões que definem um sprint, o time irá estimar a complexidade que cada história tem e encaixar no Sprint (que no nosso caso leva 2 semanas) aquilo que o time consegue se comprometer em entregar. São também definidos nessa reunião, pelo P.O., o DoD (Definition of Done, ou em português: Definição de Terminado) e os critérios de aceitação.
Com isso tudo feito, é só correr para o abraço. Com o time a par da visão e o sprint definido e bem detalhado, o P.O. poderá ter a certeza que caso ele precise mudar de estratégia, será tão simples como colocar mais itens no backlog do produto, estimar o valor de negócio, re-estimar ou mesmo remover histórias do backlog (não os do sprint atual, claro).
Uma experiência legal que tivemos aqui foi que a nossa P.O. marcou uma reunião para nos passar a visão do projeto, ouvir idéias e ter um feedback do que o time gostaria de sugerir para a plataforma que trabalhamos. O formato da reunião foi o seguinte: Reunimos os dois times que participam do projeto dessa plataforma e de outra plataforma relacionada, misturamos todos e dividimos em dois grupos. Cada grupo teve meia hora para fazer um brainstorm de idéias, colocá-las no papel, sem que ninguém pudesse criticar a idéia do outro, apenas contribuir com as suas. Depois disso (por incrível que pareça, eram 4 folhas A4 de idéias para cada grupo), nós deveríamos discutir as idéias por mais meia hora, eliminando as idéias que fossem claramente ruins. Após essa primeira eliminação e discussão, cada grupo teve 10 minutos para escolher as top 10 idéias.
Foi impressionante como as idéias se mesclavam no final. Das duas listas top 10, conseguimos 12 ou 13 idéias muito boas, e as outras 7 que sobraram eram repetidas. O timebox da reunião foi de 2:30 horas. Em 2 horas e meia conseguimos ver qual a visão a médio e longo prazo da plataforma, ter uma noção muito maior do que é a nossa plataforma para a empresa como um todo e sugerir idéias para melhorar, mudar e acrescentar valor ao projeto.
Off-topic: Como as reuniões estão mais produtivas, depois que adotamos o Scrum… mas isso é assunto pra outro post. Voltando ao tópico e para concluir, esse é o maior desafio, na minha opinião, em uma migração para Scrum: Definir a visão dos projetos.
) ? Comente !