Qual dos papéis do Scrum e único papel com autoridade para cancelar uma Sprint?

O método Scrum é uma estrutura para desenvolvimento ágil de produtos e gerenciamento ágil de projetos.

Apesar de suas origens no desenvolvimento de software, o Scrum está se tornando cada vez mais popular em projetos que não são de software.

Após uma introdução geral, apresentarei os papéis e responsabilidades em uma equipe Scrum, reuniões e atividades Scrum e os artefatos Scrum mais importantes. 

O que é Scrum?  

Scrum é um termo de rugby e significa literalmente “esforço ordenado”.

Os dois fundadores do Scrum, Jeff Sutherland e Ken Schwaber, apresentaram o método Scrum pela primeira vez em uma conferência em 1995. Desde então, o método Scrum tem sido continuamente desenvolvido e tem contribuído significativamente para a compreensão atual dos métodos de trabalho ágeis.

Os dois pais do Scrum também foram fundamentais na formulação do manifesto ágil em 2001. 

Definição do Scrum 

Se você quiser responder à pergunta “O que é Scrum?” de forma breve e concisa, acho a definição de scrum mais adequada é: Um framework para colaboração em equipe baseado em uma definição de papéis, reuniões e ferramentas que dão uma estrutura de equipe e um processo de trabalho claramente definido baseado em princípios ágeis.

Scrum não é um método dogmático mas um framework que oferece a uma equipe e stakeholders envolvidos diretrizes e pontos de referência para sua cooperação e comunicação.

O método Scrum está sendo constantemente desenvolvido por www.scrum.org e está documentado no Guia Scrum atual. O Guia do Scrum foi atualizado pela última vez no final de 2020. 

Princípios do Scrum

Antes de descrever a estrutura do framework Scrum em detalhes, vou entrar em alguns princípios-chave do Scrum.

Porque esses princípios e valores ágeis essenciais são a base sobre a qual o trabalho ágil em geral e o Scrum em particular são bem-sucedidos.

Em outras palavras, sem uma apreciação desses princípios básicos, você não pode trabalhar com sucesso com o método Scrum. 

  • Visão: Isso significa que cada Time Scrum segue um objetivo de longo prazo que serve como um ponto de referência abrangente.
  • Orientação de valor: As equipes Scrum medem seus resultados pelo valor que alcançam para os clientes e a empresa.
  • Transparência: Metas, decisões e tarefas pendentes são livremente acessíveis e conhecidas por todos os envolvidos e stakeholders.
  • Foco: Uma priorização consistente das tarefas a serem concluídas garante um alto nível de foco.
  • Autonomia: O Time Scrum é um time autônomo que trabalha de forma autodeterminada e auto-organizada.
  • Conformidade do processo: O processo Scrum não é negociável. Porque o processo dá segurança à equipe, reduz custos indiretos por meio de um alto nível de padronização e ao mesmo tempo contribui para um alto nível de transparência.
  • Feedback: Clientes, usuários e partes interessadas estão envolvidos de forma próxima e regular no processo Scrum e contribuem para a melhoria contínua com seu feedback. Além disso, o Time Scrum melhora sua colaboração por meio de retrospectivas regulares.

Estrutura do framework Scrum

O Scrum Framework é essencialmente baseado em três pilares centrais:

Papéis do Scrum – responsabilidades das pessoas envolvidas:

  • Proprietário do produto
  • Desenvolvedor
  • Scrum Master

Reuniões Scrum e atividades recorrentes:

  • Sprint
  • Planejamento
  • Diário
  • Análise
  • Retrô
  • Refinamento

Artefatos, ferramentas e termos importantes do Scrum:

  • Backlog do produto
  • Itens do Backlog do Produto (Histórias do Usuário)
  • Backlog da Sprint
  • Planejamento de poker e estimativas
  • Definição de Pronto
  • Definição de Pronto
  • Incremento de produto
  • Objetivo de sprint
  • Objetivo do produto

Papéis do Scrum

Product Owner (PO)

O Product Owner (PO) ou Project Owner tem a tarefa de maximizar o valor do produto ou projeto. Para isso, ele equilibra os interesses da empresa (valor do negócio) e dos usuários/clientes (valor do usuário).

O PO formula e comunica uma visão de longo prazo para o projeto. Para que isso seja bem-sucedido, o PO precisa de um entendimento profundo das necessidades do cliente e da estrutura estratégica do ponto de vista da empresa.

A ferramenta mais importante do Product Owner é o Backlog e a priorização dos tópicos nele contidos. Dessa forma, o PO garante que a equipe esteja trabalhando nas tarefas certas e que todos na equipe estejam usando seu tempo de forma lucrativa no interesse da empresa e do cliente.

