Guia do Scrum Comentado
O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto potencialmente liberável é criado.
Usa o tempo fixo para controlar riscos e custos e medir o que realmente se entrega nesse tempo fixo (time-box).
Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento.
Usamos Sprint de uma semana para quase todos os projetos.
Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.
As Sprints contém e consistem de um planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint.
Durante a Sprint:
• Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
Não pode ser incluídas coisas fora do objetivo e se alguma mudança for muito drástica pode levar ao cancelamento da Sprint.
• As metas de qualidade não diminuem; e,
Testes, homologação e implantação devem estar dentro da Sprint. Se diz que está “Pronto” tem que estar pronto, sem ressalvas.
• O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for aprendido.
Conforme vai recebendo feedbacks e descobrindo novos riscos ou oportunidades o escopo e esforço devem ser negociados.
Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês.
O ciclo empírico não pode ser demorado para não perder a chance de melhorias.
Como os projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem uma meta do que é para ser construído, um plano previsto e flexível que irá guiar a construção, o trabalho e o produto resultante do incremento.
Meta, plano, construção e resultados.
Sprints são limitadas a um mês corrido. Quando o horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode crescer.
Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.
Cancelamento da Sprint
Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master.
Cancelar uma Sprint significa aceitar um grande prejuízo.
A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem.
Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido.
Muito raro acontecer.
Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente liberável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado.
O cancelamento de Sprints consome recursos, já que todos se reagrupam em outro planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.
A Sprint agrupa todas as regras, eventos e cerimônias para construção de algo. Novamente, para não esquecer, ela não é um processo, seu processo deve funcionar dentro da Sprint e ser melhorado logo no final. Está claro qual o seu processo a ser melhorado?
Este artigo faz parte das minhas anotações sobre o Guia do Scrum, um capítulo em cada artigo, e se possível com exemplos práticos. Onde estiver em itálico é o texto do Guia, senão são minhas anotações.
