São responsáveis por criar e comunicar claramente os elementos do Backlog?

Esse artigo teve como base o Scrum Guide 2020, com o propósito de apresentar uma visão geral de toda a abordagem que compõe o framework Scrum.

A Definição do SCRUM

Jeff Sutherland em conjunto com Ken Schwaber, criaram o Scrum em 1993 com o intuito de mudar a forma como o desenvolvimento de Software era gerenciado. É um framework que ajuda pessoas e organizações a gerar valor através de soluções adaptativas para problemas complexos.

Teoria do SCRUM

O Scrum tem como base o empirismo e lean thinking.Empirismo é todo o conhecimento que vem da experiência e tomada de decisões baseado no que é observado. Lean Thinking reduz o desperdício e se concentra apenas no essencial.

Scrum tem uma abordagem iterativa e incremental, para otimização da previsibilidade e controle de riscos. Existem três pilares empíricos no Scrum: transparência, inspeção e adaptação.

Transparência

Os processos e o trabalho devem ser visíveis para todos, tanto para quem executa o trabalho quanto para quem recebe o trabalho. A transparência permite a inspeção, e uma inspeção sem transparência é enganosa, gerando desperdícios.

Inspeção

Artefatos Scrum e progresso em direção às metas devem ser inspecionados com frequência, para detectar variações ou problemas indesejáveis. A inspeção é realizada no Scrum por meio de seus cinco eventos, projetados para promover mudanças. A inspeção permite a adaptação, uma inspeção sem adaptação é considerada inútil.

Adaptação

Caso algum processo desvie fora de seus limites aceitáveis, ou se o resultado do produto for inaceitável, o processo que está sendo executado, ou os materiais que estão sendo produzidos devem ser ajustados. Os ajustes devem ocorrer o mais rápido possível, para minimizar novos desvios. A adaptação se torna mais difícil caso as pessoa envolvidas não sejam auto-gerenciadas, pois é esperado que o Scrum Team se adapte no momento em que aprende algo novo por meio da inspeção.

Valores do SCRUM

O Scrum é baseado em 5 valores:

• Compromisso: Scrum Team se compromete a atingir seus objetivos e suportar uns aos outros.
• Foco: Seu foco principal é o trabalho da Sprint para fazer o melhor progresso possível em direção a essas metas.
• Abertura: Scrum Team e seus stakeholders são abertos quanto ao trabalho e os desafios
• Respeito: Os membros do Scrum Team se respeitam quanto a serem pessoas capazes e independentes, e são respeitados como tal pelas pessoas com quem trabalham.
• Coragem: Membros do Scrum Team têm a coragem de fazer a coisa certa e trabalhar em problemas difíceis.

SCRUM Team

Dentro do Scrum Team não há sub-times ou hierarquias, tendo como principais integrantes um Scrum Master, um Product Owner e Developers.

Membros do Scrum Team são multifuncionais, ou seja, possuem todas as habilidades necessárias para criar valor a cada Sprint. Também são autogerenciáveis, decidindo internamente quem faz o quê, quando e como.

O Scrum Team deve ser pequeno o suficiente para ser ágil e grande o suficiente para concluir um trabalho dentro de uma Sprint, geralmente são formados por 10 pessoas ou até menos.

Se os Scrum Teams se tornarem muito grandes, eles devem considerar a reorganização em vários Scrum Teams coesos, cada um focado no mesmo produto. Portanto, eles devem compartilhar o mesma meta do produto, Product Backlog e Product Owner.

A responsabilidade do Scrum Team está em todas as atividades relacionadas ao produto, desde a colaboração e interação com os stakeholders, verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento, e qualquer outra coisa que venha a ser necessária.

Developers

São as pessoas que estão comprometidas em criar o incremento utilizável a cada Sprint.

Os Developers sempre são responsáveis por:

• Criar um plano para a Sprint, o Sprint Backlog;
• Introduzir gradualmente qualidade aderindo a uma Definição de Pronto;
• Adaptar seu plano a cada dia em direção à meta da Sprint;
• Responsabilizar-se mutuamente como profissionais.

Product Owner(PO)

É o responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. A forma de como isso é feito pode variar para cada organização, Scrum Team e indivíduos. Ele é uma pessoa que representa as necessidades de vários stakeholders, fazendo a ligação entre a área de negócios e tecnologia.

O Product Owner também tem como responsabilidade, gerenciar o Product Backlog, que inclui:

