Antes de qualquer coisa Scrum não é um acrônimo e ele vem do Rugby (aquele esporte parecido com Futebol Americano). É um nome dado a reunião que ocorre no scrum (método de reinício de jogada onde as equipes ficam se empurrando com suas cabeças e corpos, uns com os outros), para em conjunto e equipe, levar a bola para frente (no sentido literal mesmo).

Bom agora sim, Scrum é um framework ágil de gerenciamento de projetos, voltado para as áreas de desenvolvimento de software. Com ele é possível que um projeto seja executado em pequenas partes, com verificações e feedbacks contínuos. No contexto do esporte Rugby, Scrum é onde a equipe se reúne para levar o produto para frente.

A estrutura Scrum tem pontos bastante simples: o Time Scrum, com o Dono do Produto, o Scrum Master e os Desenvolvedores. O Time Scrum participa de 5 eventos e produz 3 artefatos.

O Scrum se baseia em: transparência, que garante o fácil entendimento e visibilidade do projeto; a fiscalização, que visa o constante feedback e avaliação do trabalho já realizado e; a adaptação que faz constantes adequações ao andamento do projeto.

O Scrum possui valores importantes como Coragem, onde se deve ter a coragem de fazer a coisa certa e trabalhar em problemas difíceis; Foco, em que todos focam no trabalho do sprint e nos objetivos do time; Compromisso, em que a personalidade das pessoas se compromete a alcançar os objetivos do time; Respeito, em que os membros do time respeitam uns aos outros para serem pessoas capazes e independentes e; Abertura, em que o Time Scrum e as partes interessadas (stakeholders) concordam em ser abertos sobre todo o trabalho e os desafios na execução deles e ambos estes valores são elementos extremamente importantes e que os membros do projeto devem trabalhar juntos.

O Time Scrum se fundamenta em uma pequena equipe de pessoas (geralmente com dez pessoas ou menos). Temos o Scrum Master, o Dono do Produto e os Desenvolvedores e nesta equipe não existem hierarquia (lá vamos nós). O time então, se torna cada vez mais focado no objetivo, que é a Meta do Produto.

Foi observado no Scrum que as equipes menores se comunicam melhor e são mais produtivas. Caso os times Scrum se tornem muito grandes, deve ser reconsiderado dividir em equipes menores e claro, todos focados no mesmo produto.

Scrum Master

São os responsáveis em ajudar as equipes a terem sucesso o que acaba envolvendo oferecer ajuda em grupo ou individual. O Scrum Master acaba sendo o responsável pela eficácia do time, pois sempre deve melhorar a forma como a equipe trabalha. Em qualquer situação o Scrum Master deve possuir habilidades sociais e atuar como Líder Servidor, Líder Facilitador, Coach, Gerente, Mentor, Professor, Removedor de Impedimentos ou Agente de Mudança.

Dono do Produto

Ele é responsável por gerenciar a lista de pendências e isso inclui desenvolver e comunicar explicitamente o objetivo do produto, criar e comunicar os itens de pendência do produto, solicitar itens de pendência do produto e garantir que a lista de pendências do produto seja transparente. O Dono Produto pode fazer esse trabalho ou delegar a outros membros.

De todos os citados anteriormente, o Dono do Produto também representa as necessidades de muitas partes interessadas e se alguém na empresa/organização deseja uma mudança, precisa falar diretamente com o Dono do Produto e claro, tentar convencê-lo. Ele também fica como responsável por receber o feedback dos clientes, sobre o produto.

De toda forma e para atingir objetivos do Dono do Produto, ele deve ter posturas de o Visionário, o Colaborador, o Representante do Cliente, o Tomador de Decisão, o Experimentador e o Influenciador (ele precisa ser um “Severino” na parada).

Desenvolvedor

Um Desenvolvedor não é necessariamente um desenvolvedor de software e ele pode se concentrar em qualquer tipo de trabalho, seja de software ou não (não falei que era um “Severino”?). Pode se dizer que os Desenvolvedores são responsáveis por criar um plano para a Sprint, incutir qualidade e aderindo a uma Definição de Pronto, adaptar seu plano a cada dia em direção à meta do Sprint e responsabilizar uns aos outros como profissionais.