Além disso, o proprietário do produto formula uma “meta do sprint” e as “metas do produto” substitutas para cada sprint. 

Desenvolvedor

Com o Scrum Guide 2020, a equipe de desenvolvimento simplesmente se tornou o papel do desenvolvedor”. Isso significa simplesmente a equipe de implementação, que trabalha de forma autônoma e auto-organizada na implementação das tarefas acordadas.

Para fazer isso, uma equipe entre 3 e 8 pessoas se compromete com as tarefas a serem concluídas em um sprint. Isso significa que nenhum pacote de trabalho é atribuído pelo PO ou outras pessoas.

Em vez disso, a equipe decide durante o planejamento quais das tarefas priorizadas podem ser concluídas como parte do sprint. Para que as equipes possam agir de forma independente e se comprometer com as tarefas, é um pré-requisito importante que as equipes de desenvolvimento ou projeto sejam interdisciplinares.

Isso significa que todas as competências e habilidades necessárias estão disponíveis na equipe para resolver as tarefas acordadas e atingir os objetivos do sprint.

Scrum Master

O Scrum Master é o treinador da equipe e o proprietário do produto. Isso significa que sua tarefa mais importante é permitir que a equipe e o proprietário do produto façam seu trabalho da melhor maneira possível.

Ele remove obstáculos, contribui para uma implementação eficiente e apoia a equipe na adesão ao processo Scrum. Além disso, o Scrum Master protege a equipe de influências indesejadas.

Ele também treina as partes interessadas envolvidas e garante que os princípios ágeis sejam vividos por todos os envolvidos.

Sprints e Reuniões Scrum 

A segunda pedra angular importante do framework Scrum é o processo Scrum, que consiste em uma sequência recorrente de sprints.

Cada sprint é, por sua vez, caracterizado por reuniões de scrum claramente definidas.

Esta estrutura clara e, acima de tudo, a padronização das reuniões scrum contribuem para um alto nível de eficiência. Com o processo Scrum, você reduz a sobrecarga organizacional a um mínimo absoluto. 

Qual dos papéis do Scrum e único papel com autoridade para cancelar uma Sprint?

O processo Scrum é uma série de sprints. Cada Sprint, por sua vez, é estruturado por uma sequência de Reuniões Scrum. 

Sprint

O Sprint é o principal princípio organizador central no Framework Scrum.

Um sprint é um intervalo de tempo claramente definido no qual a equipe trabalha para concluir as tarefas acordadas e atingir a meta do sprint.

Sprints literalmente passam o bastão ao outro. Ou seja, o final de um sprint é o início do próximo sprint. A duração de um sprint é normalmente de 1 a 4 semanas e é determinada dependendo do produto/projeto. Deve ter em conta as seguintes condições gerais:

  • A duração do sprint é fixa, ou seja, todos os sprints têm a mesma duração. Isso se aplica até que você decida que uma duração de sprint diferente seria mais apropriada para seu projeto, então você altera a duração do sprint e permanece com esse período.
  • Sprints duram no máximo quatro semanas O ciclo relativamente curto de quatro semanas se deve à percepção de que quanto mais longo o ciclo, menor a qualidade do planejamento. Esse achado também é conhecido como o “cone da incerteza”. 

O que o PO e a equipe fazem durante o sprint?

A equipe executiva trabalha na implementação das tarefas acordadas.

Como o PO não está envolvido na implementação, ele tem a importante tarefa de manter e priorizar o backlog durante o sprint e, assim, preparar o próximo sprint novamente.

Ele também coordena com a equipe em reuniões de refinamento para que as tarefas do próximo planejamento já estejam pensadas e não sejam completamente novas.

Além disso, ele também está disponível para a equipe durante a implementação para consultas ou re-prioriza tarefas caso surjam novos insights durante a implementação que atrapalhem o planejamento original. 

Cancelamento de um sprint

Se o objetivo do sprint originalmente formulado não for mais relevante, se tornou obsoleto ou não promete mais nenhum valor, o PO pode decidir cancelar o sprint.

Alternativamente, o PO pode decidir que as tarefas de maior prioridade são retiradas do backlog.  

Reuniões Scrum 

Cada Sprint é estruturado por uma sequência de Reuniões Scrum.