• Desenvolver e comunicar explicitamente a meta do produto;
• Criar e comunicar claramente os itens do Product Backlog;
• Ordenar os itens do Product Backlog por prioridade;
• Garantir que o Product Backlog seja transparente, visível e compreensível;

Para que os PO’s tenham sucesso, toda a organização deve respeitar suas decisões, decisões essas que são visíveis no conteúdo e na ordem do Product Backlog, e por meio do incremento inspecionável na Sprint Review.

Scrum Master

É o responsável por estabelecer o Scrum conforme definido no Scrum Guide. Eles fazem isso ajudando todos a entender a teoria e prática do Scrum, tanto no Scrum Team quanto na organização.

Também é responsável pela eficácia do Scrum Team. Eles fazem isso permitindo que o Scrum Team melhore suas práticas dentro do framework Scrum.

Os Scrum Masters são líderes servidores do Scrum Team e da organização como um todo. Ele serve ao Scrum Team de várias maneiras:

• Treinar os membros do time em autogerenciamento e cross-funcionalidade;
• Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que atendem à Definição de Pronto;
• Provocando a remoção de impedimentos ao progresso do Scrum Team;
• Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos dentro do Timebox.

O Scrum Master serve ao Product Owner de várias maneiras:

• Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;
• Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog claros e concisos;
• Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo;
• Facilitar a colaboração dos stakeholder, conforme solicitado ou necessário.

O Scrum Master serve a organização de várias maneiras:

• Liderar, treinar e orientar a organização na adoção do Scrum;
• Planejar e aconselhar implementações de Scrum dentro da organização;
• Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos;
• Remover barreiras entre stakeholders e Scrum Teams.

Eventos do SCRUM

Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os artefatos do Scrum. Esses eventos são projetados especificamente para permitir a transparência necessária. A falha em operar quaisquer eventos conforme prescrito resulta em oportunidades perdidas de inspeção e adaptação. Os eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum. O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade.

Sprint

Sprints são o coração do Scrum, onde ideias são transformadas em valor, e o container para todos os outros os eventos.

Com duração de 2 a 4 semanas, uma nova Sprint começa imediatamente após a conclusão da Sprint anterior.

Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints. Durante a Sprint:

• Nenhuma mudança é feita que coloque em risco a meta da Sprint;
• A qualidade não diminui;
• O Product Backlog é refinado conforme necessário;
• O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é aprendido.

Sprints permitem a previsibilidade, garantindo a inspeção e adaptação do progresso em direção a meta do produto. Cada Sprint pode ser considerada um projeto curto.

Existem várias práticas para prever o progresso, como burn-downs, burn-ups ou cumulative flows.

Uma Sprint pode ser cancelada se sua meta se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a Sprint.

Sprint Planning

É realizada antes de se iniciar uma Sprint. Todos os membros do Scrum Team devem participar, e através desse evento é definido todo o trabalho necessário e objetivo para a próxima Sprint.

O Product Owner garante que os participantes estejam preparados para discutir os itens mais importantes do Product Backlog e como eles são mapeados para a Meta do Produto. O Scrum Team também pode convidar outras pessoas para participar da Sprint Planning para fornecer conselhos.

A Sprint Planning aborda os seguintes tópicos:

Tópico um: Por que esta Sprint é valiosa?

O Product Owner propõe como o produto pode aumentar seu valor e utilidade na Sprint atual. Todo o Scrum Team então colabora para definir uma Meta da Sprint que comunica porque a Sprint é valiosa para os stakeholders. A meta da Sprint deve ser finalizada antes do final da Sprint Planning.

Tópico dois: O que pode ser feito nesta Sprint?

Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint atual. O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança. Selecionar o quanto pode ser concluído em uma Sprint pode ser um desafio. No entanto, quanto mais os Developers sabem sobre seu desempenho anterior, sua capacidade futura e sua Definição de Pronto, mais confiantes eles estarão em suas previsões quanto a Sprint.

Tópico três: Como o trabalho escolhido será realizado?

Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles como transformar itens do Product Backlog em incrementos de valor.

A Meta da Sprint, os itens do Product Backlog selecionados para a Sprint, mais o plano para entregá-los são chamados juntos de Sprint Backlog.

A Sprint Planning tem um timebox definido com duração máxima de de oito horas para uma Sprint de um mês.

Daily Scrum

O propósito da Daily Scrum é inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme necessário, ajustando o próximo trabalho planejado.

