O que é Scrum? E como ter sucesso 🚀

Metodologias ágeis:

É um grupo de métodos de maneiras de se gerenciar um projeto, o foco desse artigo será no scrum, o mais utilizado pelas empresas de software. Ele serve para lidar com projetos complexos onde muita coisa ainda é desconhecida.

Benefícios esperados:

Para a maioria das equipes ágeis, as histórias de usuários são o principal veículo de entrega incremental de software e oferecem os seguintes benefícios:

• Mitigam os riscos de feedback atrasado, ainda mais se os incrementos forem pequenos e ou se o software for lançado para produção com frequência.
• para o cliente ou proprietário do produto, a opção de mudar de ideia sobre os detalhes ou a prioridade de agendamento de qualquer história de usuário ainda não implementada para desenvolvedores, recebendo critérios de aceitação claros e precisos com feedback contínuo à medida que concluem o trabalho.
• Promovendo uma clara separação de responsabilidades entre definir o “o quê” (província do cliente ou proprietário do produto) e o “como” (província da equipa técnica), potenciando as competências e criatividade de cada um.

Scrum:

Ele consiste em uma série de “rituais”, “artefatos” e princípios, onde se deve seguir para ter os melhores resultados. Funciona a base do empirismo, experiências, observações e fatos, mas para isso dar certo precisa ter os três pilares.

Os três pilares do Scrum:

Transparência:

Todo mundo envolvido deve saber o que está acontecendo com o produto. Para isso precisamos usar uma linguagem comum à todos, criar um glossário por exemplo, ter informações sobre o projeto disponiveis e seguir os rituais.

Inspeção:

É o ato de fazer uma observação, tanto sobre o produto, pessoas processos, ferramentas ou artefatos. Qualquer um pode fazer e é por isso que importante a transparência, o melhor exemplo é que no final de toda sprint temos a retrospectiva onde fazemos observações para decidir onde podemos mudar/adaptar.

Adaptação:

A adaptação é o conceito central do scrum, é onde se diferencia de outros métodos mais comuns em empresas não SaaS (software como um produto). É por isso que os dois ultímos pilares são tão importantes, sem eles não tem adaptação.

Artefatos:

São as informações mais importantes da scrum como: backlog do produto (parte das tarefas que devemos completar para o projeto estar completo), backlog da sprint (parte que estamos desenvolvendo), incrementos (funcionalidades novas), a definção de pronto e aceite, e o burndown chart (métrica de progresso).

Product backlog:

Todas os itens (histórias) que devem ser feitas para o projeto ou produto estar pronto, é composto de temas, épicos, e histórias de usuário. As vezes também é chamado de Portolio e tem épicos no lugar de temas, features como épicos e backlog items como hístorias.

Deve ser composto pelo product manager e o scrum master, os desenvolvedores deve ajudar subdividindo, estimando e dando descrições claras as tarefas.

Todas as tarefas e histórias devem conter uma descrição para que o time (equipe de desenvolvimento) possa entender o que deve ser feito. É papel do scrum master e do product manager garantir a compreensão de todos, a equipe deve perguntar o tempo todo absolutamente tudo que não souberem ao scrum master durante as reuniões e ao product owner sobre alguma parte da tarefa que não entendeu, caso ele tenha feito a tarefa.

Sprint backlog:

Se diferencia do product backlog porque nos realizamos apenas as tarefas decididas na planning que foram pegas do backlog, isso é o sprint backlog, também chamado de kanbann board ou agile board.

Histórias de usuário:

Uma história nada mais é que tarefas que devem ser implementadas para conseguir atingir os desejos dos stakeholders (interessados no produto). Exemplo de uma história: Eu como usuário do site quero poder me cadastrar para poder ter acesso a meus dados e com base nisso acesso a informações mais específicas. Segue essa estrutura, Eu como [ ] quero [ ] para [ ].