Cada reunião tem um lugar claro no sprint. Isso inclui um objetivo claramente definido e uma caixa de tempo regulada, que depende da duração do sprint. Tudo isso contribui para uma cultura de reuniões muito eficiente e boa. Primeiro, darei uma breve visão geral e resumo das Reuniões Scrum. Nas seções a seguir, entrarei em mais detalhes sobre os objetivos e o processo das Reuniões Scrum.

EVENTOS META DURAÇÃO DE UM SPRINT DE 4 SEMANAS PARTICIPANTES
Planejamento Planejando o sprint 8h, no início do sprint  – PO
– Desenvolvedor
– Scrum Master (opcional)
Daily Sincronização sobre tarefas pendentes  Diariamente, máx. 15 minutos – PO (opcional)
– Desenvolvedor
– Scrum Master
Análise Desenvolvedores apresentam resultados de trabalho 4h, até o final do sprint. – Todos
– Partes interessadas
– Clientes
Retrospectiva Otimizando a colaboração 3h, até o final do sprint – Todos
Refinamento Esclarecimento e estimativa de itens de backlog 2 – 4 horas por semana – Product Owner
– Desenvolvedor
– Scrum Master (opcional)

Observe que os tempos fornecidos aqui se referem a uma duração do sprint de quatro semanas.

Além disso, o Scrum Framework é baseado na suposição ideal de que as equipes trabalham em tempo integral na implementação.

Isso significa que se você faz sprints mais curtos ou a equipe está trabalhando na implementação com menos capacidade, você ajusta a duração das reuniões do Scrum de acordo.

Planejamento do Sprint

Cada Sprint começa com um planejamento conjunto no qual todo o Time Scrum (PO, Desenvolvedores, Scrum Master) participa.

Durante o planejamento, as tarefas pendentes são discutidas e o esforço esperado é estimado.

Somente com a estimativa do esforço esperado o proprietário do produto pode tomar uma decisão final sobre a priorização com base no benefício esperado e no esforço esperado.

Se uma tarefa for priorizada, a equipe de implementação se compromete a concluir as tarefas. Para fazer isso, a equipe transfere as tarefas priorizadas para seu sprint backlog.

Durante o planejamento, o proprietário do produto formula uma meta de sprint.

Em um sprint de quatro semanas em que a equipe trabalha a 100% da capacidade, são programadas 8 horas para o planejamento do sprint.

Daily

O Daily é uma sincronização diária dos desenvolvedores ou da equipe de implementação. Isso significa que o Scrum Master e o Product Owner só participam opcionalmente.

Como a duração é limitada a 15 minutos, geralmente ocorre em pé. É por isso que às vezes é chamado de “Daily Stand Up”.

A ideia de fazer a reunião em pé tem um motivo bem simples. Em vez de entrar em detalhes, cada membro da equipe é convidado a dar uma breve atualização para sincronizar com seus colegas.

Onde estou agora? Preciso de ajuda? Tenho outras dúvidas?

Se houver necessidade de mais discussões, outras discussões ocorrerão após o diário, em vez de incomodar toda a equipe durante o diário.

A Diária acontece todos os dias no mesmo horário e no mesmo lugar por 15 minutos. 

Sprint Review

Ao final do sprint, a equipe implementadora apresenta os resultados do seu trabalho.

O proprietário do produto, as partes interessadas e os clientes estão convidados para esta revisão ou demonstração. Ou seja, a revisão oferece aos desenvolvedores um palco para apresentar seu desempenho no sprint anterior.

Por outro lado, as partes interessadas e os clientes têm a oportunidade de dar feedback e fazer perguntas para influenciar o planejamento futuro e a priorização do proprietário do produto.

No entanto, a decisão sobre o que é priorizado e como é de responsabilidade exclusiva do proprietário do produto. Isso significa que a revisão não é uma aceitação ou comparável a um comitê de direção.

Porque aqui se apresenta uma equipe autônoma que fez o melhor possível com base no planejamento conjunto com o product owner.

Outras tarefas são priorizadas pelo PO. Se houver motivo de insatisfação com o resultado, isso é assunto para a retrospectiva.

Retrospectiva

Finalmente, o sprint termina com uma retrospectiva do Time Scrum.

Os desenvolvedores, o proprietário do produto e o scrum master se reúnem para refletir sobre a cooperação e fazer acordos vinculativos para futuros sprints com base nesses insights.

Isso significa que a retrospectiva é apenas sobre o processo de trabalho, não sobre o conteúdo ou os resultados do trabalho.

O Scrum Master modera a retrospectiva de acordo com o exemplo a seguir.

  • Bem-vindo
  • Coletar informações e impressões
    • O que foi bem?
    • O que devemos ajustar?
    • O que poderíamos tentar?
  • Consolidar conhecimento
  • Formular tarefas para o sprint seguinte
  • Encerramento

