O quarto dia de noventa minutos começa como os anteriores: reunião diária e preenchimento do Burndown Chart. A equipe tem o sentimento de que no terceiro dia conseguiu “tirar o atraso e realizar dez pontos, completando a terceira história (cadastro de estabelecimentos) e faltando apenas três pontos para concluir as duas primeiras (Figura 21.6), o que a coloca em uma situação relativamente confortável, mesmo levando em conta que nesse dia receberá o Product Owner para a Revisão do Sprint. Não há nenhum impedimento a ser resolvido pelo Scrummaster e, assim, ele se dedica ao desenvolvimento junto com o resto da equipe. De fato, após o intervalo de dez minutos, a equipe entra nos 35 minutos restantes do quarto dia com todas as histórias na coluna Feito. Nesse momento (mesmo em um Sprint real) eu gosto de fazer uma nova reunião diária para concluir o Burndown Chart, fazendo a equipe afirmar que todas as histórias estão concluídas e todas passaram pelo crivo da Definição de Pronto. O Backlog se parece, então, com o da Figura 21.6.
Figura 21.6 – O Burndown Chart antes da Revisão do Sprint.
A equipe está pronta, então, para a Revisão do Sprint junto ao Product Owner.
Você deve lembrar que, no início da dinâmica proposta no Capítulo 20, destacamos um Product Owner da equipe de produtos e todos os demais se transformaram na equipe de desenvolvimento de um produto que não era o seu. Quando conduzo essas dinâmicas de introdução aos Métodos Ágeis, há dois rumos a seguir a partir desse momento:
No caso de, efetivamente, seguir a formação de Product Owners em uma trilha destacada da oficina, esses já estão identificados e seguirão com dinâmicas diversas, usando outras ferramentas além do Product Vision Board (Mapas Mentais, Product Canvas e, em muitos casos, uma revisão do Business Model Canvas). A qualquer momento, porém, as equipes nas dinâmicas de desenvolvimento descritas nesse capítulo podem acioná-los para resolver dúvidas.
No caso de todos serem mantidos na mesma trilha, os Product Owners originais deixam de existir e também tornam-se desenvolvedores (não do produto criado dentro da equipe original, claro) e o facilitador (nas oficinas que conduzo, eu mesmo) torna-se o Product Owner para todas as equipes.
Independente do rumo adotado, o Product Owner em questão pergunta à equipe se deve seguir alguma ordem para testar as histórias. Ele lerá cada uma delas e as executará no protótipo de papel, podendo aceitá-las e movê-las para a coluna Entregue, ou negá-las, revisando-as (se necessário), caso em que elas já passam para o próximo Sprint Backlog.
Uma história pode ser dada como não concluída por qualquer motivo e isso é prerrogativa única do Product Owner. Ele mesmo pode ter sido o culpado, ao reconhecer que não soube explicar ou garantir a redação correta de uma história. A culpa pode ser da equipe em assumir que compreendeu sem perguntar tudo o que devia ao Product Owner ou mesmo aos potenciais usuários. Isso não importa. Erros fazem parte do aprendizado e que bom que nossos Sprints são curtos para que os erros não sejam muito caros ou tão impactantes quando pensamos no produto integral. A Retrospectiva do Sprint nos ajudará na melhoria constante de nosso desenvolvimento com Scrum.