A sigla INVEST ajuda a lembrar um conjunto de critérios amplamente aceito, ou checklist, para avaliar a qualidade de uma história de usuário. Se a história não atender a um desses critérios, a equipe pode querer reformulá-la ou até mesmo considerar uma reescrita.

“Independente” (de todos os outros)
“Negociável” (não é um contrato específico para recursos)
“Valioso” (agrega um valor claro para os usuários)
“Estimável (para uma boa aproximação)
“Small” (caber dentro de uma iteração, sprint)
“Testável” (em princípio, mesmo que ainda não haja um teste para isso)

Denominação dos itens do kanban board:

Dentro de um Kaban board temos hístorias de usuários que devem ser dividas em tarefas, pelos próprios desenvolvedores mesmo, tarefas boas tem um objetivo claro e é possível completa-la em 1 dia de trabalho. É muito bom também deixar a meta da sprint logo no backlog para que time se mantenha focado.

Nota:

• O nível de detalhe correspondente a uma história de usuário não é constante, evolui ao longo do tempo em função do “horizonte de planejamento”; por exemplo, uma história de usuário que está agendada para a próxima iteração deve ser melhor compreendida do que uma que não será implementada até a próxima versão.
• Uma história de usuário não é um Caso de Uso; embora muitas vezes seja útil comparar e contrastar as duas noções, elas não são equivalentes e não admitem um mapeamento um-para-um.
• Uma história de usuário em geral não corresponde a um componente técnico ou de interface do usuário: mesmo que às vezes possa ser um atalho útil para falar, por exemplo, “a história do diálogo de pesquisa”, telas, caixas de diálogo e botões não são histórias de usuário.
• Pode se ter dentro de uma história fotos de design, links para referência e outras ferramentas que ajudem a completar ela, como por exemplo uma história técnica dentro dela para explicar tecnologias e etc.

Antes da reunião de Planejamento da Sprint, o Product Owner deve:

• Verificar as prioridades das partes interessadas (stakeholders)

  Se eles mudaram, o Product Owner deve estar ciente e levar isso em consideração ao definir o que precisa ser alcançado no próximo Sprint.

• Refinar o Product Backlog

  Uma prática também conhecida como backlog grooming. Ter um Backlog saudável e priorizado prepara o cenário para o Sprint Planning. Mesmo que ainda não seja um evento scrum oficialmente aceito, muitas organizações hoje o consideram um passo crítico que melhora a velocidade e a eficiência.

• Verifique o Product Roadmap

  Para que o Product Owner escolha os recursos mais apropriados para serem entregues.

• Conheça a Capacidade, mas não a preencha

  Fique atento ao cronograma de todos durante o sprint e deixe algum espaço livre para quaisquer imprevistos que possam surgir.

• Certifique-se de que a definição de pronto esteja clara

  Para que você forneça clareza e crie o caminho para entregar de maneira previsível.

• Especifique os Critérios

  de Aceitação ou, em outras palavras, defina as condições que um produto deve satisfazer para ser aceito pelo usuário final, cliente ou sistema. Isso definirá a instrução com um resultado claro de aprovação ou reprovação.

• Peça ao Scrum Master para revisar o backlog da Sprint

  É de uma forma ou de outra o principal conselheiro!

Backlog grooming:

O refinamento de pendências (anteriormente conhecido como preparação de pendências) é quando o PO e alguns, ou todo o restante da equipe, revisam os itens do backlog para garantir que contenha os itens apropriados, que eles sejam priorizados e que os itens estejam pronto para entrega. Essa atividade ocorre regularmente e pode ser uma reunião oficialmente agendada ou uma atividade contínua. Algumas das atividades que ocorrem durante esse refinamento do backlog incluem:

• Removendo histórias de usuários que não parecem mais relevantes
• Criar novas histórias de usuário em resposta às necessidades recém-descobertas
• Reavaliar a prioridade relativa das histórias
• Atribuir estimativas a histórias que ainda não receberam uma
• Corrigir estimativas à luz de informações recém-descobertas
• Dividiriteração, garantir que uma história seja pequena o suficiente para caber na iteração/sprint.

