Como tornar reuniões mais ágeis
Achei um artigo no site Agile Commons dando dicas sobre como tornar mais ágeis as reuniões de planejamento. O artigo, dividido em duas partes (Shorter Agile Meetings, Part 1: Iteration Planning e Shorter Agile Meetings, Part 2: Release Planning), dá algumas boas dicas, em especial nesse trecho:
An Iteration Planning Meeting is all about agreeing as a team that we can deliver a certain amount of work within the upcoming iteration, and figuring out how to go about implementing that work. For me, the most important part of a successful IPM is that the whole team agrees on what is to be built, right down to detailed acceptance criteria for each story.
This part of the meeting goes a lot faster if you’ve done some of the following:
1. The Product Owner comes in with a prioritized list of user stories to be built
2. The team, or at least a few members, know what’s at the top of the list
3. The Product Owner has done a first pass at writing acceptance criteria for the stories
4. The Product Owner and a tester have discussed those stories and added negative tests (edge cases)
5. The tech lead has looked at the stories and acceptance criteria, and discussed these with the Product Owner
6. The team got the list of stories a few days before, so they’ve had some time to think about implementation
Aqui na Locaweb observei alguns casos de pequenos desperdícios durante as reuniões de planejamento. A identificação e eliminação desses desperdícios podem agilizar bastante as reuniões que duram mais tempo do que o necessário. Algumas situações comuns que identifiquei:
- Organização do Backlog durante a reunião: Vi alguns casos em que o Product Owner organiza o backlog durante a reunião de planejamento, com toda a equipe presente. Essa organização inclui desde priorizar as histórias até procurar emails com solicitações de novas histórias, passando por tirar dúvidas com solicitantes externos. Essa prática acaba tomando muito tempo da reunião e de todos os presentes, fazendo com que o foco se disperse e o resultado do planejamento fique comprometido.
- Discussões muito detalhadas: É importante discutir os detalhes necessários, mas somente os necessários. Em uma reunião recente, vi a equipe chamando um especialista de outra equipe e abrindo o Notepad para listar todas as regras de validação de um determinado campo. Perguntei se isso influenciava na estimativa em si, e descobri que a história já estava estimada. Na prática, saber que existem 3, 5 ou 13 regras de validação já é o suficiente para estimar a história, não é necessário listar e discutir cada uma delas.
- Discussões de histórias que não entraram no sprint: Em outra reunião recente observei uma história que após uma breve discussão decidiu-se por não incluí-la no sprint - faltava definir alguns detalhes funcionais, e a prioridade nem era tão alta. Antes de passar para a próxima história uma outra dúvida foi levantada. Com isso, a equipe passou os próximos minutos discutindo novamente toda a história, não para decidir se ela deveria entrar mesmo no sprint, mas já definindo detalhes para quando ela entrar em um sprint futuro.
Uma solução simples
A solução que ajuda a minimizar esses problemas é simples: O PO enviar um email listando as histórias que serão discutidas para o próximo sprint. O email deve ser enviado para a equipe, para os solicitantes externos que pedem histórias, e para os POs das outras equipes.
Essa prática ajuda a:
- O próprio PO organizar o backlog previamente;
- A equipe conhecer as histórias que serão discutidas, e já levantar alguns detalhes que podem ser importantes;
- Os solicitantes saberem se suas histórias serão discutidas, e se prepararem caso sejam acionados para esclarecer dúvidas;
- Os solicitantes saberem que outras histórias suas não serão discutidas, e repriorizá-las caso necessário;
- Os POs de outras equipes saberem se alguma história pode impactar algum produto seu, ou se existe alguma dependência que deva ser analisada;
- Divulgar a várias áreas o que a equipe está fazendo.
Em outras palavras, voltando ao artigo da Agile Commons, enviar um email com antecedência ajuda a resolver os ítens 1, 2, 5 e 6 da lista. Para os itens 3 e 4, um Definition of Done claro e preciso ajuda a resolvê-los. Ou seja, com dois passos simples é possível diminuir bastante o tempo da reunião de planejamento.
Um detalhe importante: Da mesma forma que o ScrumMaster é o responsável por eliminar impedimentos que comprometam o andamento do sprint, ele também é o responsável por eliminar impedimentos que comprometam o andamento da própria reunião de planejamento. Puxando para o Lean Thinking, o valor da reunião de planejamento é ter o sprint planejado - qualquer coisa que não ajude a equipe a atingir esse objetivo é considerado desperdício.
Tags: backlog, histórias, Planejamento, product owner, scrum master