---

Aprenda o framework Scrum com um estudo de caso real! A resposta pode surpreender você!

Antes de iniciar o primeiro Sprint

Alex trabalha como Scrum Product Owner de um novo projeto de desenvolvimento de software. Uma de suas primeiras tarefas é avaliar e identificar os requisitos para entregar o valor de negócio que o cliente procura.

Ele precisa garantir que o cliente receba o software correto para alcançar resultados concretos de negócio. Ele registra os casos de uso essenciais e os discute com arquitetos, representantes do cliente e outras partes interessadas de TI e das áreas de negócio. (Veja nossa Exemplo Scrum)

Depois de reunir os casos de uso e requisitos de alto nível, ele os registra no Scrum Product Backlog e inicia uma sessão de estimativa e priorização com a equipe Scrum. Ao final da sessão, todos os itens do Product Backlog recebem uma estimativa inicial aproximada e uma prioridade.

Nessas sessões, Anna, a Scrum Master, garante que todos falem a mesma língua. Assim, o Scrum Product Owner, os membros da equipe e as partes interessadas ficam alinhados aos objetivos previstos. Dessa forma, têm uma compreensão adequada de conceitos possivelmente novos para eles, como caso de uso, backlog, Sprint e outros. E, acima de tudo, o processo Scrum de desenvolvimento e entrega de software é aplicado corretamente no trabalho.

Agora, Alex, o Scrum Product Owner, começa a dividir os requisitos de alto nível num primeiro esboço de histórias de usuário mais detalhadas. Com essa lista, convoca a primeira reunião de Sprint Planning.

Sprint 1 — Dia 0

Durante a Reunião de Sprint Planning, Alex apresenta os itens do Product Backlog da maior para a menor prioridade. A equipe Scrum faz perguntas e esclarece dúvidas. Para cada item, discute se dispõe de capacidade e conhecimentos suficientes para desenvolvê-lo e entregá-lo. A equipe precisa garantir que todos os recursos humanos e técnicos necessários estejam disponíveis antes do início do Sprint. Ela precisa confirmar que todos os pré-requisitos e dependências essenciais à entrega bem-sucedida de determinadas funcionalidades foram atendidos.

Na reunião de Sprint Planning (parte “o quê”), os Desenvolvedores preveem que podem concluir as histórias de usuário 1,2,3,6,7 e 8 até o fim do Sprint, em apoio ao Objetivo do Sprint acordado. Essas histórias passam, então, do Product Backlog para o Sprint Backlog. As histórias de usuário 4 e 5 não podem ser concluídas neste Sprint porque parte da infraestrutura técnica necessária ainda não está disponível.

Depois da parte “o quê” da reunião de Sprint Planning, Anna, a Scrum Master, convida a equipe a aprofundar como implementará as histórias de usuário assumidas (parte “como”). As tarefas identificadas nessa parte da reunião são registradas em cartões e colocadas no Sprint Backlog. Agora, todos os membros da equipe Scrum estão prontos para escolher uma tarefa e começar a trabalhar.

Sprint 1 — Dia 1

Pela manhã, os Desenvolvedores se reúnem para sua reunião Daily Scrum. Cada pessoa faz uma declaração breve e concisa sobre o que realizou até então e atualiza as estimativas do trabalho restante nos cartões do Sprint Backlog. Cada um informa o que pretende fazer hoje e revela se existe algum impedimento que dificulte a execução das tarefas.

Hoje, Melinda, uma das integrantes da equipe Scrum, informa que tem um problema com a licença do ambiente integrado de desenvolvimento que utiliza. Anna, a Scrum Master, verifica se outras pessoas têm o mesmo problema e confirma que cuidará desse impedimento após a reunião. Depois de cerca de 15 minutos dessa reunião Daily Scrum, todos voltam ao trabalho.

Após a reunião, Anna atualiza o burndown do Sprint para visualizar o progresso do trabalho neste Sprint. Depois, liga para o fornecedor do software, encomenda a licença que falta e a entrega a Melinda.

Introdução ao Scrum: exemplo real (estudo de caso) ao longo de diferentes fases e Sprints

Sprint 1 — Dia 2