A intenção do refinamento do backlog é garantir que o backlog permaneça preenchido com itens relevantes, detalhados e estimados em um grau apropriado à sua prioridade e de acordo com o entendimento atual do projeto ou produto e seus objetivos.

Ao contrário de um “documento de requisitos” mais formal, o backlog é entendido como um corpo dinâmico de informações.

Por exemplo, nem todas as histórias de usuários precisam ter sido divididas em um nível refinado no início do projeto ou receber estimativas detalhadas; mas é importante que a qualquer momento um número “suficiente” de histórias esteja pronto para agendamento nas próximas iterações.

Um projeto Agile é, não menos do que qualquer outro, sujeito a “scope creep”, na forma de histórias de usuários que não geram valor substancial, mas foram consideradas “boas ideias na época” e inseridas no backlog para que não fossem esquecido.

Na ausência de esforços explícitos destinados a administrar essa inflação, essa inflação resultaria nas patologias muito conhecidas de excessos de cronograma e orçamento.

Gráfico burndown:

É um meio de quantificar o progresso de uma sprint, é mais uma das tarefas do Scrum master, pode ser medido em ponto de história ou horas.

Normalmente, o eixo y vertical no gráfico de burndown mede o número total de histórias a serem concluídas, enquanto o eixo x mede o tempo em uma sprint. Um declínio constante na inclinação representa o cenário ideal, ou seja, com histórias de usuários e tarefas no caminho certo para terminar a tempo e, assim, serem concluídas para chegar ao final do sprint.

É mais uma das tarefas do scrum master, deve ser atualizada toda sprint, seve para ter uma ideia de progressão e assim também podendo estimar melhor o tempo das tarefas.

Gráfico velocity:

De maneira semelhante à forma como o gráfico de burndown mede o trabalho concluído em cada sprint, o gráfico de velocidade mede o trabalho concluído ao longo de um projeto inteiro. Com esta ferramenta, o eixo y representa o número de pontos da história e o eixo x o número de sprints.

Embora o gráfico de velocidade seja geralmente pensado como uma ferramenta de gerenciamento que fornece uma visão geral de alto nível da eficácia e produtividade da equipe, ele também deve ser visto como de grande valor para o scrum master em sua rotina de trabalho diária e semanal.

Os benefícios para ele é que, principalmente com equipes scrum experientes, ele consegue usar a velocidade média como uma ferramenta de planejamento útil para projetos atuais e futuros. Ele ganha uma visão muito mais clara das capacidades da equipe que tem à sua disposição.

Definição de aceite/preparado (DOR):

O DOR, trata-se de uma listagem de requisitos que determinada história ou tarefa necessita para que possa estar apta a entrar no backlog da Sprint. Normalmente essa lista fica vinculada a tarefa e cada item é marcado com check se está atendido ou não. A história só deve ser movida para o backlog da Sprint se todos os itens levantados durante o refinamento estiverem marcados.

Exemplificando uma história, na qual necessitará consultar outra aplicação, podemos citar na lista do DOR alguns itens como:

• Histórias de usuário devem ser escritas no padrão BDD
• O(s) critério(s) de aceite estão claros
• Serviço de Integração disponível para consulta
• Design pronto
• HTML pronto
• Dados para teste

Não precisamos seguir essa definição, mas é importante que tenhamos a nossa própria e todos saibam o significado dela.

Definição de completo/feito (DOD):

Isso é quando se pode dizer que completou uma tarefa.

Se deve ter uma definição clara de feito em toda sprint. Deve se testar o incremento feito? Deve existir testes autônomos? Usuários devem testar? Precisa passar por feedback? Até onde vai à funcionalidade? (Isso deve estar bem explicado no backlog e o scrum master deve garantir que todos compreenderam as tarefas).

Exemplos:

• Testes do programa feito
• Código revisado por outro membro do time
• Funcionalidades atende aos critérios de preparado