Os Desenvolvedores também podem precisar adotar práticas de facilitação (um Daily Scrum é um exemplo de evento de Desenvolvedores do Time Scrum e precisa de um facilitador), mentoria, ensino e coaching (é recomendado que um Desenvolvedor possua habilidades de orientar membros da equipe de como fazer algo).

Sprint

Cada evento no Scrum é uma oportunidade formal para adaptar artefatos do Scrum e a Sprint é uma espécie de contêiner de todos estes eventos. Este eventos são projetados para permitir a transparência necessária e a falha em operar quaisquer eventos, resulta em oportunidades perdidas de inspeção e adaptação. Ou seja, os eventos são usados para criar regularidade e minimizar a necessidade de reuniões.

Os Sprints são considerados a pulsação do Scrum, onde as ideias são transformadas em valor e: “o Sprint é o evento Scrum que engloba todos os outros eventos Scrum”.

O trabalho necessário para atingir o Objetivo do Produto, acontece das Sprints e durante elas. Nenhuma alteração é feita se essa colocar o objetivo em risco, a qualidade não diminui, a lista de pendências é refinada conforme necessário e o escopo pode ser esclarecido e renegociado com o Dono do Produto à medida que mais for aprendido.

Scrum Diário

É um evento de 15 minutos para os desenvolvedores do Time Scrum e usam para reduzir a complexidade. Ele é realizado no mesmo horário e local todos os dias úteis do Sprint. Se o Dono do Produto e o Scrum Master estiverem trabalhando ativamente em itens do Sprint Backlog, eles trabalham como Desenvolvedores. Os Scrums Diários melhoram a comunicação, identificam impedimentos, promovem a rápida tomada de decisão e consequentemente eliminam a necessidade de mais reuniões. Este também não é o único momento em que os Desenvolvedores podem ajustar seus planos, pois eles frequentemente se reúnem ao longo do dia para discussões mais detalhadas sobre como adaptar ou replanejar o restante do trabalho do Sprint.

Os Desenvolvedores escolhem qualquer estrutura técnica que desejarem, desde que seu Scrum Diário se concentre em atingir a Meta do Sprint e faça um plano prático para o próximo dia de trabalho.

Em um Scrum Diário o Scrum Master garante que a reunião aconteça, porém os Desenvolvedores são responsáveis pela condução e assim, os Scrums Master ensinam os Desenvolvedores a manter o evento dentro do tempo de 15 minutos.

O que é uma revisão de sprint?

Aqui ocorre a inspeção do Sprint e através do resultado determina se ocorrerá adaptações futuras. O Time Scrum apresenta os resultados para as partes interessadas (stakeholders) e o progresso em direção ao objetivo é discutido. O Time Scrum e as partes interessadas analisam o que foi realizado no Sprint e o que mudou. Tendo como base as informações obtidas e os participantes discutem o que fazer a seguir. O Time Scrum deve evitar que uma Sprint Review seja apenas uma sessão de trabalho.

A Sprint Review é o penúltimo evento e o tempo limite é de quatro horas para um Sprint de um mês. A Sprint Review pode decidir que: os participantes incluam o Time Scrum e as principais parte interessadas convidadas pelo Dono do Produto; os membros do Time Scrum explicam quais itens do Backlog do Produto foram ou não terminados; os Desenvolvedores discutem o que deu certo durante o Sprint; os Desenvolvedores demonstram o trabalho feito e responde dúvidas sobre o incremento; o Dono do Produto discute que o Backlog onde está e neste momento ele ou ela projeta metas prováveis e datas de entrega com base no progresso que ocorreu até o momento; todo o grupo colabora para decidir o que fazer a seguir, para que a Revisão do Sprint forneça informações valiosas para o planejamento do Sprint posterior; a revisão de como o mercado ou uso potencial do produto pode ter mudado o que é a coisa mais valiosa a fazer a seguir e; a Revisão do cronograma, orçamento, recursos potenciais e mercado para os próximos lançamentos previstos de funcionalidade e capacidade do produto.

Os artefatos Scrum

Backlog do produto: é a única fonte de trabalho realizada pelo Time Scrum, cujo objetivo é gerar uma lista emergente e ordenada do que é necessário para melhorar o produto.

