Sprint

Em Scrum um projeto é executado em Sprints. O periodo do Sprint faz uma analogia à corrida frenética dos atletas realizada na ultima porção da pista mais perto da meta.

Cada Sprint define uma meta a ser cumprida e um tempo para a cumprir. A meta é documentada através de – sim, você já sabe – uma lista de historias. Esta lista é chamada de Sprint Backlog. À semelhança do Release Backlog que é um pedaço do Product Backlog, o Sprint backlog é um pedaço do Release Backlog.

O Sprint Backlog deve conter histórias que uma vez implementadas possam fornecer algum tipo de demonstração do release. No principio pode ser algo muit cru como um protótipo navegável ou um valor aparecendo na tela. Mas com mais sprints e sprints a demonstração irá cada vez mais se aproximar do release a ser entregue.

O Sprint te, então, os seguintes objetivos:

1. Estabelecer um periodo de tempo durante o qual o foco é máximo.
2. Estabelecer um compromisso entre o Dono do Produto , a Equipa e o Scrum Master sobre o que será entregue no final desse período.
3. Implementar funcionalidades que realmente tenham valor e não apenas que consumam recursos.

O Dono do Produto, mais uma vez, é encarregado de montar o Sprint Backlog com base na prioridade das historias do Release Backlog e a Equipa é encarregada de se comprometer em realizar essas historias. Sempre que as historias não caibam no sprint ou sempre que haja impedimentos tecnicos ou outros, a Equipa é responsável por deixar isso claro tanto ao Dono do Produto quanto ao Scrum Master. Baseado nisso o Dono do Produto re-prioriza as historias e o Scrum Master toma nota dos impedimentos. Sim, você acertou de novo: em uma lista de impedimentos. Antes do inicio de cada sprint é feita uma reunião entre a equipa scrum para definir todos estes pontos. No fim desta reunião dois artefactos são produzidos:

Um Sprint backlog devidamente priorizado e uma lista de impedimentos também devidamente priorizada.

Período de um Sprint

O Sprint é o fator tempo em Scrum. Quantos sprints serão feitos e qual a duração de cada um estabelece desde o inicio o tempo necessário para entregar o release.

Durante o planejamento de Release deve ser estipulado qual é a duração de um Sprint em dias uteis.  O objetivo é que o Release tenha de 4 a 12 Sprints e em que cada Sprint seja possivel à equipa entregar uma versão funcional do release. Pensemos nisso como um protótipo funcional onde o funcionamento é real e não simulado. Isto dá uma ideia menos abstracta ao Dono do Produto daquilo que o Produto será e o ajuda a tomar decisões para a sua priorização de histórias. Este release semi-pronto é chamado informalmente de demo. No fim de cada Sprint a demo é apresentada a quem quiser ver. A apresentação é dirigida à equipa mas aberta a qualquer um que queira assistir (membros de outros projetos, por exemplo).

A duração  comum de um Sprint é de 10 a 20 dias uteis . Menos que duas semanas é muito pouco tempo para adicionar histórias que adicionem valor ao demo e mais do que quatro semanas pode ser demais para a equipa conseguir fechar uma versão entregável.

É conveniente que sejam incluidos sprints exclusivamente devotados a matar bugs existentes e descobertos nos sprints anteriores e um ultimo sprint para “fechar” o release.

Velocidade da Equipa

Outro fator que é necessário considerar para a distribuição do Release em Sprints é a Velocidade da equipa. Quando a equipa já trabalha junta a alguns projetos ela tem uma boa estimativa da sua velocidade. Para equipes novas é possivel fazer um sprint de teste-drive para tentar avaliar a velocidades. Para este “sprint zero” é bom escolher um tempo razoável para a equipa tenha tempo de executar algo palpável de 10 a 15 dias uteis e escolher historias variadas de forma que os resultados possam ser extrapolados para as outras historias.

A velocidade da Equipa é o numero de Pontos de Historia que a Equipa consegue completar em um Sprint ( considerando o sprint um periodo sempre igual ao logo do release). A unidade é portanto Pontos de Historia por Sprint (SP/Sprint).

Sprints e Milestones

Uma forma também proveitosa de encarar os sprints é defenir que após cada um uma milestone do release/ projeto será alcançado. Milestones são conjuntos de funcionalidades que uma vez completos são ânimos para completar os próximo mostrando que é possivel entregar o Produto.

Esta correspondência tende a aumentar o sprint para periodos de 20 a 30 dias uteis mas pode ser uma vantagem se existe duvida quanto ao sucesso do produto final.

Planejamento do Sprint

Depois que foi definido quantos e quais sprints serão feitos é a hora que executar o Sprint.