Rituais:

As vezes também é chamado de cerimonías, nada mais é do que os eventos do scrum que tem um tempo máximo, o refinamento do backlog (refinar as tarefas, backlog grooming) a fase de planejamento (planning), a curta reunião díaria (daily scrum, ou stand-up), review do que foi feito na sprint (sprint é o ciclo de desenvolvimento), retrospectiva (parte que vemos o que podemos fazer melhor na próxima sprint).

Sprint:

A sprint ou iteração é o ciclo de desenvolvimento com o objetivo de conquistar uma meta a partir de incrementos, o resultado deve ser um software utilizavel. Dura 14 dias.

A sprint deve continuar até o fim, mesmo se absolutamente tudo foi definido errado. Os erros devem ser discutidos na retrospectiva, retro. Se alguma tarefa da sprint não for terminada ela volta para o backlog.

Não se deve mudar o objetivo central da sprint e nem adicionar novas tarefas a ela, mas mudanças podem ser feitas e vão ser feitas, porque é intrínseco ao planejamento aparecer problemas inesperados, mudanças devem ser acordadas com o PO.

Daily:

Reunião de menos de 15 minutos realizada todos os dias de preferência no mesmo local e horário. O foco é ver se estamos progredindo para atingir a meta da sprint e resolver os problemas que impedem isso. Nas empresas normalmente é aqui que se mostra trabalho.

Perguntas comuns a serem feitas:

1. O que foi realizado desda última reunião?
2. O que é esperado atingir até a próxima reunião?
3. Quais são os seus impedimentos?

De forma alternativa às perguntas podemos fazer o “walk the board” onde passamos pelas tarefas do kanban board exemplo, eu estou responsável por essa história, já implementei uma das funcionalidades, é esperado que eu consiga terminar até hoje se eu conseguir resolver os problemas do banco de dados.

Nota:

Isso deve ser feito para ver como está o andamento do time e se alguém necessita de ajuda assim para como reconhecer o trabalho feito dos outros, é importante não se focar apenas em si mesmo. Sem conversa paralela, deve ser informal e no máximo 15 minutos.

Planning:

Essa faze serve para planejar o que devera ser feito na sprint, ou seja o sprint backlog, aqui se deve decidir o objetivo pelo PO, e estimar o tempo das tarefas trabalho dos devs já que eles que vão realizar o trabalho.

Estimando:

Essa é a primeira fase da planning, onde se deve atribuir quanto tempo ou pontos para uma tarefa.

Tipos de tempo:

Temos dois meios para quais podemos definir o tempo de uma tarefa, por pontos e por horas, por pontos seria um meio de comparação com as outras tarefas, normalmente os números utilizados são fibbonaci: 1, 2, 3, 5, 8, 13, 21, etc. A vantagem desse método é que humanos são ótimos em comparar coisas, mas péssimos em calcular prazos, porem fica mais difícil de explicar para outras pessoas fora da equipe a dificuldade de uma tarefa e nas primeiras sprints acaba sendo menos eficaz.

Como estimar bem:

É preferivel que o PO não participe da estimativa para não criar pressão sobre o time.

O time de desenvolvimento deve estimar o tempo de uma tarefa já que são eles que vão realiza-la, porém o scrum master deve auxilia-los no processo para garantir que estão pensando de forma realista e asseguralos de que é apenas uma estimativa, não é para ser perfeito.

Pegar duas história de tamanho médio (5 ou 8 pontos) para começar a estimativa é interessante. Escolher uma de fácil compreensão pelo time inteiro é bem importante. É bom lembrar que nem sempre o que é fácil para você será para mim.

planning poker:

Cada indivíduo precisa dar sua estimativa realista de qual pontuação terá, para que haja uma oportunidade de discutir as diferenças e depois fazer um acordo antes de se comprometer. A maioria dos analistas provavelmente concorda que isso na prática é simplesmente o caso de cada pessoa anotar sua pontuação prevista, 1, 2, 3, etc. em um cartão e depois revelá-la a seus colegas. No entanto, além desta sessão de planning poker, existem outras técnicas. É importante revelar ao mesmo tempo e não tentar persuadir os outros antes de revelarem suas pontuações.

