Se você está migrando de Scrum para Kanban ou se quer ter uma cadência mais puxada do seu planejamento prévio ao sprint, você pode usar um gatilho que lhe informe quando a ação de planejamento precisa acontecer. Deixa eu explicar melhor:
No framework Scrum temos uma cadência formal pré-definida para as ações de planejamento: acontecem no início de um novo sprint. Ou seja, o scrum didaticamente estabelece que sua “puxada” de novos itens ao fluxo de entrega acontecerá, por exemplo, de duas em duas semanas. Isso ajuda a pessoa que planeja o produto na antecipação dos itens de trabalho deixando-os ready para o dia da “puxada“.
Mas e quando não há sprints… como faz?
Já quem usa Kanban e não está mais sob o jugo das restrições scrumianas tem algumas opções para conduzir um planejamento mais on demand, just in time e sexy:
Cadência pré-definida opcional
Talvez você encontre um certo conforto nesta sugestão, pois se aproxima mais àqueles que usavam Scrum. A proposta aqui é manter cerimônias periódicas de abastecimento do fluxo, que poderiam até seguir a frequência dos antigos sprints, mas com o diferencial de alimentar o fluxo somente o suficiente.
Imagine que sua coluna Pronto para Desenvolvimento (ou similar) foi limitada em 10 itens. Logo, na sua cadência de planejamento as pessoas se reuniriam para planejar somente até preencher a coluna em 10 itens. Se há 5 itens na coluna, a reunião se limitaria a preencher somente mais 5. Se já possui 10 itens, a reunião é desmarcada. Daí vem ela ser “opcional”.
Obs: Eu prefiro ter reuniões pequenas e mais periódicas, por exemplo, uma vez por semana de 40 minutos. Se não houver a necessidade de planejar mais itens, temos a satisfação de cancelar a reunião. 🙂
Cadência on demand
Aqui a cadência obedece mais ao conceito de on demand. Define-se um limite mínimo à coluna de itens planejados e ao se atingir esse limite mínimo você tem o gatilho para então, e só então, planejar mais itens.
Usando o exemplo anterior e imaginando que o limite máximo da coluna de itens planejados é 10, vamos definir o limite mínimo em 4 itens. Assim, somente quando os itens desta coluna forem consumidos a ponto de chegar a ter somente 4 itens de trabalho, é que você deveria iniciar seus processos de análise e planejamento para que o fluxo não sofra de starvation (morra de fome, em bom português).
Usando o conceito com Scrum
Você também pode usar o conceito de reabastecimento para as etapas de refinamento prévio ao início do sprint do Scrum. Geralmente o Product Owner precisa envolver a área de negócio para obter detalhes para as demandas; conduzir, em outro momento, uma análise técnica preliminar para minimizar riscos; entender viabilidades técnicas e operacionais; concorrer prioridades com áreas demandantes diferentes; etc. Esse fluxo anterior ao início da sprint poderia se beneficiar dessa organização on demand sugerida aqui.
Usando o Jira para ver os limites
Já que muitos aqui usam o Jira, veja como sinalizar os limites máximos e mínimos nas colunas da ferramenta:
- Entra nas configuração do quadro (board) clicando naqueles 3 pontinhos (…) no canto superior direito da tela;
- Em seguida, no menu lateral esquerdo, escolha Colunas;
- Você verá as colunas do seu quadro e sobre cada coluna dois campos: à esquerda você colocará a quantidade de itens para o limite mínimo e à direita o limite máximo. Veja o exemplo na coluna Analisado.
Seu quadro então sinalizará em amarelo quando a coluna ficar com menos itens que o limite mínimo definido.
(Sinalizará de vermelho quando extrapolar o limite máximo)
Pronto! Agora sempre que sua coluna sinalizar você pode se ocupar em alimentá-la com mais itens. Ou, numa cadência pré-definida de reabastecimento, garantir que ela sempre esteja cheia. 😉
Neste post eu não respondi:
- Qual o limite ideal para minha coluna de itens planejados?
- Quem deveria participar da reunião de reabastecimento do fluxo? Seria igual à cerimônia de Planning?
- Como funciona esse conceito de limitar o trabalho em progresso?
- Isso é o Kanban Upstream?
Mais em breve! Deixe o seu comentário.