Certamente uma das principais características de um time Scrum é que ele é focado no problema a ser resolvido e no atingimento do Objetivo do Produto.
O foco não está em entregar horas de trabalho ou aumentar porcentagens de avanço em cronogramas, mas sim resolver um problema, através de algum resultado gerado.
De fato, o time gerencia seu próprio trabalho e têm autonomia para definir como trabalhar juntos e como fazer o trabalho, estando sempre alinhados com os objetivos da empresa e do produto que estão construindo.
Todos do time são mutuamente responsáveis pelo resultado do time como um todo e monitoram o andamento do seu próprio trabalho.
A forma como o Scrum aplica na prática seus pilares de transparência, inspeção e adaptação é através dos eventos.
Na verdade, esses eventos são projetados dentro da Sprint de forma estratégica para gerar a transparência necessária.
O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade. Todos os eventos do Scrum são “timebox”, ou seja, têm uma duração fixa de tempo.
Imagine que você está prestes a iniciar uma viagem de automóvel até uma cidade que você nunca foi antes e que está a 400 quilômetros de distância.
A estrada está com bastante neblina e você não sabe exatamente o que te espera durante o percurso, apesar de estar usando seu aplicativo de navegação por GPS.
Você somente enxerga alguns metros de distância e a cada pequeno trecho precisa re-planejar mentalmente como conduzirá o veículo.
Você também não sabe exatamente onde irá parar para abastecer, ir ao banheiro ou se alimentar, mas sabe que irá fazer entre 2 e três paradas, ajustando o plano da viagem algumas vezes…
Mike Cohn, um dos maiores especialistas em desenvolvimento ágil, diz que “um projeto está em risco se o seu planejamento vai além do horizonte de visibilidade do planejador e se o plano não prevê tempo para o time levantar a cabeça, olhar para o novo horizonte e fazer ajustes”.
Ao construirmos um produto de forma ágil, o planejamento é elaborado progressivamente durante o projeto e não somente no início.
O Scrum é um framework ágil, portanto, o produto é desenvolvido de maneira iterativa e incremental. O trabalho é realizado em diversas iterações (ou ciclos) que têm duração fixa. Chamamos uma iteração de Sprint.
A Sprint define a pulsação, a cadência durante o desenvolvimento do produto. Cada Sprint é considerada um evento “timeboxed”, ou seja, tem duração fixa de tempo e, portanto, tem datas de início e término definidas.
Em geral é mais comum encontrar times Scrum que utilizam Sprints de uma a três semanas. Não existe uma fórmula mágica para definir o tamanho da Sprint.
O tamanho da Sprint deve levar em consideração a duração estimada do projeto (caso você esteja trabalhando em um projeto específico), porém sugerimos que nunca seja maior que quatro semanas.
Imagine um projeto de três meses para desenvolver um novo produto. Se adotarmos um Sprint de 4 semanas (1 mês), teremos apenas três ciclos de feedback para mitigarmos os riscos e absorvermos possíveis mudanças durante o projeto.
Portanto, avalie a duração estimada do projeto e a quantidade de ciclos de feedback necessários para reduzir o risco do projeto.
É importante compreender a disponibilidade daqueles que irão avaliar e validar as entregas feitas pelo time a cada Sprint.