Artefatos do Scrum

Esse post faz parte de uma série sobre Scrum e descreve os Artefatos do Scrum. 

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

Artefatos

Os artefatos do Scrum foram desenvolvidos para manter a transparência do que está sendo executado, e para garantir que todos da equipe tenham um entendimento do artefato.

O Scrum possui os seguintes artefatos:

• Product Backlog
• Sprint Backlog
• Incremento

Product Backlog

O Product Backlog é uma lista ordenada de tudo o que é necessário para o produto. É a única fonte de informações dos requisitos das alterações que podem ser feitas no produto.

 

O Product Owner é o responsável pelo Product Backlog, incluindo o conteúdo, a disponibilidade e a ordenação.

 

O Product Backlog nunca está completo. A primeira versão possui somente os requisitos iniciais conhecidos até o momento. Conforme o produto vai evoluindo o Product Backlog vai evoluindo também.  

O Product Backlog é dinâmico porque o produto passa por diversas fases, e enquanto o produto existir o Product Backlog deve existir também.

 

O Product Backlog lista todas as características, funções, requisitos, melhorias e correções que constituem as alterações que podem ser feitas no produto para as próximas distribuições.

 

Os itens do Product Backlog possuem os atributos de descrição, ordem, estimativa e valor.

 

Conforme o produto for sendo utilizado e o mercado começar a dar retorno sobre o produto, o Product Backlog vai crescendo e se tornando uma lista cada vez maior. Os requisitos nunca param de sofrer alterações. Mudanças nos requisitos de negócios como, por exemplo, mudanças fiscais, mudanças de condições de mercado ou mudanças tecnológicas podem promover alterações no Product Backlog.

 

O refinamento do Product Backlog é o ato de incluir detalhes, estimativas e dar ordem aos itens. Este é um processo onde o Product Owner e a equipe de desenvolvimento colabora nos detalhes dos itens. 

Durante o refinamento os itens são revisados. A equipe do Scrum decide onde e quando o refinamento deve ser realizado. Ele não deve consumir mais do que 10% da capacidade da equipe de desenvolvimento. Entretanto os itens do Product Backlog podem ser atualizados a qualquer momento pelo Product Owner.

 

Os itens ordenados na posição mais alta são normalmente mais detalhados e claros do que os itens ordenados nas posições mais baixas. As estimativas dos itens mais claros e detalhados são também mais precisos.

 

Os itens do Product Backlog que irão ocupar a equipe de desenvolvimento no próximo Sprint são os que poderão atingir os status Done, dentro de um período de um Sprint.

 

Os itens que podem ser executados pela equipe de desenvolvimento, ou seja, que podem assumir o status Done são considerados como Ready para a seleção do Sprint Planning.

 

A equipe de desenvolvimento é a responsável por todas as estimativas. O Product Owner pode auxiliar a equipe de desenvolvimento no entendimento ou selecionando algumas trocas de itens, mas as pessoas que irão trabalhar no desenvolvimento é que definem a estimativa final.

A Figura abaixo exibe o exemplo de um Product Backlog do projeto de uma Biblioteca Virtual.

Sprint Backlog

O Sprint Backlog é criado pela equipe de desenvolvimento. Possui a previsão sobre qual funcionalidade estará presente no próximo Incremento, e o trabalho necessário para entregar essa funcionalidade.

O Sprint Backlog torna visível todo o trabalho que a equipe de desenvolvimento identifica como necessário para atingir o Sprint Goal. 

A equipe de desenvolvimento modifica o Sprint Backlog durante todo o Sprint. Conforme novos trabalhos são necessários, a equipe inclui os novos trabalhos. A estimativa sofre atualizações à medida que o trabalho é completado. Quando elementos do plano são considerados desnecessários, eles são removidos. Somente a equipe de desenvolvimento pode alterar o Sprint Backlog durante um Sprint.

 

O Sprint Backlog é um retrato em tempo real altamente visível, do trabalho que a equipe de desenvolvimento espera cumprir durante o Sprint, e ele pertence somente à equipe de desenvolvimento.

O progresso do Sprint pode ser monitorado através da verificação do trabalho pendente. A qualquer momento durante o Sprint o total de trabalho faltante pode ser visualizado. A equipe de desenvolvimento monitora o total de trabalho faltante pelo menos uma vez ao dia, durante o Daily Scrum.

A Figura abaixo exibe o exemplo de um Sprint Backlog do projeto de uma Biblioteca Virtual.

Incremento

O incremento é a soma de todos os itens completados do Product Backlog durante o Sprint, e o valor de todos os incrementos de todos os Sprint anteriores.

 