A primeira coisa a fazer é definir um Sprint backlog. Isso é feito entre toda a equipa scrum. Depois disso a equipa, sem o Scrum Master ou o Dono do Produto se reunem para partir cada historia em tarefas que possam se executadas pelos menbros da equipa. É dada total liberdade para que as tarefas seja escolhidas e otorgadas como a equipa desejar.

Em um primeiro passo, historia por história, a equipa divide o trabalho necessário para completar a historia em tarefas. O tamanho destas tarefas têm que ser tal que cada uma ocupa no máximo 16 horas uteis.  Após a devisão o segundo passo é estimar cada uma.

A soma das estimativas de todas as  tarefas de todas as historias do sprint  é uma estimativa do tempo real necessário para completar o Sprint. Se tudo correu bem este tempo será menor ou igual ao numero de horas existentes em um Sprint.

Lembre-se que ao aceitar que uma historia entre no Sprint Backlog a Equipa está assumindo o compromisso partilhado de entregar aquela historia comple no fim do sprint. Esse é um compomisso com o Dono do Produto , o Scrum Master e todos os demais membros da equipa. Portanto não é algo que se deve tomar de leve.  Se necessário for, a equipa pode estimar as tarefas e o tempo das historias de maior prioridade no Release Backlog para ajudar na hora de se compremeter peranto o resto da equipa. O que nunca a equipa deve fazer é se comprometer com algo que ela sabe que não será capaz de cumprir, ou pior, comprometer-se como algo que ela tem a certeza que não poderá cumprir.

No dia zero do Sprint ( formalmente antes do trabalho realmente começar) é feita uma runião onde a equipa scrum estabelece o Sprint backlog e a Lista de Impedimentos. Pode ser que no primeiro sprint já se vislumbrem impedimentos para os próximos sprints e isso deve ser resolvido pelo Scrum Master enquanto a equipa trabalha no sprint.

Durante o Sprint

A cada dia do sprint a equipa reune com o Scrum Master por não mais de 15 minutos para o deixar a par de novos impedimentos e ficarem a par dos que foram resolvidos. Além disso cada membro da equipa conta o que está irá fazer naquele dia e como correu o dia anterior. Quais tarefas foram terminadas e quais não e porquê. Além disso cada membro da equipa que esteja sem tarefas escolhe uma tarefas ainda disponiveis. Durante esta reunião o Sprint Burndown Chart é atualizado com as tarefas já feitas. O Scrum Master avalia a carga da equipa e se ela poderá completar o sprint.

Caso todas as Historias sejam terminadas antes do fim do sprint, o Scrum Master junto com a equipa poderá nomear novas historias seguindo a prioridade estabelecida no Release Backlog pelo Dono do Produto. Em alternativa o Dono do Produto pode ser consultado para saber quais historias fazer a seguir.  Isto pode ser complicado porque o Dono do Produto pode não estar disponivel naquele momento. Sabendo disto,  para cada Sprint são  sempre incluidas uma ou duas historias que poderão ser feitas caso haja tempo e descartadas caso não haja. O termo para isto “slack”.  Definindo o slack previamente duranta a runião do principio do Sprint é mais facil à equipa saber o que fazer na ausencia de historias.

Por outro lado, pode ser necessário incluir uma historia no sprint que não foi prevista antes. Essa decisão cabe ao Scrum Master. O Scrum Master deve negociar com o Dono do Produto a remoção de historias ainda não iniciadas e que tenha tamnho total equivalente ao da nova historia. Na impossibilidade de fazer isto, ao aceitar a adição de uma nova historia o sprint, o tamanho do Sprint backlog será maior que o previsto o que significa que algumas historias ficaram imcompletas.

Também durante o sprint é possivel que sejam encontrados bugs. Os defeitos encontrados no produto ( que no mundo do software se chamam “bugs”) devem ser liquidados imediatamente. Na impossibilidade de fazer isso o defeito é adicionado uma lista chamada Lista de Defeitos ( Defect Backlog).  Todos aqueles que utilizam o Produto e têm acesso às frequentes demos liberadas pela equipa  poderão descobrir defeitos, por isso todos eles devem poder submeter defeitos para a Lista de Defeitos.

Fim do Sprint

No fim do Sprint uma nova reunião é feita com o Scrum Master e o Dono do Produto. Primeiro é feita a demonstração das funcionalidades adicionadas no sprint. Em segundo é revisado como o sprint correu. Que impedimentos ainda não foram resolvidos de Sprints passados. Quais impedimentos nasceram no sprint que acabou. Quais bugs estão presentes na Lista de Defeitos e quais histórias foram completadas.

De posse desta informação se faz um novo planejamento para o Sprint seguinte. Este ciclo de execução e planejamento de sprints continua até que o release seja completado.