Priorização e objetivos de médio prazo
Em outro artigo do blog, já escrevi sobre como podemos fazer uma priorização na nossa vida pessoal através de "Agora" e "Depois". Compras planejadas não são divididas em categorias como: O que precisamos comprar? O que deveríamos comprar? O que poderíamos comprar e o que não vamos comprar de jeito nenhum? A seguir, vou explicar como implementar o planejamento com "Agora" e "Depois" de forma simples e como trabalhar ao mesmo tempo em direção a uma visão maior para o produto.
Uma visão para o produto de médio prazo (cerca de três meses) tem se mostrado bastante útil. No início de um novo trimestre, o Product Owner deve estabelecer um objetivo e dizer: "Quero ter alcançado este ponto em três meses." Essa definição de objetivo é feita junto com o time e os stakeholders. A visão final de um produto, por outro lado, é responsabilidade exclusiva do Product Owner.
O Product Owner não precisa se apegar demais a essa visão – ela também pode ser alterada. Mas sem uma meta temporal definida, temas urgentes que surgem pouco antes das Sprint Planning Meetings acabariam influenciando rapidamente a priorização. Sem uma visão clara, temas urgentes sempre receberiam mais atenção do que temas estrategicamente importantes.
Quais fatores devo considerar?
Quando preciso decidir entre diferentes ideias para uma visão de médio prazo, gosto de seguir um processo formal, para poder explicar e justificar minha decisão. Devemos ser capazes de dizer: "Decidi focar nisto em vez de naquilo" e então apresentar os fatos que levaram a essa decisão.
No entanto, o Product Owner precisa primeiro classificar as User Stories no início de cada Sprint em "Agora" ou "Depois" . Isso ajuda a decidir em quais itens trabalhar no próximo Sprint. Em vez da abordagem formal e bem explicável, o Product Owner deve considerar os seguintes quatro pontos para cada item do Product Backlog:
O quão valioso será a funcionalidade
O efeito de aprendizagem que ocorrerá com esta funcionalidade
O risco desta funcionalidade
O custo da funcionalidade
Os itens são primeiro ordenados com base no ponto 1, ou seja, pelo seu valor. Até aqui, é um método muito tradicional de priorização. No entanto, este backlog reordenado é depois organizado com base nos pontos 2 – 4. Dependendo da influência que estes fatores exercem, move-se as funcionalidades individuais para cima. Mas primeiro vou explicar do que se tratam estes fatores:
O segundo fator diz respeito ao quão grande é o efeito de aprendizagem no desenvolvimento de uma determinada funcionalidade. Isso pode significar, por exemplo, que se aprende algo sobre a tecnologia utilizada (algo não é tão simples como se assumiu) ou descobre-se como os utilizadores reagem a uma nova interface. Assim, se através de um determinado item do backlog se pode aprender algo importante, move-se para cima no Product Backlog, para que possa ser desenvolvido no próximo Sprint.
Em relação ao risco, prefiro desenvolver funcionalidades mais arriscadas mais cedo do que mais tarde. Assim, pode-se descobrir quais são os impactos desse risco. Portanto, esses itens também são colocados no próximo Sprint. No entanto, se houver a possibilidade de evitar completamente um risco (por exemplo, eliminando completamente a funcionalidade), o item não é incluído no próximo Sprint. No melhor dos casos, pode-se proceder assim também nos Sprints seguintes e assim evitar completamente o risco.
O último fator refere-se aos custos. Algumas funcionalidades tendem a ser mais baratas quando são realizadas o mais rapidamente possível. Tornam-se cada vez mais caras quanto mais se adiam. Colocar esses itens no próximo Sprint pode manter os custos baixos.
Utilize estes quatro fatores para a seleção dos itens para os próximos Sprints e crie uma visão de médio prazo (três meses). Assim, conseguirá fazer uma boa priorização de "agora" e "depois" para alcançar o objetivo geral.