No final do Sprint o novo incremento deve estar com o estado Done, o que significa que ele está em condições de usabilidade independentemente do Product Owner resolver lançar ou não.

Quando um item do Product Backlog ou um Incremento é definido com o estado Done todos devem estar cientes do significado de Done. Apesar de o significado poder variar significativamente entre os membros do Scrum Team, os membros devem compartilhar o significado para que o trabalho esteja completo e a transparência garantida. 

 

A mesma definição guia a equipe de desenvolvimento em quantos itens do Product Backlog podem ser selecionados durante um Sprint Planning. O propósito de cada Sprint é entregar Incrementos de funcionalidades potencialmente prontas para lançamento, que aderem à definição de Done do Scrum Team.

 

A equipe de desenvolvimento entrega um Incremento de funcionalidade do produto a cada Sprint. Esse Incremento é utilizável, portanto o Product Owner pode optar pelo lançamento.

 

O Scrum Team deve seguir a definição de Done se o Incremento é parte da convenção padrão ou orientação da organização de desenvolvimento. Se a definição de Done para um Incremento não é uma convenção na organização de desenvolvimento, a equipe de desenvolvimento do Scrum Team deve definir uma definição de Done apropriada para o produto.

Se existem múltiplos Scrum Team trabalhando no sistema ou lançamento do produto, a equipe de desenvolvimento de todos os Scrum Team, devem mutuamente definir o significado de Done.

 

Cada Incremento é um aditivo de todos os Incrementos anteriores e completamente testados, garantindo que todos os Incrementos trabalhem juntos.

 

Conforme o Scrum Team vai amadurecendo, é esperado que suas definições de Done sejam expandidas a fim de incluir critérios mais rigorosos para melhorar a qualidade. Qualquer produto ou sistema deveria ter uma definição de Done que é um padrão para qualquer trabalho executado.

Eventos do Scrum

Esse post faz parte de uma série sobre Scrum e descreve os eventos do Scrum.

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

Eventos

Os eventos são utilizados para criar uma regularidade e minimizar a necessidade de reuniões não definidas. Todos os eventos são definidos com um período fixo e com duração máxima. Os eventos do Scrum são:

• Sprint
• Sprint Planning
• Sprint Goal
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Os eventos restantes terminam quando alcançam o propósito do evento, assegurando uma quantidade de tempo gasta, sem permitir desperdícios no processo.

 

Se houver uma falha em incluir qualquer um dos eventos irá resultar em transparência reduzida e uma oportunidade perdida para inspecionar e adaptar.

Sprint

A parte principal do Scrum é um Sprint que é um período fixo normalmente de um mês ou menos no qual se cria o incremento do produto. O Sprint é o repositório para todos os outros eventos e cada evento é uma oportunidade formal para fazer a inspeção e adaptação.

 

O Sprint consiste basicamente de um Sprint Planning, um Daily Scrum, o desenvolvimento do trabalho, o Sprint Review e o Sprint Retrospective.

A Figura abaixo ilustra as etapas de um Sprint estimado em 30 dias.

Um Sprint pode ser cancelado antes do final de seu período, caso um Sprint Goal fique obsoleto. Isto pode acontecer se a empresa mudar de direção ou se as condições do mercado ou da tecnologia sofrerem alterações. Somente o Product Owner tem a autoridade para cancelar um Sprint.

De um modo geral cancelar um Sprint só faz sentido mediante circunstâncias especiais. Mas devido a curta duração, este evento raramente acontece.

 

Quando se cancela um Sprint podem-se adotar as seguintes providências, dependendo do estágio em que o Sprint se encontra:

• Revisar qualquer item que esteja com o status Done no Product Backlog.
• O Product Owner pode aceitar o produto se puder lançar parte desse produto.
• Estimar novamente todos os itens incompletos e colocar de volta no Product Backlog.
• Estimar novamente o trabalho feito nos itens do Product Backlog.

O cancelamento de um Sprint é ruim porque consome muitos recursos. Todos os envolvidos devem se reagrupar novamente para fazer um novo planejamento. O cancelamento de um Sprint é uma atividade pouco comum.

Sprint Planning

O Sprint Planning define o planejamento do trabalho a ser realizado durante um Sprint. Cria-se o plano através do trabalho conjunto de todo o Scrum Team.

 

O Sprint Planning é um trabalho executado em um período que demora no máximo oito horas para o Sprint de um mês. Para Sprints menores o Sprint Planning pode demorar um pouco menos. 

A função do Scrum Master é garantir que o evento aconteça, que os participantes entendam o propósito do evento e mantenham o planejamento dentro do prazo fixado.

 

