O Agile Planning Board surge com o objetivo de auxiliar times de projetos na execução de planejamentos e estimativas com transparência e boa comunicação entre todos os envolvidos.
Criado para auxiliar times iniciantes, com o passar do tempo se mostrou uma boa ferramenta de facilitação, definição de métricas e propósitos além da resolução de conflitos através do uso da gestão visual e o alinhamento de restrições.
Uso do Agile Planning Board
Para aqueles que têm apenas um martelo como ferramenta, todos os problemas parecem pregos.
Mark Twain
Em alguns passos, a ideia é demonstrar como o agile planning board pode ser utilizado.
Caso você ainda não conheça o Agile Planning Board, faça o download aqui.
1. Identificação e Propósito
Aqui identificamos qual o projeto (ou nome do time) e também o objetivo que queremos alcançar, dando um propósito claro a todos os envolvidos no planejamento.
2. Participantes
Nesta área vamos identificar dois papéis:
O Product Owner será o responsável por tirar as dúvidas de negócio, criar todas as hipóteses (itens do backlog), priorização e definição das metas a serem atingidas.
O Time é formado pelos indivíduos que estarão diretamente envolvidos com a construção e que participarão do planejamento de esforço.
2.1 O papel do Facilitador
É comum termos a presença de um facilitador para auxiliar na condução da dinâmica e na discussão entre todos os envolvidos. Se você atua com Scrum, o Scrum Master é a pessoa indicada para assumir este papel.
Entretanto, com o passar do tempo temos notado que equipes experientes conseguem utilizar o agile planning board sem a necessidade de um facilitador.
3. Backlog Priorizado
Nesta área serão dispostos os itens priorizados para se atingir o objetivo (determinado no primeiro passo).
Aqui não importa se você utiliza user stories, user cases, features, etc. Comece com o que você tem hoje.
O Agile Planning Board irá auxiliar na discussão se o nível de granularidade está suficiente para o entendimento do time de desenvolvimento.
A quantidade de itens nesta área pode variar bastante, pois o board pode ser utilizado para planejar sprints, releases ou todo o projeto.
Uma sugestão é utilizar um board por release, mas esta decisão depende do contexto de cada projeto.
4. Alinhando as Restrições
Agora que sabemos qual o nosso propósito e quais funcionalidades serão necessárias para atendê-lo, vamos alinhar as restrições entre todos os envolvidos no planejamento.
Fazemos isto através da Definição de Pronto (DoD – Definition of Done).
Aqui deixamos claro para todos o que é esperado para que se considere um item pronto, através de uma política explícita.
Por exemplo: Todos os itens devem ter o seu manual de usuário, testes automatizados e entregues em ambientes de produção.
Desta forma, o time deverá considerar todos estes parâmetros na construção de cada item e o Product Owner terá visibilidade de que estas foram as premissas que deverão ser validadas na sua entrega.
Conseguimos então, alinhar as expectativas e evitar futuros conflitos.
5. Classificando os itens (jogo do planejamento)
Para cada item priorizado do backlog, pergunte ao seu time como classificá-lo dentro do fluxo do conhecimento.
Se o seu time tiver dúvidas de negócio, sobre o que deve ser feito, pergunte se esta dúvida é (G) Grande, (M) Média ou (P) Pequena.
Caso não as tenha, verifique se há dúvidas técnicas, sobre o como deve ser feito, pergunte se esta dúvida é (G) Grande, (M) Média ou (P) Pequena.
Mas caso tudo já esteja entendido, simplesmente classifique o tamanho do esforço como (G) Grande, (M) Média ou (P) Pequena.
Esta ação pode ser repetida para cada item do backlog, enquanto o time tiver entendimento e os itens estiverem de acordo com o propósito do planejamento.
A Importância da Comunicação
Se durante a classificação existir dúvidas de negócio, o Product Owner pode ser acionado para explicar qual o comportamento esperado daquele item.
Se o time perceber que há muitas dúvidas técnicas, pode acionar um especialista para auxiliar na explicação ou criação de provas de conceito. Este é um bom momento para entendimento, diminuindo os riscos que podem aparecer durante o desenvolvimento.
Acima de tudo, o importante é a comunicação.
Acompanhando times que utilizam o agile planning board, iremos observar que após iniciar o uso, o jogo do planejamento vai se tornando cada vez mais simples.
Veja alguns casos:
Triangulação
Supondo que você já tem um item classificado com esforço pequeno e outro item classificado com esforço grande. Então surge um terceiro item, que é um pouco maior que o primeiro, mas não tão grande quanto o segundo.
Podemos facilmente realizar o conceito de triangulação, classificando o novo item com um tamanho médio, sem a necessidade de grandes discussões.
Analogia
Se surgir um item similar a outro previamente discutido, basta classificá-lo na mesma coluna.
Desagregação
Vamos supor que o time de desenvolvimento entendeu que há um item com grande complexidade técnica e por isso será necessário realizar uma prova de conceito para validar algumas hipóteses de desenvolvimento.
Neste momento, o time decide quebrar o item em um mais simples para testes tecnológicos (spikes) e manter outro item com as regras de negócio, sendo que se este último não tiver os riscos técnicos, pode ser avaliado com um nível de complexidade menor que teria se tivesse que fazer tudo ao mesmo tempo.
Sendo assim, é sugerido que o item para validação técnica seja realizado em uma interação que antecede a que será realizado o item de negócio.
Dê maneira bem visual, conseguimos dar visibilidade a todos os envolvidos sobre o nível de conhecimento dos itens.
A transparência e a comunicação são premissas fundamentais para realizarmos um bom planejamento.
Em breve falaremos mais sobre os conceitos por trás do Agile Planning Board, estimativas e métricas.
Abaixo segue uma apresentação sobre o assunto disponível no SlideShare:
Referências: https://agileplanningboard.wordpress.com/
