Scrum: E se o Dono do Produto tiver tarefas?

Acabei de começar a trabalhar com uma equipe que pegou alguns aspectos do Scrum (timebox de duas semanas), mas não outros (a equipe atualmente não concorda com todas as estimativas ou com o número de pontos em um sprint, mas vou mudar isso em breve.) O proprietário do produto também é um recurso técnico (cientista) com alguma experiência em desenvolvimento.

É apropriado ter as tarefas do proprietário do produto (que envolvem principalmente pesquisa) misturadas com as tarefas da equipe (algumas das quais são pesquisa e desenvolvimento).

Especialistas em Scrum são muito firmes em afirmar que o Product Owner e Scrum Master devem ser duas pessoas diferentes. No entanto, não existe essa regra excluindo da equipe de desenvolvimento. Nota no Guia Scrum :

Tamanho da equipe de desenvolvimento

O tamanho ideal da equipe de desenvolvimento é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo. Menos de três membros da equipe de desenvolvimento diminuem a interação e resultam em menores ganhos de produtividade. As equipes de desenvolvimento menores podem encontrar restrições de habilidades durante o Sprint, fazendo com que a equipe de desenvolvimento não consiga fornecer um incremento potencialmente liberável. Ter mais de nove membros requer muita coordenação. As grandes equipes de desenvolvimento geram muita complexidade para um processo empírico gerenciar. As funções Dono do produto e Scrum Master não estão incluídas nesta contagem, a menos que elas também estejam executando o trabalho do Sprint Backlog.

O corolário dessa última linha seria que, se o Dono do Produto estiver executando o trabalho do Sprint Backlog, ele será contabilizado como membro da Equipe de Desenvolvimento.

Dito isto, faça o que for necessário para que o seu trabalho seja bem executado.

O Dono do Produto é responsável por maximizar o valor do produto e o retorno do investimento. Pode parecer simples, mas geralmente é um papel em tempo integral e muito exigente - provavelmente o mais difícil do Scrum. Envolve muito trabalho estratégico de alto nível, bem como tarefas de nível inferior, desde a análise de oportunidades de mercado e consultoria às partes interessadas e usuários do produto para tomar as decisões corretas, até manter o roteiro e o backlog do produto sempre polidos, participando do planejamento e revisar as atividades, colocando-se à disposição da equipe para responder suas perguntas etc.

Se o PO estiver encarregado de outras tarefas além disso, eu as veria como marginais na maioria dos casos. Portanto, minha resposta seria sim, crie tarefas para o PO, se você realmente precisar e se elas contribuírem diretamente para produzir o incremento de software do sprint, mas não vejo isso acontecendo frequentemente no seu projeto Scrum comum.

O Scrum é, acima de tudo, sobre comunicação e trabalho relevante e oportuno. Tudo para atingir esse objetivo é bom, se é isso que permite à sua equipe ser mais produtiva.

É difícil fazer bem, no entanto. Estou nessa posição agora e acho difícil dedicar uma quantidade adequada de tempo como proprietário do produto, enquanto ainda resta tempo para o desenvolvimento. No entanto, o arranjo funciona bem para essa equipe específica neste momento. Revisitaremos a decisão de fazer o duplo dever quando nosso desempenho diminuir, mas até lá continuaremos trabalhando dessa maneira.

Então tente. Faça retrospectivas para melhorar continuamente seu processo. Não deixe que a aderência anterior a alguma metodologia atrapalhe a produtividade de sua equipe.