O Sprint Planning responde as seguintes perguntas:

• O que pode ser entregue em termos de Incremento?
• Como alcançar o trabalho necessário para entregar o Incremento?

Sprint Goal

O Sprint Goal é um objetivo configurado para o Sprint que pode ser atingido através da implementação do Product Backlog.  Ele funciona como um guia para a equipe de desenvolvimento na definição do porquê construir o Incremento. 

Ele é criado durante as reuniões de Sprint Planing. O Sprint Goal dá à equipe de desenvolvimento alguma flexibilidade em relação à funcionalidade implementada dentro do Sprint. Os itens selecionados do Product Backlog entregam uma função coerente, que pode ser o Sprint Goal.

 

A equipe de desenvolvimento trabalha com o Sprint Goal em mente. Se o trabalho acaba sendo diferente do que a equipe de desenvolvimento esperava, eles colaboram com o Product Owner para negociar o escopo do Sprint Backlog durante o Sprint.

Daily Scrum

O Daily Scrum é uma reunião de 15 minutos realizada pela equipe de desenvolvimento com o objetivo de discutir os seguintes pontos:

• O que “eu” fiz no dia anterior para atingir o objetivo do Sprint.
• O que “eu” farei hoje para auxiliar a equipe de desenvolvimento a atingir o Sprint Goal.
• Se “eu” vejo algum impedimento para atingir o Sprint Goal.

Para evitar complicações o Daily Scrum deve ser feito todos os dias no mesmo local.

 

A função do Daily Scrum é inspecionar o trabalho realizado desde a última reunião e prever o trabalho que será feito até a próxima reunião.

 

A equipe de desenvolvimento ou alguns membros da equipe frequentemente se reúnem após o Daily Scrum, para as discussões mais detalhadas e adaptar ou planejar o resto do trabalho do Sprint.

 

O Scrum Master deve garantir que as reuniões diárias do Scrum ocorram e não durem mais do que 15 minutos. A equipe de desenvolvimento é responsável em conduzir a reunião.

Sprint Review

O Sprint Review é uma reunião informal de no máximo quatro horas, para o Sprint de um mês, a fim de inspecionar o Incremento e revisar o Product Backlog, se necessário.

 

A reunião é formada pela equipe do Scrum e as partes interessadas no projeto. É realizado no último dia do Sprint. Os participantes colaboram com as informações das próximas atividades.

 

O Scrum Master deve garantir que a reunião aconteça obedecendo ao tempo limite. O Sprint Review inclui os seguintes elementos:

• Os participantes são a equipe Scrum e as pessoas chaves convidadas pelo Product Owner.
• O Product Owner explica quais os itens do Product Backlog foram para o status Done. A equipe de desenvolvimento explica o que deu certo, o que não funcionou e como o problema foi resolvido.
• A equipe de desenvolvimento mostra o trabalho que foi realizado e responde perguntas sobre o Incremento.
• O grupo inteiro colabora com as informações do que fazer a seguir, de forma que o Sprint Review gere a entrada para o próximo Sprint Planning.
• Verifica se o mercado ou a função do produto sofreu alguma alteração, para decidir o que fazer a seguir.
• Revisa a linha de tempo, orçamento e mercado para prever o próximo lançamento do produto.

O resultado do Sprint Review é um Product Backlog revisado que define os prováveis itens do próximo Sprint.

Sprint Retrospective

O Sprint Retrospective é uma oportunidade para a equipe Scrum fazer uma avaliação e verificar possibilidades de melhoria no projeto, que podem ser inseridas no próximo Sprint. 

A reunião do Sprint Retrospective deve ocorrer após o Sprint Review e antes do próximo Sprint Planning, normalmente no último dia do Sprint. O Scrum Master deve participar desta reunião como um colaborador e garantir que não demore mais do que três horas, para o Sprint de um mês. Para Sprint menores este tempo pode ser reduzido.

 

A finalidade do Sprint Retrospective é:

• Inspecionar como foi o último Sprint com relação às pessoas, relacionamentos, processos e ferramentas.
• Identificar e ordenar os itens principais que foram bem e verificar as possibilidades de melhorias.
• Criar um plano para executar melhorias, com a finalidade de aprimorar a qualidade do produto.

No fim do Sprint Retrospective as melhorias que serão executadas já foram identificadas. Apesar dos aperfeiçoamentos poderem ser feitos a qualquer momento, o Sprint Retrospective é uma forma de oficializar as melhorias que são necessárias no produto.

Organização do Scrum

Esse post faz parte de uma série sobre Scrum que descreve a organização do Scrum. 