Pela manhã, os Desenvolvedores voltam a se reunir para sua reunião Daily Scrum. À tarde, James, um dos membros da equipe Scrum, tem dúvidas sobre o resultado esperado de uma história de usuário. Ele liga para Alex, o Scrum Product Owner, e ambos discutem a história para garantir que James a compreenda corretamente. Depois de ter segurança sobre como prosseguir, James continua sua implementação.

Sprint 1 — dia 6

O dia começa novamente com o Daily Scrum da equipe. Nesta manhã, Anna, a Scrum Master, percebe que a reunião tende a ultrapassar 15 minutos. Os membros estão discutindo a otimização de algumas consultas ao banco de dados. Anna lembra que as reuniões Daily Scrum não se destinam a longas discussões técnicas, mas a inspecionar o progresso rumo ao Objetivo do Sprint e adaptar o plano dos Desenvolvedores.

Depois do Daily Scrum, Alex (Product Owner) informa a Anna (Scrum Master) que o cliente apresentou novos requisitos que podem afetar o Sprint atual e os seguintes. Anna lembra educadamente a Alex que as mudanças não podem colocar em risco o Objetivo do Sprint. Os Desenvolvedores e o Product Owner podem esclarecer ou renegociar o escopo à medida que aprendem, em vez de tratar cada história selecionada como um compromisso imutável. Por isso, Anna organiza uma reunião de refinamento do backlog para a tarde, para que Alex apresente esses novos requisitos à equipe.

Durante a reunião, o grupo ajuda Alex a identificar como essas histórias se encaixam no plano geral de desenvolvimento do software, sua divisão inicial em tarefas, estimativas e prioridades.

Sprint 1 — dia 10

Finalmente, chegou o último dia deste primeiro Sprint. Anna, a Scrum Master, convida a equipe Scrum para a Reunião de Sprint Review. A equipe preparou um servidor fora do ambiente de produção com a versão mais recente do incremento de software em condições de entrega que criou.

Alex, o Scrum Product Owner, e o Sr. Rich, uma das partes interessadas do cliente, sentam-se diante de uma instância da interface gráfica do software. Eles verificam se a implementação atende às expectativas e se a equipe documentou adequadamente os detalhes do nível atual da aplicação.

Ao final da Sprint Review, Alex conclui:

• A equipe entregou as histórias de usuário 1,2,6 e 7 conforme assumido e esperado.
• A equipe não conseguiu terminar a história de usuário 3 no prazo e não a demonstrou. A história inacabada volta ao Product Backlog para reordenação; seu trabalho restante pode ser selecionado no próximo Sprint Planning.
• A história de usuário 8 não cumpriu a Definition of Done (DoD) comum. Ela volta ao Product Backlog, onde a equipe pode esclarecer os critérios de aceitação e as tarefas restantes antes de decidir quando selecioná-la novamente.

Alex, o Scrum Product Owner, e o Sr. Rich, representante do cliente, fazem uma breve atualização para a equipe Scrum sobre as próximas mudanças e desafios nos requisitos do software e a direção que a estratégia geral desse software deve seguir. O Sr. Rich agradece à equipe pelo esforço e compromisso e sai da sala.

Após a Sprint Review, a equipe Scrum se reúne para a Reunião de Sprint Retrospective. Nessa reunião, discute o que funcionou bem no Sprint e o que pode melhorar, para aprimorar previsões futuras e evitar a repetição dos problemas com as histórias de usuário 3 e 8 nos próximos Sprints. Um dos obstáculos identificados na Sprint Retrospective é o conhecimento insuficiente da equipe sobre a arquitetura geral do sistema. Anna, a Scrum Master, assume a tarefa de trazer um arquiteto de sistemas para orientar e acompanhar a equipe no início do próximo Sprint.

Sprint 2 — Dia 1

Alex, o Product Owner Scrum, continua a acrescentar novos requisitos ao Product Backlog Scrum com base nas suas reuniões recentes com o cliente. Além disso, esclarece os critérios de aceitação e o trabalho restante da história de utilizador 8, mantendo a Definition of Done comum, para que a Equipa Scrum consiga visualizar melhor o resultado esperado desta história de utilizador.

Alex convida então a equipa para a reunião de Sprint Planning do Sprint 2. A Equipa Scrum acorda um Objetivo do Sprint, e os Developers selecionam e planeiam as histórias de utilizador que o apoiam. Anna, a Scrum Master, ajuda a tornar o evento eficaz, e começa o segundo Sprint.