Essa atividade é de suma importância porque vai definir o tempo do projeto e o PO necessita dessa estimativa para apresentar aos stakeholders e planejar o roadmap do produto.

O SM e PO não devem pressionar a equipe de desenvolvimento. Se for a primeira vez estimando ela será muito mais importante para as sprints posteriores do que a atual, já que da para ter um ideia melhor do tempo de uma tarefa.

Segunda estimativa:

A cada semana os pontos devem ser revisados e se possível dividir as tarefas e histórias em partes menores.

Para ter uma boa sprint se deve ter 3 critérios: objetivo, método e as métricas.

Objetivo:

Porque devemos realizar essa sprint? O que deve ser feito? Exemplo: observar os riscos, testar uma hipótese e efetuar funcionalidades. Importante para explicar o porque estamos fazendo essa sprint e motivar o time. Essa parte é papel do PO onde ele deve esclarecer todas as duvidas que a equipe de desenvolvimento tenha e explicar quais tarefas eles vão desenvolver.

Existe um acrônimo para criar metas efetivas: “SMART”

S – Specific (todos entendem o objetivo)
M – Mensurável (tem como saber se está pronto)
A – Alcançável (caiba no tempo de uma sprint)
R – Relevante (traz valor aos stakeholders)
T – Temporizado (tem tempo estimado)

Método:

Como realizaremos a tarefa? Deve se usar técnicas de validação? Por exemplo: teste de usabilidade, testes A/B (são experimentos realizados com o objetivo de comparar variáveis em estratégias de Marketing), protótipo e demo, para ter uma noção de como será o produto. Também pode ser decidido as tecnologias a serem utilizadas.

Métricas:

O que define que o objetivo foi alcançado? Por exemplo: pelo menos 5 usuários devem ser capaz completar os testes de forma bem sucedida em menos de 1 minuto.

Definindo o sprint backlog:

Está é a última faze da planning. Dependendo da complexidade do objetivo não será viavel completar em uma sprint, assim tendo que questionar o PO sobre os trade-offs e talvez mudar a definição de feito.

Definir quais histórias vão ser realizadas na sprint é muito importante que se tenha apenas tarefas que podem ser completadas no tamanho da sprint isso pode ser feito subdividindo as histórias em tarefas ou até mesmo as tarefas em tarefas menores.

É muito importante não pegar tarefas pensando: “Tudo bem se não completar essa.” Todas as tarefas do backlog da sprint deve ter o objetivo real de serem completadas e serem escolhidas de forma realista, o que pode ajudar com isso é: https://www.planningpoker.com/ para definir o tamanho das tarefas.

Limite WIP:

WIP significa trabalho em progresso e em algumas empresas tem um limite de tarefas que pode estar nessa sessão do kanban board.

Nota:

Não precisa de absolutamente tudo decidido na planning, a maior parte do como deve ser decidido pela equipe de desenvolvimento e não o SM e PO, ele deve apenas escutar e mentorear, nunca dar a palavra final. Também deve assegurar que não tem problema sair com algumas coisas não definidas e terá sempre adaptações.

Deve durar no máximo 4h.

Review:

É aqui que é mostrado o trabalho feito na sprint sendo convidado pessoas de fora para ver, stakeholders, pessoas que possam dar feedback, ou amigos. É importante não discutir o que deve ser melhorado aqui, já que existe a retrospectiva apenas para isso.

Deve durar no máximo 2h. Informal.

Retro:

Aqui é discutido o que deu errado e o que deu certo, o que será implementado na próxima sprint e o que deve ser abandonado em questão de métodos. O que intriga cada membro do time, o que cada um aprendeu. Quem mais te ajudou na última sprint, como você quer ajudar os outros.