A série é composta pelos posts:

• Definição e Exemplo de Scrum
• História do Scrum
• Organização do Scrum
• Eventos do Scrum
• Artefatos do Scrum

Você pode também baixar o Ebook Introdução ao Scrum que apresenta todos os posts da série sobre Scrum.

Organização

A equipe Scrum é composta por um Product Owner, uma Equipe de Desenvolvimento e um Scrum Master. É auto organizada porque escolhe como executar o trabalho da melhor forma possível, ao invés de ser direcionada por outros fora da equipe. É funcional, porque possui todas as competências necessárias para realizar o trabalho, sem depender de outros que não fazem parte da equipe.

A equipe Scrum entrega produtos iterativamente e de forma incremental, para garantir que uma versão do produto funcional esteja sempre disponível, aumentando as oportunidades para um retorno de comentários.

O modelo de equipe do Scrum foi desenvolvido para aperfeiçoar a flexibilidade, criatividade e produtividade.

Product Owner

O Product Owner é o único responsável em administrar o Product Backlog (lista completa de funcionalidades que devem ser incluídas no produto), e possui as seguintes funções: 

• Incluir os itens no Product Backlog.
• Fazer a ordenação dos itens do Product Backlog, de forma a atingir os objetivos e missões.
• Aperfeiçoar o valor do trabalho que a Equipe de Desenvolvimento realiza.
• Garantir que o Product Backlog seja visível, transparente e claro para todos, além de definir para a Equipe Scrum qual é o próximo trabalho.
• Garantir que a Equipe de Desenvolvimento entenda os itens do Product Backlog no nível necessário.

O Product Owner pode fazer todo o trabalho descrito acima, ou passar para a Equipe de Desenvolvimento, entretanto continua sendo o responsável.

 

O Product Owner é uma pessoa, não um comitê. Pode representar o desejo do comitê no Product Backlog, mas os indivíduos que desejam alterar a prioridade dos itens, devem se dirigir ao Product Owner.

 

Para que o Product Owner tenha sucesso, toda a organização deve respeitar suas decisões. As decisões são visíveis no conteúdo e na ordenação do Product Backlog. Ninguém tem permissão de solicitar que a Equipe de Desenvolvimento trabalhe em um conjunto de requisições, e a Equipe de Desenvolvimento também não tem permissão de agir de acordo com opiniões de outras pessoas.

Equipe de Desenvolvimento

A Equipe de Desenvolvimento consiste de profissionais que são responsáveis em entregar um Incremento com status Done do produto, no final de cada Sprint (período onde são desenvolvidos os itens acertados no Product Backlog). Somente os membros da Equipe de Desenvolvimento podem criar o Incremento.

As Equipes de Desenvolvimento são estruturadas e autorizadas para organizar e administrar o seu próprio trabalho. As Equipes de Desenvolvimento possuem as seguintes características:

São auto organizadas, ninguém nem mesmo o Scrum Master, pode interferir na forma de transformar os itens do Product Backlog, em Incrementos de funcionalidades potencialmente prontas para o lançamento.

• São funcionais no sentido de possuir todas as habilidades necessárias em uma equipe para criar o Incremento do produto.
• O Scrum não reconhece nenhum título diferente de "Desenvolvedor", independente da função executada pelo profissional.
• O Scrum não reconhece nenhum subdomínio na Equipe de Desenvolvimento, independentemente de domínios particulares que precisam ser nomeados como testadores ou analista de negócios.
• Os membros individuais da equipe podem possuir habilidades específicas na área do trabalho, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo.

O tamanho ótimo de uma equipe de desenvolvimento pode ser pequeno o suficiente para ser ágil ou grande o suficiente para completar o trabalho dentro de um Sprint.

Menos do que três membros na Equipe de Desenvolvimento, diminui a interação e resulta em um ganho de produtividade menor. Equipes muito pequenas podem encontrar restrições durante o Sprint, que dificultam a entrega de um Incremento.

Equipes muito grandes podem dificultar a coordenação e podem gerar complexidade para administrar um processo empírico.

 O Product Owner e o Scrum Master não entram na contagem da Equipe de Desenvolvimento, a não ser que também estejam executando trabalhos no Sprint Backlog.

Scrum Master

O Scrum Master é responsável para que o Scrum seja entendido, assegurando que a Equipe siga a teoria, práticas e regras do Scrum.

 O Scrum Master auxilia aqueles que estão de fora da equipe a entender quais interações são úteis e quais não são. O Scrum Master ajuda todos a alterar essas interações de forma a maximizar o valor criado pela Equipe do Scrum.