Aceitação oficial de trabalhos na Sprint Review – Sim ou Não?
Algumas equipes usam a Sprint Review como uma oportunidade para que o Product Owner ou os principais stakeholders aprovem os itens do Product Backlog concluídos naquele Sprint.
Em princípio, uma Sprint Review não deve ser usada pela equipe para obter aprovação do trabalho pelo Product Owner. A equipe e o Product Owner devem colaborar tão estreitamente durante o Sprint que a equipe já saiba o que o Product Owner pensa sobre seu trabalho.
„Sem surpresas" é a minha 1ª regra para a Sprint Review
É completamente aceitável que um Product Owner não aceite o trabalho da equipe para um determinado Product Backlog Item. No entanto, a equipe já deveria saber disso com antecedência.
Os membros da equipe não deveriam entrar em uma Sprint Review esperando grande reconhecimento pelo seu trabalho, apenas para receber reclamações completamente inesperadas.
Pode o Sprint Review ser usado oficialmente para a aceitação formal?
Quando um cliente contrata um fornecedor para desenvolver um produto para ele, idealmente alguém na empresa do cliente atua como Product Owner. Nesse caso, pode ser apropriado que as funcionalidades sejam aprovadas no Sprint Review. Mesmo assim, mantenho minha posição de que não deveria haver surpresas no Sprint Review.
Mesmo que o Product Owner do cliente dê feedback à equipe durante o Sprint, é possível que ele precise esperar com uma aprovação oficial até que os outros stakeholders tenham tido a chance de se manifestar sobre o trabalho.
Um exemplo simples
Um exemplo simples: minha filha me perguntou recentemente se poderia participar de uma excursão escolar. Eu disse que não tinha problema com isso, mas – adivinhe só – precisávamos primeiro perguntar à mãe dela. O motivo era que minha esposa poderia ter feito outros planos para a família naquela data, dos quais eu ainda não sabia.
E a aceitação em um projeto real?
Esta é uma situação cotidiana para Product Owners em projetos de desenvolvimento. Mesmo que o Product Owner, que interage diariamente com o time, goste de como uma feature foi construída, ele pode precisar se certificar de que os stakeholders que representa também concordam. Claro, poderia-se argumentar que o Product Owner poderia simplesmente ir até eles e perguntar. Mas isso pode ser muito impraticável e, por isso, é melhor resolver isso na Sprint Review.
Em projetos de desenvolvimento desse tipo, no entanto, o cliente nem sempre disponibiliza um Product Owner. Frequentemente, o cliente paga para que o parceiro contratado cuide de tudo.
O cliente, naturalmente, continua sendo o verdadeiro Product Owner. No final das contas, é ele quem vai aceitar ou rejeitar o trabalho de desenvolvimento. Porém, ele não quer ser "incomodado" com essas coisas no dia a dia. A solução típica é o fornecedor designar um Product Owner da sua própria empresa.
E nesse caso, nenhum item do Product Backlog pode ser aceito ou aprovado antes da Sprint Review. O verdadeiro Product Owner (da empresa do cliente) não está disponível e envolvido o suficiente para poder aprovar algo com mais frequência.
Certamente, o time pode obter uma aprovação preliminar do seu próprio Product Owner durante a Sprint. Porém, o verdadeiro Product Owner da empresa do cliente pode, em última instância, tomar uma decisão completamente diferente na Sprint Review.
A resposta definitiva depende, como sempre, do contexto de cada situação. Por isso, devo dizer que não me preocupo muito quando a aprovação oficial dos trabalhos acontece na Sprint Review. Ainda assim, mantenho minha posição de que não deveria haver surpresas na Sprint Review. Faça o que funciona melhor para você. O importante é que os membros do time já saibam antes da Review o que os espera.
Este texto é do blog de Mike Cohn e foi traduzido por nós para o alemão.
Sprint Planning orientado por Velocidade
=> Vantagens e desvantagens do Sprint Planning orientado por velocidade
Quando a ordem dos itens deve ser alterada?
=> Aqui estão 5 boas razões pelas quais você deveria ajustar de vez em quando a ordem dos itens no Sprint.