Princípios ágeis e valores ágeis são particularmente importantes na retrospectiva.

Porque isso requer abertura, autorreflexão e desejo de melhoria constante. A retrospectiva conclui com acordos específicos que serão implementados no próximo sprint e também podem ter sua própria entrada no sprint backlog.

Refinamento do backlog do produto 

A única reunião scrum que não segue uma estrutura definida são as reuniões de refinamento.

O objetivo desses refinamentos é que o proprietário do produto e o desenvolvedor discutam o escopo, o resultado e os critérios de aceitação das próximas tarefas antes do planejamento do sprint.

Isso dá ao proprietário do produto a oportunidade de aprimorar seus requisitos e os desenvolvedores envolvidos a chance de pensar sobre eles. A ideia básica é que os desenvolvedores não apenas aprendam sobre um requisito durante o planejamento.

Essa sincronização prévia e um refinamento conjunto das tarefas são importantes, principalmente no caso de tarefas muito complexas e extensas, para garantir que o planejamento seja realizado com eficiência.

Então, se você não chegar ao ponto ou não chegar a uma boa conclusão durante o planejamento, o refinamento insuficiente pode ser uma causa possível. O refinamento não deve demorar mais do que 5-10% do tempo durante um sprint.

Artefatos e ferramentas do Scrum

Além dos papéis e atividades, os artefatos e ferramentas do Scrum são o terceiro bloco de construção central do framework Scrum.

A seguir, explicarei brevemente os seguintes artefatos do Scrum.

Backlog do produto

O backlog é a soma de todas as tarefas pendentes.

Isso significa que no backlog você encontrará todas as tarefas e ideias que você, como proprietário do produto, assume que criarão valor para o projeto ou produto ou que talvez precisem ser feitas apenas devido a requisitos formais.

A lista de pendências do produto é mantida pelo proprietário do produto, por exemplo, em um quadro Kanban e é continuamente priorizada.

Idealmente, o backlog do produto pode ser visualizado online pela equipe e pelas partes interessadas envolvidas. 

Itens do Backlog do Produto

Itens e tarefas individuais dentro do backlog são “itens do Product Backlog”.

Podem ser pequenas tarefas muito concretas, expansões de recursos existentes, novos recursos ou até novos épicos.

Esses épicos são então divididos em itens editáveis ​​do backlog do produto.

Cada item do backlog do produto contém o benefício esperado para o cliente, o valor agregado para a empresa, se aplicável e indicadores para avaliar a eficácia das medidas ou do recurso.

Além disso, o item de backlog contém critérios de aceitação necessários para o cumprimento da tarefa.

Mesmo que não haja um formato oficial para os itens do backlog do produto, as histórias de usuários se estabeleceram como o padrão de fato. 

Backlog da Sprint

O sprint backlog contém todas as tarefas que são processadas pelos desenvolvedores no sprint atual. Enquanto o backlog está sob a autoridade do PO, o backlog do sprint pertence exclusivamente à equipe de implementação.

O sprint backlog é resultado do planejamento do sprint. Porque aqui o PO e a equipe do projeto decidem juntos quais itens do backlog serão processados ​​no próximo sprint.

Se os desenvolvedores se comprometerem a concluir um item do backlog do produto, isso será incluído no backlog do sprint.

Qual dos papéis do Scrum e único papel com autoridade para cancelar uma Sprint?
Durante o planejamento, os desenvolvedores se comprometem a implementar os itens do backlog do produto priorizados, que são então inseridos no backlog do sprint. – ©Andreas Diehl

Definição de Pronto

Definição de Pronto (DoR) não é uma parte oficial do Guia Scrum, mas reflete uma ideia conceitual importante.

É assim que a equipe expressa seu entendimento sobre o nível de maturidade que uma tarefa no backlog pode ter para poder ser processada. Por exemplo, o benefício esperado ou as métricas para avaliar a eficácia podem fazer parte da definição de pronto.

Se uma tarefa não atender à definição de pronta, o PO é obrigado a desenvolver ainda mais o item do backlog do produto.

Assim como a Definição de Pronto (DoD), a Definição de Pronto (DoR) está sujeita a constantes ajustes e revisão crítica. Por exemplo, a equipe pode decidir ajustar a Definição de Pronto (DoD) ou a Definição de Pronto (DoR) como parte da retrospectiva.

Qual dos papéis do Scrum e único papel com autoridade para cancelar uma Sprint?
“Definição de Pronto” e “Definição de Pronto” em combinação com um fluxo de trabalho Kanban típico – ©Andreas Diehl