É para ser uma refleção de como podemos melhorar para a próxima sprint ser melhor que a última.

Deve durar no máximo 2h.

Papeis:

Existem três trabalhos obrigatórios no scrum, o product owner (quem sabe como o produto deve ser, trabalho principal é o backlog), o scrum master (um coach onde papel é gerenciar o projeto e servir ao time de desenvolvimento), os devs (equipe de desenvolvimento, quem programa e dubla, adiciona informações dentro do produto se enquadra aqui, no tempo livre o SM pode se enquadrar também, mas não é o foco dele).

Outros papeis importantes, mas não essenciais são: Techlead (gerencia os desenvolvedores garantindo qualidade de código, minimizando o débito técnico e cuida dos processos de desenvolvimento, a parte do como, decide tecnologias e arquiteturas, também programa). QA (garantia de qualidade, testa os programas), devops (cuida da parte de infraestrutura, automatiza os processos de teste e garante que o servidor esteja funcionando) e o SME (experiente no assunto do tema, nosso caso um nútrologo ou nutricionista por exemplo).

Scrum master (SM):

Deve: organizar rituais (os métodos de scrum), resolver impedimentos, apaziguar as discussões, explicar como funciona o scrum, realizar métricas, ser um mentor, motivar o time, dando suporte a ele, priorizar o time às tarefas externas e entender os desejos do PO.

Não deve: ser a quem se reporta as tarefas feitas, quem toma as decisões e quem cobra o time.

Diarío do SM:

É muito importante o SM ter um díario onde ele anota observações e faz perguntas para tentar encontrar soluções para intervir ou decidir se pode continuar assim.

Intenvenção:

É uma ação tomada pelo SM, como conversar com o time sobre um tópico especifico que ele percebeu que não foi entendido corretamente ou apenas algo bom que eles estão fazendo e ele gostaria de saber mais. Para que a conversa seja boa é bom ser baseada em perguntas e não tenha culpado, todo o time tomou a decisão junto afinal.

Product owner (PO):

É quem deve garantir o maior aproveitamento do time, decidindo o objetivo, criando o roadmap e checando métricas. Também é quem conversa com os stakeholders (clarificando seus desejos e passando eles ao time), decide se algo está bom ou não, e constitui os desejos dos usuários no backlog.

Equipe de desenvolvimento:

Todos aqueles que realizam as tarefas do kanbann board. Seja um trabalho de design, implementar um software, dublar vídeos, ou redigir textos.

Sempre que tiver um impedimento ou precisar de ajuda pedir ao scrum master, tirar todas as dúvidas sobre metodologias scrum com ele e perguntar sobre o backlog para o PO se não entendeu alguma tarefa.

É quem decide como será realizada as tarefas do ponto de vista do desenvolvimento. Estima o tempo das tarefas.

Não pedir ajuda sem tentar fazer sozinho primeiro, mas não ficar batendo cabeça para sempre. Tem que saber o que irá dizer na daily. O google é seu melhor amigo.

Criar documentação dos produtos, revisar pull requests (solicitação para colocar o código no projeto, assim outro revisa seu código antes de coloca-lo) e fazer pair programming quando for mais eficaz (programar junto com outro dev).

Os valores do scrum:

Estes são os valores do scrum que devemos desenvolver com tempo para ter a maior produtividade.

Manifesto ágil:

Foi uma reunião feita entre os mais importantes gerentes de projetos, foi feita para decidir alguns elementos essenciais como:

1. Mais interação entre indivíduos do que processos e ferramentas.
2. Mais software em funcionamento do que documentação.
3. Colaboração entre o cliente acima de negociação e contrato.
4. Adaptabilidade é mais importante do que seguir um plano.

Apesar de todos esses serem impontantes os que estão a esquerda devem ser priorizados.

Outros principíos:

• Auto-organização da equipe (independencia do time)
• Composição da equipe (deve haver papeis bem delimitados)
• Feito significa feito (todos devem ter a mesma definição de feito)
• Product Owner Capacitado (tem que ter sua decisão respeitada)
• Scrum Master como Líder Servente (gerencia o time servindo os outros)
• Propriedade da equipe de se adaptar
• Entrega de valor (software útil para o usário final funcionando)

Incremento do produto:

Conforme descrito no Guia do Scrum, um Incremento é um trampolim concreto em direção ao Objetivo do Produto. Cada Incremento é aditivo a todos os Incrementos anteriores e verificado minuciosamente, garantindo que todos os Incrementos funcionem juntos. Para fornecer valor, o incremento deve ser utilizável.

Outros design patterns:

Design Patterns ou padrões de projetos são soluções generalistas para problemas recorrentes, uma especificação de como deve ser resolvido. Como a estrutura da história.

BDD:

Significa behavior driven development, é um meio de basear o desenvolvimento de histórias e códigos em comportamentos.

Exemplo:

Dado que estou na página de cadastro quando eu clicar no botão de cadastro e preencher a senha e email e confirmar a senha, então o sistema deve exibir uma mensagem no topo da tela: “Cadastro efetuado com sucesso” e redirecionar ele para a home. Segue essa estrutura, Dado que [ ] quando eu [ ] então [ ].

Como implementar na programação:

1. Foco em cenário;
2. Escreva a especificação para o cenário;
3. Escreva a especificação das unidades (naquele exemplo as unidade seriam o email e senha, já que se não preenchido corretamente mudaria o resultado);
4. Faça a especificação da unidade passar (atenda à todas as especificações, cenários e esteja de acordo com a definição de feito);
5. Refatore (reescreva o código de uma maneira melhor).

E quais os benefícios reais desta fusão Scrum e BDD?

• Evita-se erros de compreensão e interpretação das histórias de usuário;
• O que antes eram requisitos funcionais e requisitos não funcionais são transformados em comportamentos funcionais do software e critérios de aceitação;
• Fornece uma forma de comunicação (vocabulários) comum a todos envolvidos, facilitando a compreensão por parte de todos;
• A equipe fica ciente dos comportamentos que serão aceitos pelos usuários com antecedência;
• A equipe entende como os comportamentos são relacionados, evitando confusão;
• As reuniões de planejamento, revisão e diárias tornam-se mais eficazes.

Essa metodologia deve ser implementada no backlog e na programação, se não souber que resultado deve ter em outro caso da história por exemplo não preencher os campos da história pergunte ao PO.

TDD:

Você cria o teste do código antes do código em si, para fazer de maneira correta precisa seguir 5 etapas:

1. Escrever o teste antes da funcionalidade
2. Falhar no teste
3. Passar no teste
4. Refatorar o código, escrever tudo de novo de maneira otimizada.
5. Repete até estar de acordo com a métrica da tarefa (definição de feito)

Mais recursos:

Se quiser saber mais sobre scrum:

https://geekbot.com/blog/project-management-tools-that-every-scrum-master-should-use/

https://www.scrum.org/

é em inglês, leia e clique em todas as referências passadas para entender mais. Também recomendo o https://simpli-web.app.link/e/9588O7QB2nb, tem vários cursos gratuitos e com certificados, eles têm um de Agile Scrum Master que acabei fazendo e gostei bastante.

Mais sobre tdd, bdd, e ddd:

https://www.eduardopires.net.br/2012/06/ddd-tdd-bdd/

https://medium.com/cwi-software/domain-driven-design-do-início-ao-código-569b23cb3d47

Para saber mais sobre o trabalho do PO de modo interativo com um grupo:

https://medium.com/@sjoerdnijland/stakeholder-tycoon-4178eec63adf.

Onde fazer o backlog:

O mais usado é o jira, mas também tem o azure que é muito bom

https://azure.microsoft.com/en-us/services/devops/

https://start.atlassian.com/ jira

Uma alternativa ao Microsoft teams para organizar reuniões: https://www.gather.town/