é um evento timebox com duração fixa de 15 minutos para os Developers do Scrum Team, sempre realizado no mesmo local e horário, todos os dias úteis da Sprint. Se o Product Owner ou o Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog, eles participam como Developers.

As Daily Scrums melhoram as comunicações, identificam os impedimentos, promovem a rápida tomada de decisões e consequentemente, eliminam a necessidade de outras reuniões, por meio de 3 perguntas:

• O que eu fiz ontem que ajudou a chegar mais próximo da Meta da Sprint?
• O que vou fazer hoje que irá ajudar a chegar mais próximo da Meta da Sprint?
• Quais impedimentos que estou tendo de chegar a Meta da Sprint?

A Daily Scrum não é o único momento em que os Developers podem ajustar seu plano. Eles costumam se reunir ao longo do dia para discussões mais detalhadas sobre a adaptação ou replanejamento do resto do trabalho da Sprint.

Sprint Review

Seu propósito é inspecionar o resultado da Sprint e determinar as adaptações futuras. O Scrum Team apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é discutido.

Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado na Sprint e o que mudou em seu ambiente. Com base nessas informações, os participantes colaboram sobre o que fazer a seguir. O Product Backlog também pode ser ajustado para atender a novas oportunidades. A Sprint Review é uma sessão de trabalho e o Scrum Team deve evitar limitá-la a uma apresentação.

A Sprint Review é o penúltimo evento da Sprint e tem um timebox com prazo máximo de quatro horas para uma Sprint de um mês.

Sprint Retrospective

Seu propósito é planejar maneiras de aumentar a qualidade e a eficácia.

O Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto. Os elementos inspecionados geralmente variam com o domínio de trabalho. As suposições que os desviaram são identificadas e suas origens exploradas. O Scrum Team discute o que deu certo durante a Sprint, quais problemas encontraram e como esses problemas foram (ou não) resolvidos.

O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias mais impactantes são endereçadas o mais rápido possível. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint.

A Sprint Retrospective conclui a Sprint. É limitada pelo timebox de no máximo três horas para uma Sprint de um mês.

SCRUM Artifacts

Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das principais informações. Assim, todos os que os inspecionam têm a mesma base para adaptação.

Cada artefato contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso pode ser medido:

• Para o Product Backlog, é a Meta do produto.
• Para o Sprint Backlog, é a Meta da Sprint.
• Para o incremento, é a Definição de Pronto.

Product Backlog

É uma lista ordenada e emergente do que é necessário para melhorar o produto. É a única fonte de trabalho realizado pelo Scrum Team.

Os itens do Product Backlog que podem ser realizados pelo Scrum Team em uma Sprint são considerados preparados para seleção no evento Sprint Planning. Eles geralmente adquirem esse grau de transparência após as atividades de refinamento. O Product Backlog refinement é o ato de quebrar e incluir definição adicional aos itens do Product Backlog para ter itens menores e mais precisos. Esta é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho.

Os Developers que farão o trabalho são responsáveis pelo dimensionamento. O Product Owner pode influenciar os Developers, ajudando-os a entender e selecionar trade-offs (trocas de itens).

Sprint Backlog

O Sprint Backlog é composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o Incremento (como).

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

Incremento

Um incremento é um trampolim concreto em direção a Meta do produto. Cada incremento é adicionado a todos os incrementos anteriores e completamente verificado, garantindo que todos os incrementos funcionem juntos. A fim de fornecer valor, o incremento deve ser utilizável.

Vários incrementos podem ser criados em uma Sprint. A soma dos incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor.

O trabalho não pode ser considerado parte de um incremento a menos que atenda a Definição de Pronto.

A Definição de Pronto é uma descrição formal do estado do Incremento quando ela atende às medidas de qualidade exigidas para o produto. No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento nasce. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para consideração futura.

Se a Definição de Pronto para um incremento faz parte dos padrões da organização, todos os Scrum Teams devem segui-la como mínimo. Se não for um padrão organizacional, o Scrum Team deve criar uma Definição de Pronto apropriada para o produto.

Os Developers devem estar em conformidade com a Definição de Pronto. Se houver vários Scrum Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de Pronto.

Quem é responsável por criar e comunicar claramente os elementos do Backlog de produtos?

Quem é responsável por preparar o Backlog priorizado do produto?

Quem cria e mantém o Sprint Backlog?

Qual é o papel do Scrum Master?