Definição de Pronto

Definição de Pronto (DoD) é um acordo e entendimento da equipe de quando o trabalho é feito.

Ou seja, o DoD contém regras gerais para a conclusão bem-sucedida de uma tarefa. Por exemplo, o DoD afirma que todos os critérios de aceitação devem ser atendidos para que uma tarefa seja concluída.

Além disso, uma equipe pode concordar, por exemplo, que os resultados do trabalho devem ser acessíveis e discutidos para todos para que uma tarefa seja realmente “feita”.

Da mesma forma, uma tarefa em seu quadro Kanban não pode ser movida para Concluído até que atenda às condições da Definição de Concluído. 

Incremento de produto

Se você ler ou ouvir o Guia do Scrum, o termo “incremento de produto” certamente virá à mente.

O incremento do produto descreve os resultados do trabalho alcançados durante um sprint.

Estimativas

Durante o planejamento do sprint, a equipe de implementação estima o esforço necessário para tarefas individuais.

Dessa forma, a equipe fornece ao proprietário do produto um feedback importante sobre o esforço de implementação esperado. O PO pode, portanto, comparar diretamente seus benefícios e esforços esperados e priorizar melhor seu backlog e tarefas para o sprint.

O valor estimado que uma tarefa recebe também é chamado de “pontos de história” com base em histórias de usuários. Se você somar os pontos da história de todas as tarefas do sprint, obterá uma medida do desempenho da equipe. Isso lhe dá uma orientação que o ajudará a planejar melhor a longo prazo. 

Poker de Planejamento

O “Planning Poker” estabeleceu-se como um método de estimativa. Cada membro da equipe recebe um conjunto de cartas, cada uma contendo um valor da série de Fibonacci (1, 2, 3, 5, 8, 13, 21…).

Depois de apresentar uma tarefa, todos os membros da equipe jogam sua carta ao mesmo tempo. Isso é para evitar que os membros da equipe influenciem muito uns aos outros. Com sua carta jogada, cada membro da equipe estima o esforço relativo esperado.

Esta não é uma estimativa absoluta de esforço mas o esforço esperado em relação a uma tarefa de referência. Porque a informação associada à estimativa é mais importante que o esforço absoluto.

Ou seja, se as estimativas diferirem muito, os desenvolvedores parecem ter entendimentos diferentes do escopo de uma tarefa. 

Objetivo de sprint

O objetivo do sprint é formulado pelo proprietário do produto durante o planejamento.

O objetivo do sprint tem a importante tarefa de fornecer aos desenvolvedores uma orientação sobre o que deve ser alcançado no sprint atual.

Objetivo do produto

O “Product Goal” foi introduzido com o Scrum Guide 2020. O objetivo do produto é um objetivo de cross-sprint e é particularmente relevante quando os resultados de um único sprint e seus “incrementos” são apenas etapas intermediárias para a conclusão de um novo recurso.

Isso significa que a meta do produto também é definida em vários sprints e oferece à equipe orientação adicional além de um único sprint.

O método Scrum como pai do gerenciamento ágil de projetos

Nesse meio tempo, o modelo Scrum passou por mais de 25 anos de testes e adaptação constante. Scrum é agora um padrão de fato para desenvolvimento ágil de produtos e gerenciamento ágil de projetos, especialmente em relação ao Kanban.

A valorização dos valores e princípios ágeis essenciais é a base sobre a qual o método Scrum se torna eficaz.

Para mim, o Scrum é um alicerce indispensável ao configurar uma organização de projeto ágil para o design bem-sucedido da transformação digital. E uma maneira boa e muito simples de abalar um pouco as fundações da organização de hoje.

Quais são os 3 papéis do Scrum?

O Scrum tem três papéis: proprietário do produto, mestre do Scrum e membros da equipe de desenvolvimento.

Qual dos papéis do Scrum abaixo assinalados é único?

19 resposta(s) Product Owner.

Qual dos seguintes papéis é responsável pela reunião de Sprint?

Sprint Planning O Scrum Master é o responsável pela realização da reunião para que todos entendam o propósito da Backlog do produto. Esse planejamento é realizado de forma colaborativamente pela equipe.

Quais são os papéis e regras do Scrum?

3.2 Regras Básicas do Scrum.
Cada Sprint tem quatro semanas ou menos de duração..
Não há intervalos entre os Sprints..
Cada Sprint tem a mesma duração..
A intenção de cada Sprint é criar um software “potencialmente utilizável”..
Cada Sprint possui um planejamento..