Destrinchando as funções de P.O. — parte 2

Continuando a parte 1 desta série sobre tópicos avançados de Scrum, vamos nos aprofundar um pouco mais sobre as funções da pessoa P.O.

P.O.s são responsáveis por garantir que, durante o desenvolvimento do projeto, as necessidades da equipe sejam atendidas e também, deve garantir que a equipe esteja trabalhando nas histórias que entreguem mais valor para o cliente. Ou seja: O papel da P.O. é ajudar as partes interessadas a entender o porquê algumas histórias são necessárias. Seu foco é definir, negociar e influenciar.

É muito importante que a P.O. acompanhe os testes diários do que é produzido, evitando surpresas com reprovação e aprovação de histórias técnicas e não funcionais.

Definir a visão

Antes de começar um produto, é importante identificar a visão do produto e, para isso, precisará de ajuda das partes interessadas para realizar essa definição. Algumas equipes se reúnem e realizam uma sessão com product vision box, outras realizam reuniões onde a P.O. participa como pessoa mediadora. O objetivo dessas atividades é chegar a um consenso sobre a visão e ter bem definidos quais são os critérios de aceitação para o produto.

Definir um roteiro

Um roteiro de produto é um plano de ação relacionado a como um produto ou solução será desenvolvida ao longo do tempo. Proprietários de produto usam roteiros para delinear funcionalidades futuras do produto e quando novos recursos serão liberados.¹

É importante deixar claro para as partes interessadas que o roteiro é apenas uma estimativa, não um compromisso de prazo de entrega. Conforme a equipe trabalhar nas histórias e aprender mais sobre o produto, o roteiro será atualizado.

Término anormal de uma iteração

Aqui quero dividir em duas partes. A primeira é o caso da equipe concluir todas as atividades da sprint antes do tempo pré definido. Encontrei um artigo interessante com algumas sugestões do que fazer nestes casos.

Na segunda parte, o caso da equipe estar trabalhando em uma iteração e, por motivos inesperados, ela precisa ser descartada. É importante que a P.O. converse com a Scrum Master e a equipe antes de efetivamente descarta-la. A necessidade de descartar uma iteração não aponta falha do Scrum ou da empresa.

Referências:

¹ Trecho retirado de “Roteiros ágeis: construir, compartilhar, usar, evoluir”, do autor Dan Radigan.