O refinamento do Backlog do Produto é o ato de dividir e definir os itens em partes menores e mais precisas. Ele pode ocorrer a qualquer momento durante uma Sprint. O refinamento não é obrigatório porém deve considerar como uma boa prática para aumentar a transparência e tornar os itens de trabalho mais precisos.

O Objetivo do Produto descreve um estado futuro do produto que pode servir como uma meta para o Time Scrum planejar.

Um produto é um veículo para entregar valor. Tem um limite claro, partes interessadas conhecidas e usuários ou clientes bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato.

A Meta do Produto é um objetivo de longo prazo do Time Scrum e os itens do Backlog do Produto definem o que cumprirá o Objetivo do Produto à medida que o Time Scrum aprende mais sobre como atingir o objetivo enquanto trabalha em cada Sprint. O Objetivo do Produto é, portanto, uma declaração direcional simples que fornece contexto e propósito para o Time Scrum e suas partes interessadas (stakeholders).

O Sprint Backlog é um plano feito por e para os desenvolvedores. É uma imagem altamente visível e em tempo real do trabalho que os Desenvolvedores planejam realizar durante o Sprint para atingir a Meta do Sprint. Consequentemente, o Sprint Backlog é atualizado ao longo do Sprint à medida que mais é aprendido. Deve ter detalhes suficientes para que eles possam inspecionar seu progresso no Daily Scrum.

A Meta de Sprint é o único objetivo do Sprint. Embora a Meta da Sprint seja um compromisso dos Desenvolvedores, ela oferece flexibilidade em termos do trabalho exato necessário para alcançá-la. A Meta da Sprint também cria coesão e foco , incentivando o Time Scrum a trabalhar em conjunto, em vez de em iniciativas separadas. É criado durante o Sprint Planning pelo Time Scrum e então adicionado ao Sprint Backlog. À medida que os Desenvolvedores trabalham durante o Sprint, eles mantêm o Objetivo do Sprint em mente. Se o trabalho evolui e não é o que esperavam, colaboram com o Dono do Produto para negociar o âmbito do Sprint Backlog dentro do Sprint sem afetar a Meta da Sprint.

Um Incremento é um trampolim concreto em direção ao Objetivo do Produto. Cada incremento é aditivo a todos os incrementos anteriores e minuciosamente verificado, garantindo que todos os incrementos funcionem juntos. Para fornecer valor, o Incremento deve ser utilizável. A soma dos Incrementos é apresentada na Sprint Review apoiando assim o empirismo. No entanto, um Incremento pode ser entregue às partes interessadas antes do final do Sprint . A Sprint Review nunca deve ser considerada uma porta para a liberação de valor.

A Definição de Pronto (concluído) é o compromisso dos Desenvolvedores com o Incremento, assim como a Meta do Sprint é o compromisso dos Desenvolvedores com o Backlog do Sprint e a Meta do Produto é o compromisso do Dono do Produto com o Backlog do Produto. A Definição de Pronto inclui todas as características e padrões que um incremento precisa atender para ser lançado. Também pode ser dizer que é uma descrição formal do estado do Incremento quando atende às medidas de qualidade exigidas para o produto. Assim que a Definição de Pronto for atendida, o Incremento estará Feito e poderá ser entregue.

A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado dos padrões de trabalho exigidos como parte do Incremento. Isso pode ser tão simples quanto a equipe colaborar e anotar tudo em conjunto. Alguns Times Scrum também podem incorporar atividades de brainstorming.

Alguns exemplos dos itens em uma Definição de Pronto para um Estudo de Caso de Marketing escrito: Atende às diretrizes de marca do cliente em destaque; escrito em estilo AP; revisado pelo cliente em destaque e feedback recebido; feedback implementado e; rascunho Final Aprovado pelo Cliente.

Alguns exemplos dos itens de uma Definição de Pronto para um aplicativo de software voltado para a saúde: todos os testes concluídos; nenhum defeito conhecido, revisão de código concluída e aprovada; atende aos padrões de conformidade HIPAA e; atende aos requisitos gerais de segurança

Depois que todos os itens da Definição de Pronto estiverem marcados e concluídos, este incremento será considerado Feito. O Scrum é usado em trabalhos complexos e essas características podem ser adicionadas a uma definição de pronto para torná-la mais rigorosa.

Fonte:
https://www.scrum.org