5 Razões para alterar a ordem dos itens

Um Product Owner entrega ao seu time 10 Story Cards (cartões com uma User Story cada). Os membros do time leem e devolvem ao Product Owner o quinto e o sexto cartão. No final do Sprint, o time entrega a funcionalidade dos cartões 1, 2, 3, 4 e 7. No entanto, as tarefas dos cartões 5 e 6 ainda não foram iniciadas.

Na minha opinião, isso está ok.

Uma recomendação padrão em métodos ágeis é que o time deve trabalhar nos itens do Backlog na ordem que o Product Owner define. Embora isso faça sentido até certo ponto, bons times ágeis frequentemente abrem exceções a essa regra.

Existem muitos bons motivos para um time não seguir a ordem estabelecida. Aqui listei alguns que devem servir como justificativa suficiente:

1) Efeitos de sinergia

Muitas vezes existem efeitos de sinergia entre os itens no topo do Product Backlog. Enquanto uma equipe trabalha no item nº 3, por exemplo, ela também deveria poder trabalhar no item nº 6. Se dois itens estão na mesma parte do sistema e podem ser concluídos mais rapidamente juntos, o Product Owner também deveria permitir isso.

2) Dependências

Uma equipe pode decidir que o item 4 é mais importante que os itens 5 e 6. Infelizmente, só é possível trabalhar no nº 4 depois que o nº 7 estiver concluído. Uma dependência assim normalmente é suficiente para permitir que uma equipe se desvie da ordem prevista.

3) Disponibilidade de conhecimento especializado

Uma equipe gostaria de trabalhar no quarto item mais importante do Product Owner, mas a pessoa certa para isso infelizmente não está disponível. Claro que isso pode ser um sinal de que mais membros da equipe deveriam ser capazes de trabalhar de forma multifuncional – mas essa é mais uma solução de longo prazo. Uma solução de curto prazo seria simplesmente trabalhar em outros itens até que o membro da equipe com as habilidades necessárias esteja disponível novamente.

4) É mais interessante

Ok, esse ponto é discutível. Não estou dizendo que a equipe deveria trabalhar nos itens nº 1, 2, 3, 4 e depois no nº 600. Mas selecionar os itens como no meu exemplo (1, 2, 3, 4, 7) está ok se isso torna o trabalho um pouco mais empolgante.

Em alguns projetos, as equipes ocasionalmente encontram uma série de Product Backlog Items que não são realmente muito divertidos. Se uma equipe puder de vez em quando antecipar um item que oferece alguma variedade, isso pode ter um efeito positivo na moral dos membros da equipe. E isso, por sua vez, é bom para o Product Owner.

Bônus: 4.1.) É mais interessante para os stakeholders

Já que estamos no assunto: afirmo simplesmente que também está ok para uma equipe alterar a ordem se determinados itens são interessantes para os Stakeholder.

Às vezes pode ser um grande desafio fazer com que todas as pessoas importantes participem dos Sprint Reviews. Fica especialmente difícil quando os últimos Reviews foram bastante entediantes. A razão pode ser a alta prioridade de certos trabalhos (por exemplo, coisas importantes que não são realmente visíveis para os stakeholders).

Num caso assim, pode ser inteligente dar um pouco de sex appeal ao próximo Sprint Review. Porque se a equipe trabalha em algo que os stakeholders acham interessante, eles também terão mais probabilidade de participar da reunião.

5) Tamanho

Caso os motivos anteriores ainda não tenham te convencido, guardei o motivo mais convincente para o final. Ele prova que toda equipe também pode se desviar da ordem definida pelo Product Owner: uma equipe pode, por exemplo, pular o item nº 5 se ele for grande demais. Então a equipe pega o próximo item que cabe no Sprint em termos de tamanho.

Se isso não fosse permitido, a equipe selecionaria apenas os itens 1, 2, 3 e 4 e depois pararia. Então possivelmente uma parte considerável do Sprint ficaria vazia. Claro que a equipe poderia pelo menos concluir parte do item 5 e depois começar outro. Mas isso não faz muito sentido em muitos casos. Por isso, a equipe vai pelo menos de vez em quando se desviar da ordem original.

Product Owners não são perfeitos

Um Product Owner perfeito saberia tudo isso. Um Product Owner perfeito saberia que os primeiros quatro itens no backlog já significam tanto trabalho relacionado a banco de dados que ele não colocaria mais um item desse tipo na posição 5. Um Product Owner perfeito saberia que os itens 2 e 5 se referem à mesma classe Java e os agruparia na priorização.

Mas para a maioria dos Product Owners é difícil ser perfeito. A melhor solução é simplesmente priorizar o Product Backlog da melhor forma possível e depois deixar o ajuste fino para a equipe.

Este texto vem do blog de Mike Cohn e foi traduzido por nós para o português.

agile100: Roger Martin

=> Em fevereiro de 2021, conversamos com Roger L. Martin sobre o seu livro "When more is not Better".

Trabalho Ágil na MAN

=> Quão ágil é a MAN Truck & Bus SE e como funciona o trabalho ágil na indústria automobilística?