Ei PO, o seu Product Backlog está DEEP?

Olá Pessoas,

Antes de mais nada eu gostaria de agradecer o WordPress, por ceder este espaço para que a gente possa discutir, em alto nível, a gestão de projetos e produtos no Brasil… (protocolos e blá blá blás cumpridos, vamos ao que interessa)

Se eu pudesse fazer uma correlação dos papéis do Scrum com profissões conhecidas no mercado de trabalho; o Scrum Master seria um rabugento Técnico de Futebol (o pragmatismo de Telê Santana e o garbo e elegância de Pep Guardiola), o Time de Desenvolvimento seria uma mescla de habilidosos Engenheiros, Arquitetos, Mestre de Obras e Pedreiros… e o Product Owner seria um criativo e cuidadoso Jardineiro. – Ei “seu PO”, como este post é destinado especialmente à você, não fique bravo comigo caso não goste, digamos, da sua nova profissão; acredito que ela seja bastante interessante, muito embora eu não tenha a menor vocação para exercê-la.

Mas porque eu acho que os nossos valorosos POs poderiam ser criativos e cuidadosos jardineiros? (os demais papéis e suas correlações, acho que estão subentendidos) 😀

Porque todo PO deveria cuidar do seu Product Backlog, da mesma maneira que um jardineiro cuida do seu jardim… onde, sem os seus devidos cuidados e atenção, certamente estará, o seu o backlog (jardim), fadado à um destino fatal. 😦

E, assim como um Jardineiro precisa de algumas ferramentas como regador, tesoura de poda, luvas e etc… um Product Owner precisa — para que o seu jardim, ou melhor… o seu Product Backlog receba os devidos cuidados — ter em mente, por exemplo, o significado do acrônimo DEEP, e responder sim a todas (ou quase todas) as perguntas a seguir:

D de DETALHADO o suficiente…

• As histórias de usuário que entrarão na próxima sprint estão granulares?
• Todos do Time de Desenvolvimento entendem o que deve ser feito para que as histórias de usuário sejam concluídas?
• As dúvidas de negócio das histórias foram esclarecidas?
• Os testes de aceitação estão definidos e escritos?

E de ESTIMADO…

Nota: se você não usa estimativas em seu projeto, desconsidere esta parte.

• As histórias de usuário do alto do Product Backlog estão estimadas, auxiliando o time a decidir se elas cabem dentro da sprint?
• As estimativas estão coerentes, ou seja, estão utilizando a unidade de medida que o time definiu? (story point, t-shirt sizing, anos-luz, jokenpô, baralho de tarot, uno e etc) 😀

E de EMERGENTE…

• O Product Backlog está atualizado, levando-se em consideração as informações que são conhecidas?
• Histórias de Usuário que trazem valor para o negócio estão escritas e adicionadas no Product Backlog?
• Histórias de Usuário que não fazem mais sentido, foram removidas do Product Backlog?

P de PRIORIZADO…

• As histórias de usuário mais importantes (que geram maior valor) estão no alto do Product Backlog?
• As histórias de usuário que não geram valor no momento, estão com baixa prioridade?
• Os épicos estão na parte de baixo do Product Backlog, sem muito detalhamento?

Enfim se você é um PO e respondeu sim para a maioria das perguntas acima, parabéns… tenha certeza que além da maximização do ROI, o produto que o seu projeto está criando, passará por ótimas e floridas primaveras.

Saudações. Ψ