O time entregou o MVP, e segue trabalhando nas funcionalidades do próximo incremento do produto. Mas agora começou a receber feedback nas funcionalidades entregues: pequenos bugs e melhorias. Como lidar com esse feedback perante o que está planejado como trabalho para o próximo incremento do produto?
Para isso sugiro kanban. Segue abaixo um kanban que demonstra como um time pode lidar com tal situação.
Note neste kanban que o time decidiu a capacidade alocada para lidar com os bugs e para trabalhar no próximo incremento do produto. Isso fica visível pelos limites de WIP das colunas Doing.
Note também que bugs e melhorias passam por uma etapa de priorização antes de entrarem em Doing. Enquanto que as funcionalidades do próximo incremento do produto (MVP2 na imagem) seguem a ordem definida na Lean Inception.
Capacidade para lidar com os bugs
O time deve decidir a capacidade alocada aos MVPs já em produção perante aos próximos incrementos. Por exemplo 20 % / 80%. Esses são os valores decididos no kanban exemplificado acima. Tal razão é definida pelos limites WIPs (Work in Progress) identificados em Doing.
Ao decidir valores de WIP para bugs/feedback e WIP para o MVP em construção, o time estará definindo a capacidade entre pequenas alterações no que está pronto e na criação do que está por vir.
No exemplo apresentado, o time decidiu 20 % da sua capacidade para bugs e feedback; ou seja uma de cinco tarefas em desenvolvimento é relacionada a um bug ou feedback do produto já entregue. Enquanto que quatro de cinco tarefas em desenvolvimento — 80% da capacidade — é para o próximo incremento do produto, as novas features.
>> Você encontra mais sobre esse assunto no eBook Lean Product Development: Guiando a Construção do MvP com Scrum e Kanban
![[Kanban] Kickback ou Stop the Line](https://caroli.org/wp-content/uploads/2019/03/exemplo-kanban-kickback-stop-the-line2.jpg)