Implementação do Scrum

Você aprenderá como criar e gerenciar um backlog do produto e desenvolver histórias de usuários e épicos. Você também explorará como configurar os cinco eventos importantes do Scrum e usar ferramentas para planejar e visualizar fluxos de trabalho e progresso do sprint.

Dedicação ao estudo

• Videos: 1h 15 min

• Leitura: 2h

• Teste: 3 Testes com avaliação

Objectivos

• Aplicar ferramentas de comunicação para ajudar a planejar e visualizar o fluxo de trabalho e o progresso do sprint.
• Desenvolver e detalhar histórias e épicos de usuários.
• Realizar o refinamento do backlog do produto de acordo com a estimativa de esforço, determinando o critério de aceitação e a priorização.
• Descrever a importância dos cinco eventos Scrum e como configurar cada evento para uma equipe Scrum.
• Explicar como desenvolver e gerenciar um backlog de produto.

Conteúdos

1. O backlog do produto
2. Eventos Scrum
3. Ferramentas Scrum
4. Revisão: Implementação do Scrum

1. O backlog do produto

Introdução: Implementação do Scrum

Video. Duração: 1 min

Na seção anterior, apresentamos o Scrum. Aprendemos sobre os valores do Scrum e explicamos as funções essenciais para todas as equipes Scrum.

Neste vídeo, completaremos nossa visão geral do Scrum e nos aprofundaremos na configuração e na execução do dia-a-dia de uma equipe Scrum. Vamos além do que é fornecido no Guia do Scrum oficial e compartilharemos ferramentas, métodos, dicas e truques mais populares para trabalhar com uma equipe Scrum.

Falarei como gerenciar seu backlog do produto, que contém características, requisitos e atividades associados às entregas para atingir a meta do projeto. Depois de ter um backlog, uma das partes mais complicadas do Scrum é a estimativa.

Aprenderemos o que tamanhos das camisetas e pontos de história têm a ver com o Scrum e falaremos de uma técnica chamada estimativa de esforço relativo.

A seguir, você aprenderá os cinco eventos importantes do Scrum:

• Sprint
• Planejamento do Sprint
• Daily Scrum (reuniões diárias)
• Revisão do Sprint
• Retrospectiva do Sprint.

Vamos aprender o que significa velocidade e como sua equipe pode usar ferramentas como gráficos de burndown para gerenciar o progresso.

Mostrarei algumas outras ferramentas úteis, como Google Docs, JIRA, Asana, Trello, quadros Kanban e muito mais, o que ajudará a manter seu fluxo de trabalho organizado e transparente.

Começaremos falando do backlog do produto, que é um artefato crítico para todas as equipes Scrum.

Construir um backlog do produto

Video. Duração: 5 min

Neste programa, apresentamos muitos artefatos de gerenciamento de projeto, como planos de projeto, declarações de trabalho, gráficos RACI e muito mais.

Agora, analisaremos um artefato importante da estrutura Scrum, o backlog do produto.

Backlog do produto é como única fonte autorizada para as coisas em que uma equipe trabalha. Ele contém todos os recursos, requisitos, e atividades associadas a entregas para alcançar a meta do projeto.

O equivalente no gerenciamento de projetos tradicional não Agile seria o conjunto de requisitos do projeto.

Existem três recursos principais de um backlog do produto:

1. O backlog do produto é um artefato vivo, o que significa que os itens são adicionados ao backlog a qualquer momento. O backlog do produto evolui durante o ciclo de vida do projeto e serve como um guia central para a equipe saber no que trabalhar a seguir.

2. O backlog do produto é de propriedade e ajustado pelo Proprietário do Produto.

3. O backlog do produto é sempre uma lista priorizada de recursos. Então, quando há novas informações ou novos recursos, eles são adicionados ao backlog em ordem de importância. Os itens no topo da lista são muito específicos e bem definidos, deixando os itens mais vagos para o final da lista.

Lembre-se, o backlog do produto é o guia e o roteiro do seu produto.

É o artefato central no Scrum, no qual todas as ideias, entregas, recursos, ou tarefas possíveis são capturadas para serem trabalhadas pela equipe. Porque o backlog é tão central, existem algumas práticas recomendadas e partes de dados que devem ser capturados ao trabalhar com backlogs de produtos.

• Descrição
• Valor
• Ordem
• Estimativa.

Vamos ver como construir um exemplo de backlog com essas práticas recomendadas em mente. Primeiro, há a descrição do item.

• A descrição do item é exatamente o que parece, ela descreve um item. Quando você está escrevendo uma descrição de item, é uma boa ideia ser muito claro ao adicionar itens de backlog de produtos, portanto, os detalhes são incentivados. Por exemplo, no novo projeto da Office Green, Virtual Verde, há um exemplo de descrição de um item: como cliente do Virtual Verde, pretendo aumentar minha seleção de vegetais enquanto trabalho em casa, em meu apartamento na cidade de Nova York. A descrição desse item inclui detalhes essenciais, como uma ação e um local do ponto de vista do cliente. Isso garante que a Equipe de Desenvolvimento tenha informações suficientes para atender às necessidades do usuário.

• O valor vem de seguida. Esse campo nos diz o valor de negócio que o item oferece para os clientes, para a equipe ou para os usuários. Como indicar o valor é uma escolha da equipe Scrum deveria fazer em conjunto. Eu gosto de definir valor usando cifrões, variando de um cifrão para baixo valor e aumentando até quatro cifrões para um alto valor de negócio agregado.

• A Estimativa é quanto esforço a equipe Scrum acredita ser necessário para a conclusão de um item. Vamos explorar como fazer uma estimativa de esforço relativo mais tarde. Por enquanto, é importante saber que a estimativa de esforço relativo é capturada em cada item do backlog. Esse campo no backlog é de propriedade da Equipe de Desenvolvimento.

• A Ordem é o próximo atributo de cada backlog. Como mencionamos, o backlog sempre deve ser priorizado. Os campos de estimativa e de valor sobre os quais acabamos de falar ajudam o Proprietário do Produto a descobrir onde colocar um item na hierarquia da ordem do backlog.

O Proprietário do Produto pode perguntar a si mesmo qual a importância desse item no backlog em comparação com todos os outros itens? Itens de ordem do backlog do produto da prioridade mais alta para a mais baixa. Isso é chamado de classificação empilhada. Ordenar itens dessa forma permite que as equipes para operem de forma mais eficiente.

Por exemplo, nossa equipe de pesquisa de mercado do Virtual Verde aprendeu que as pessoas que trabalham em casa preferem ter plantas que são fáceis de cuidar do que plantas de manutenção mais alta, como orquídeas. Em seguida, a equipe prioriza plantas simples e fáceis no backlog, como suculentas, acima das orquídeas. Então, as listas de backlogs de produto um: suculentas, dois: orquídeas.

Mas, digamos, por exemplo, que o suporte receba um e-mail de um usuário quem diz que adoraria ter árvores Bonsai, que também são difíceis de cuidar. Onde colocamos isso na ordem, antes das orquídeas ou depois? O Proprietário do Produto faz algumas pesquisas e decide que a equipe colocará orquídeas primeiro, porque acha que muitos mais usuários solicitaram orquídeas do que árvores Bonsai.

O Proprietário do Produto dá às orquídeas uma classificação de valor de dois cifrões, e para árvores Bonsai uma classificação de valor de um cifrão, e coloca árvores Bonsai no final da lista.

Ao criar itens de backlog, o objetivo é incluir o máximo que você puder sem se estressar demais com as incógnitas. Por exemplo, o Proprietário do Produto no Virtual Verde não sabe ainda quanto custam as árvores Bonsai, em comparação com suculentas, então, ele não sabe se elas atendem um mercado de alto custo ou de baixo custo. Ele documenta uma suposição na descrição da árvore Bonsai e avança. Ele poderá estudar isso com mais detalhes quando estiver em posição mais alta na lista de prioridades.

Agora você sabe um pouco mais sobre definição do backlog do produto e quem é o proprietário. Também vimos como atuam algumas das várias funções em relação ao backlog do produto e podemos identificar e descrever cada campo em um backlog de produto.

No próximo vídeo, aprenderemos como gerenciar o backlog, o que muda de acordo com as práticas do Scrum.

Backlog do produto: Visão geral do Guia do Scrum

Leitura. Duração: 10 min

Nesta lição, você verá um artefato importante do Scrum: o backlog do produto. Para recapitular, o backlog do produto é uma lista ordenada do que precisa ser feito para melhorar um produto. É a única fonte autorizada para itens em que a equipe Scrum trabalha. Durante o refinamento do backlog do produto, os itens são divididos e definidos com a adição de detalhes. Esses detalhes podem variar, mas geralmente incluem atributos como descrição, valor, ordem, estimativa e tamanho.

A meta do produto é o objetivo de longo prazo para a equipe Scrum e está incluída no backlog do produto. O restante do backlog do produto define quais tarefas cumprirão a meta do produto.

Para saber mais sobre o backlog do produto e a meta do produto, leia esta visão geral do Guia do Scrum 2020 (opens in a new tab)

Teste seu conhecimento: O backlog do produto

Quiz. 5 questões | Duração 8 min | Nota Final: 100%

Escrever histórias de usuários

Video. Duração: 6 min

No último vídeo, você aprendeu sobre um backlog de produto. Falamos que, para construir corretamente o backlog, o gerente de projeto deve considerar fatores como descrições, valor, ordem e estimativas. Isso garante que você, como gerente de projeto, incluirá informações suficientes para atender a visão do Proprietário do Produto para o valor do usuário.

Agora que você conhece os vários campos associado a cada item em seu backlog, vamos discutir uma maneira popular de capturar e gerenciar esses itens do backlog, histórias de usuários.

As histórias de usuários (user stories) são descrições curtas e simples de um recurso contadas do ponto de vista do usuário.

Isso ajuda a equipe a criar uma solução que seja sempre centrada no usuário e na experiência do usuário. As histórias de usuários podem começar grandes e amplas ou podem ser divididas para se tornarem tão pequenas e específicas quanto possível.

Nesta lição, vamos dar algumas ideias para escrever histórias de usuários e de como dividi-las.

As histórias de usuários são compostas por três elementos diferentes:

• o Usuário
• a Ação que ele tomará
• o Benefício para ele

Esses elementos podem ter alguns formatos diferentes, mas o mais comum é:

“Como papel do usuário, eu quero ação para que eu possa obter valor.”

Ao escrever histórias de usuários eficazes, a equipe deve ter um usuário em mente. Imagine que o usuário vai interagir com o produto para alcançar um resultado específico. O que eu realmente gosto de fazer nessa fase é criar personas ou descrições detalhadas dos meus diferentes usuários. Às vezes até lhes dou nomes. No Virtual Verde, pudemos dar aos nossos usuários alguns nomes e algumas informações sobre eles. Aqui estão algumas ideias de personas do usuário.

Leo é meu fornecedor de plantas, quem administra a aquisição das plantas, a cadeia de suprimentos e a logística de entrega.

Felicity é minha especialista em jardinagem, quem ajuda minha equipe de suporte a dar aos nossos clientes conselhos realmente excelentes sobre como cuidar de suas plantas.

Zach é meu jardineiro de hortaliças amador. Ele quer usar as plantas que compra para fazer o jantar.

Nia é minha consultora de gestão. Ela trabalha em casa e quer criar um cenário profissional para videoconferências em seu home office.

Reena é minha aficionada por flores, quem quer ter um arranjo de flores diferente cada semana para iluminar sua casa.

Ao dar a esses usuários um nome e uma história de fundo, podemos imaginá-los em nossas mentes, e isso nos permitirá projetar melhores produtos para eles como resultado.

Eu realmente gostei de escrever histórias de usuários, porque isso me coloca no lugar dos meus usuários. Cada história de usuário deve atender a seis critérios diferentes, representado pela sigla I.N.V.E.S.T. (do inglês).

• I para independente: a história deve ser capaz de ser iniciada e terminada por si mesma. Não depende de outra história para ter uma conclusão.

• N significa negociável: há espaço para negociação e discussão sobre o item.

• V é para valioso: isso significa que completar a história do usuário precisa agregar valor.

• E é para estimável: nossa Definição de Conclusão deve ser clara, para que a equipe pode dar uma estimativa a cada história de usuário.

• S é para simples: cada história de usuário precisa ser capaz de caber dentro de um Sprint planejado. Se a história de usuário for muito grande, ela deve ser dividida em histórias menores. Histórias que são de baixa prioridade no backlog podem permanecer grandes até que se tornem prioridade em um próximo Sprint. Finalmente,

• T é para testável: um teste pode ser escrito para verificar e garantir que ele atenda aos critérios de aceitação.

Enquanto o Proprietário do Produto é a pessoa principal responsável por escrever histórias de usuários, a equipe tem a responsabilidade de dar feedback sobre se a história do usuário é clara e se encaixa nos critérios de investimento antes de investir tempo nisso.

Além das histórias de usuários, você precisa conhecer o termo épico, que simplesmente representa um grupo ou coleção de histórias de usuários. Alguns épicos do Virtual Verde podem ser entrega de plantas vivas, serviço de aconselhamento sobre planta de escritório, gerenciamento de fornecedores ou gerenciamento de dados de clientes.

Vamos criar uma história de usuário de exemplo para nossos clientes do Virtual Verde no épico de entrega de plantas vivas.

Como cliente do Virtual Verde, gostaria de adquirir uma árvore Bonsai para ter uma bela planta e meditar enquanto aparo os galhos.

Pensei nisso porque comprei um Bonsai para meu sobrinho de 12 anos no ano passado. Ele fez algumas pesquisas e descobriu que no Japão a poda de árvores Bonsai é uma prática meditativa. Ele está aprendendo a fazer isso. Com essa história de usuário de exemplo, o Proprietário do Produto cria algo chamado de critérios de aceitação, que é essencialmente a lista de verificação que você usará para decidir se a história do usuário foi concluída.

Para ter uma história de usuário completa, você deve atender à lista de verificação de critérios de aceitação.

Aqui está um exemplo de critério de aceitação para a história do usuário da árvore Bonsai. Os usuários podem:

• Procurar três tipos diferentes de árvores Bonsai para comprar.

• Comparar as três árvores para saber qual é mais fácil e mais difícil de crescer em sua casa. Talvez cada planta tenha uma anotação de jardineiro iniciante, intermediário e avançado ao lado dela.

• Poder comprar pacotes específicos de cuidados com árvores Bonsai, como fertilizantes, tesouras de poda etc.

• Acessar online a um folheto sobre Bonsai, além de ter um livreto de cuidados enviado com a árvore.

• Poder encontrar uma solução de problemas de árvore Bonsai na página de perguntas frequentes do Virtual Verde.

Parece uma história incrível, não é? Parece uma coisa real com a qual um usuário pode interagir e se emocionar. Cada história de usuário no backlog deve ser escrita dessa forma. É natural que itens mais altos na lista de prioridades tenham mais detalhes e menos áreas cinzentas. Ao deixar esses itens de baixa prioridade vagos, isso economiza o tempo da equipe de trabalhar em itens que podem acabar ficando despriorizados no caminho. Fantástico.

Agora você sabe como explicar histórias de usuários, os critérios para avaliar a prontidão das histórias de usuários para a equipe e pode explicar critérios de aceitação de histórias de usuários e épicos.

No próximo vídeo, discutiremos o refinamento do backlog e explicaremos a estimativa de esforço relativo, tamanhos de camisetas e pontos de história.

Ler os componentes de histórias de usuários e épicos

Leitura. Duração: 10 min

No vídeo anterior, apresentamos histórias de usuários e épicos. Histórias de usuários são descrições curtas e simples de um material de entrega contado da perspectiva do usuário. A criação de histórias de usuários ajuda a equipe a desenvolver uma solução sempre centrada nas necessidades e na experiência geral do usuário.

Você também aprendeu que os épicos são uma coleção de histórias de usuários. Pense no conceito de histórias de usuários em termos de livros ou filmes. Uma história é uma única narrativa, enquanto um épico é um conjunto de várias histórias independentes relacionadas. Cada história conta uma crônica específica, enquanto um épico oferece uma visão de alto nível do arco geral.

Histórias de usuários

O fator determinante por trás de cada projeto Scrum é colocar o cliente em primeiro lugar. As histórias de usuários são um componente essencial para garantir que os clientes estejam satisfeitos com o produto. Uma equipe escreve uma história de usuário da perspectiva do usuário em potencial. As histórias de usuários não apenas fornecem insights sobre quais objetivos o usuário deseja alcançar, mas também permitem a colaboração, inspiram soluções criativas e criam impulso, dando à equipe uma pequena vitória quando as histórias são desenvolvidas.

Ao escrever histórias de usuários, você precisará incluir os seguintes componentes:

• Persona do usuário. Como é o seu usuário? Qual é a relação dele com o projeto? Que objetivos ele tem?

• Definição de Conclusão. Isso se refere a um conjunto acordado de itens que devem ser concluídos antes que uma história de usuário possa ser considerada completa.

• Tarefas. Quais são as principais atividades necessárias para completar a história do usuário?

• Qualquer feedback já fornecido. Se você estiver adicionando recursos a um produto existente e já tiver recebido feedback dos clientes em uma iteração anterior, considere esse feedback.

I.N.V.E.S.T.

Lembre-se de que suas histórias de usuário devem atender aos critérios I.N.V.E.S.T.:

• Independente: A conclusão da história não depende de outra história.

• Negociável: Há espaço para discussão sobre esse item.

• Valiosa: Completar a história do usuário precisa agregar valor.

• Estimável: A Definição de Conclusão deve ser clara para que a equipe possa fazer uma estimativa da história do usuário.

• Simples: Cada história de usuário precisa ser capaz de se encaixar em um Sprint planejado.

• Testável: Um teste pode ser realizado para verificar se ele atende aos critérios.

Vamos imaginar que você esteja trabalhando em um projeto para uma biblioteca local. A biblioteca espera lançar um site para que os clientes possam ler as resenhas antes de comprar os livros. O modelo típico para uma história de usuário é assim:

Como função de usuário, eu quero ação para que eu possa valor.

Portanto, um exemplo de história de usuário para essa situação poderia ser:Como ávido leitor, quero poder ler as resenhas antes de conferir um livro da minha unidade local para saber se receberei um livro no qual tenho interesse.

Épicos

O objetivo de um épico é ajudar a gerenciar histórias de usuários relacionadas. Nesta publicação , Mike Cohn, o inventor do termo “épico” para o Scrum, descreve épico como uma “história de usuário muito grande”, que não pôde ser entregue em uma única iteração e pode precisar ser dividida em histórias menores. A equipe deve discutir em conjunto e alcançar uma visão compartilhada de como escrever e capturar suas histórias de usuários e épicos. Lembre-se de que os épicos são apenas histórias de usuários maiores que estão lá para ajudar a organizar o projeto.

Vamos imaginar que você esteja criando histórias de usuários e épicos com base no exemplo anterior. As histórias de usuários podem incluir clientes que desejam ler resenhas de livros no site ou adicionar livros ao carrinho. Essas histórias de usuários podem cair no épico da “criação de sites”.

Outra história de usuário pode ser que os clientes queiram entrar na biblioteca e encontrar facilmente a seção de não ficção. Isso se enquadraria no épico da “organização do espaço físico”.

Então, em vez dessas várias histórias de usuários que aparecem juntas em uma lista, elas são organizadas em seções ou épicos.

É importante observar que, embora o Proprietário do Produto possa escrever histórias de usuários e épicos, um desenvolvedor também pode escrevê-los, desde que o Proprietário do Produto permaneça responsável pelo item backlog do produto.

Principal conclusão

Os épicos permitem que você acompanhe ideias grandes e pouco definidas, enquanto as histórias de usuários são uma unidade de trabalho muito menor, inspirada diretamente no usuário final ou no cliente. Tanto as histórias de usuários quanto os épicos ajudam as equipes a garantir que estejam agregando valor ao cliente.

Concluir a história do usuário/corresponder aos critérios de aceitação

Plugin. Duração: 15 min

Crie histórias de usuários e escolha os critérios de aceitação

Sua equipe Scrum está planejando um sprint para melhorar a experiência do usuário de um site de receitas. Depois de pesquisar os clientes, você ajudará a criar histórias de usuários e definir critérios de aceitação para atender às necessidades deles.

Complete a história do usuário

Revise a história do usuário e selecione a função do usuário, ação ou valor que melhor completa a declaração.

1. História do usuário

Como cozinheira doméstica, quero ____ para desperdiçar menos comida.

(Um cozinheiro doméstico que deseja reduzir o desperdício de alimentos se beneficiaria de receitas que usam ingredientes que ele já possui.)

Resposta 1

encontrar receitas de ingredientes que ja tenho

2. História do usuário

Como ____, quero encontrar receitas rápidas que meus filhos vão adorar para que eu possa passar mais tempo com minha família.

Resposta 2

pai ou mãe que trabalha

(Encontrar receitas rápidas e saborosas beneficiaria mais um pai ou uma mãe que trabalha e quer passar mais tempo com sua família).

3. História do usuário

Como cozinheira doméstica, quero fazer receitas com qualidade testada para que eu possa ____.

Resposta 3

ter certeza que deem certo

(Um cozinheiro doméstico que deseja que seus projetos deem certo se beneficiaria mais com receitas testadas com qualidade.)

4. História do usuário

Como cozinheiro iniciante, quero ____ para que eu possa ganhar confiança na cozinha.

Resposta 4

fazer receitas fáceis de seguir

(Um cozinheiro iniciante se beneficiaria mais de receitas fáceis de seguir que o ajude a desenvolver confiança e habilidade.)

II - Defina os critérios de aceitação

Agora que você criou as histórias dos usuários, selecione os critérios de aceitação para ajudar sua equipe a determinar uma Definição de conclusão.

5. História do usuário

Como cozinheira doméstica, quero encontrar receitas de ingredientes que já tenho para desperdiçar menos comida.

Resposta 5

Filtrar receitas por ingrediente e acessar um artigo relevante ajudará o cozinheiro caseiro a completar a história.

6. História do usuário

Como pai que trabalha, quero encontrar receitas rápidas que meus filhos vão adorar para que eu possa passar mais tempo com minha família.

Resposta 6

Pesquisar receitas por tempo de cozimento e navegar por refeições para crianças ajudará o pai ou a mãe que trabalha a completar a história.

7. História do usuário

Como cozinheiro iniciante, quero fazer receitas fáceis de seguir para que eu possa ganhar confiança na cozinha.

Resposta 7

Pesquisar receitas por tempo de cozimento e navegar por refeições para crianças ajudará o pai ou a mãe que trabalha a completar a história.

Atividade: Criar um backlog do produto

Até, Jul 2, 11:59 PM WEST | Quiz. | 5 questões | Duração: 30 min | Nota Final: 100%

Para acessar o modelo clique no link: Backlog do Produto (opens in a new tab)

Exemplo de atividade: Criar um backlog do produto

Leitura. Duração: 10 min

Veja aqui um exemplo completo com uma explicação sobre como ele atende às expectativas da atividade.

Exemplo completo

Para ver o exemplo deste item do curso, clique no link abaixo e selecione "Usar modelo".

Link para o exemplo: Backlog do produto (opens in a new tab)

OU

Caso você não tenha uma conta do Google, faça o download do anexo.

Avaliação do exemplo

Compare o exemplo com o plano de projeto que você criou. Analise seu trabalho usando cada um dos critérios presentes no exemplo. O que você fez bem? Em que é possível melhorar? Use suas respostas a essas perguntas como guia ao longo da realização do curso.

Observação: Suas histórias de usuários, títulos e critérios de aceitação serão diferentes em alguns aspectos daqueles abaixo. Tudo bem, o mais importante é que suas histórias de usuário sejam concisas, acionáveis e agreguem valor à função do usuário.

Vamos examinar o exemplo:

1 - Opções de baixa manutenção: A história do usuário segue a estrutura correta e atende aos critérios I.N.V.E.S.T.:“Como cliente em potencial, quero descobrir quais plantas são mais fáceis de cuidar para comprar opções de baixa manutenção.”Os critérios de aceitação permitem que os clientes classifiquem as plantas por dificuldade no site e descubram quais plantas têm necessidades de cuidados semelhantes.

2 - Dicas de cuidados com as plantas: A história do usuário segue a estrutura correta e atende aos critérios I.N.V.E.S.T.:“Como dono de planta, quero acessar instruções de cuidados facilmente para manter minha planta viva por mais tempo.”Os critérios de aceitação permitem que os clientes consultem um folheto de cuidados com as plantas e se inscrevam para receber e-mails mensais com dicas sazonais.

3 - Ferramentas de cuidados com as plantas: A história do usuário segue a estrutura correta e atende aos critérios I.N.V.E.S.T.:“Como dono de planta, quero ter as ferramentas certas para cuidar da minha planta para mantê-la saudável e bonita.”Os critérios de aceitação permitem que os clientes comprem kits iniciais para cuidados com as plantas ou comprem ferramentas individualmente.

4 - Lembretes de rega: A história do usuário segue a estrutura correta e atende aos critérios I.N.V.E.S.T.: “Como dono de planta, quero lembrar quando regar minhas plantas para não colocar água em excesso nem deixar faltar.”Os critérios de aceitação permitem que os clientes se inscrevam para receber lembretes de rega e comprar adesivos de lembrete para seus calendários.

5 - Ajuda e aconselhamento especializado: A história do usuário segue a estrutura correta e atende aos critérios I.N.V.E.S.T.:“Como dono de planta, quero obter ajuda especializada e conselhos rapidamente para saber o que fazer se minha planta ficar doente.”Os critérios de aceitação permitem que os clientes acessem o suporte por bate-papo ao vivo e liguem para o suporte por telefone durante horário estendido

6 - Política de devolução: A história do usuário segue a estrutura correta e atende aos critérios I.N.V.E.S.T.:“Como cliente, quero uma maneira sem problemas de devolver meu pedido, para ter certeza de que tenho a planta certa para mim.”Os critérios de aceitação permitem que os clientes encontrem facilmente informações de crédito e devolução no site e enviem suas devoluções com uma etiqueta pré-impressa.

Finalmente, como todas as histórias estão relacionadas a ajudar os clientes a cuidar de suas plantas, todas pertencem a um épico intitulado “Iniciativas de cuidado com as plantas”.

Aplique o que aprendeu usando o Asana:

Além das planilhas, muitas equipes Scrum usam ferramentas e softwares de gerenciamento de projetos mais avançados para gerenciar eventos Scrum e processos relacionados. Essas ferramentas podem ajudar você e sua equipe a se manterem organizados, economizar tempo e simplificar tarefas. Continue para o próximo item do curso (opens in a new tab) para saber como concluir essa atividade usando o Asana, uma ferramenta de gerenciamento de trabalho que ajuda as equipes a organizar o trabalho em um só lugar. Depois, em uma próxima atividade (opens in a new tab), você mesmo poderá aplicar o que aprendeu no Asana (opens in a new tab).

Muitas organizações adotam ferramentas de gerenciamento de trabalho semelhantes, portanto, familiarizar-se com as várias opções ajudará você a se preparar para o sucesso. Pronto para começar? Vá para o próximo item (opens in a new tab) do curso para começar.

Criar um backlog do produto no Asana

Video. Duração: 5 min

eu nome é Carla e faço parte da equipe de educação do cliente do Asana. Neste curso, tenho o prazer de mostrar algumas maneiras de otimizar o trabalho de sua equipe e maximizar sua produtividade usando o Asana para gerenciamento de trabalho. Trabalhadores de todos os setores perdem inúmeras horas com trabalho: o tempo perdido na busca de informações, alternando entre aplicativos e aguardando reuniões de status. Ferramentas de gerenciamento de trabalho como Asana são projetadas para reduzir perda de tempo ao capacitar os gerentes de projeto a se concentrarem no planejamento do projeto, no alinhamento da equipe e na alocação de recursos. Muitas organizações usam esses tipos de ferramenta para gerenciar tudo, de simples projetos com equipes pequenas a projetos complexos com várias partes interessadas. O que eu mais amo no Asana é que me dá total tranquilidade de que nada vai ficar de fora. Posso acompanhar todas as minhas próprias tarefas em um só lugar, e meus companheiros de equipe e eu sempre sabemos quem é responsável pelo quê e quando isso precisa ser feito. Eu vou aparecer ao longo deste curso para demonstrar atividades comuns de gerenciamento de projetos usando Asana. Neste vídeo, demonstrarei como construir o mesmo backlog do produto para o Virtual Verde que você acabou de criar. Desta vez, você usará projetos, tarefas, subtarefas e campos personalizados no Asana.

Vou mostrar um exemplo de cada etapa para que você saiba exatamente como é feito. Então, na atividade que segue, vamos apresentar uma visão geral detalhada e instruções de cada etapa, para que você mesmo possa experimentar no Asana. Tudo pronto? Vamos começar.

Antes de mais nada, vou entrar na minha conta do Asana.

Em seguida, criarei um projeto para meu backlog do produto

usando template .

como por exemplo o modelo de Planejamento do Sprint no Asana

O Asana tem muitos modelos úteis para todos os tipos de projeto, para que você possa explorar algumas outras opções por conta própria. Mas aqui vamos usar o modelo Sprint.

Em seguida, preencherei os detalhes do projeto. Neste caso, vou atualizar o nome para Virtual Verde e criar o projeto.

Não preciso atualizar mais nada para esta atividade, mas, se você quiser, pode selecionar opções para sua equipe.

Depois de criar o projeto, você irá para a visualização do quadro, onde poderá começar a adicionar detalhes do projeto.

A visualização do quadro pode ajudar a monitorar os planos de Sprint da equipe como em um quadro Kanban.

A maioria das equipes faz projetos no início de cada Sprint e depois monitora o trabalho em cada estágio, para garantir que sabe o ponto em que está o trabalho do Sprint. Neste modelo, esses estágios são representados por seções que aparecem como cabeçalhos de coluna na visualização do quadro.

Você notará que muitos dos modelos Asana, como este Planejamento do Sprint, tem tarefas já adicionadas. Para os propósitos desta demonstração, vou removê-las, mas você pode revisar por conta própria para saber mais sobre como usar este modelo.

Agora que criei meu projeto de backlog do produto, vou inserir títulos das histórias de usuário adicionando tarefas à coluna backlog para o projeto do Virtual Verde.

Meu primeiro título de história de usuário é "opções de baixa manutenção", depois, "ferramentas de cuidados com as plantas", e farei mais um, "ajuda e conselhos de especialistas".

Ótimo, tudo pronto. Aqui está minha lista completa de títulos de histórias de usuários.

Em seguida, adicionarei as histórias de usuários. Para fazer isso, precisarei abrir o painel detalhado da tarefa e atualizar a descrição da tarefa com a história.

Lembre-se de que criamos histórias de usuário na última atividade? Vou adicionar uma dessas como exemplo aqui em “descrição”.

Vou escolher esta história de usuário: Como cliente em potencial, quero descobrir quais plantas são mais fáceis de cuidar para comprar opções de baixa manutenção.

Em seguida, preciso adicionar critérios de aceitação para a história do usuário. Como você inseriu os títulos da história do usuário como tarefas, adicionará seus critérios de aceitação como subtarefas.

Para os primeiros critérios de aceitação, adicionarei: “capacidade de classificar plantas por iniciante, intermediário e avançado”. Para o próximo critério, "capacidade de procurar plantas com necessidades de cuidados semelhantes".

Quando terminar de adicionar subtarefas, fecharei o painel detalhado para acessar todas as tarefas no backlog.

Como uma dica rápida, posso expandir a lista de subtarefas e visualizar meus critérios de aceitação sem abrir o painel de detalhes.

E, por último, mas não menos importante, para esta atividade, vou adicionar um campo personalizado para o título do épico.

Os campos personalizados permitem adicionar detalhes adicionais às tarefas em um projeto. Você pode pensar neles como etiquetas ou colunas em uma planilha. Para esta atividade, escolherei um campo suspenso, usarei “épico” como título do campo e adicionarei "iniciativas de cuidado com as plantas" na primeira opção.

Só preciso de uma opção para esta atividade, então, vou excluir a opção dois. E terminei de criar o campo. Como todas essas histórias fazem parte do mesmo épico, posso atualizar o épico para todas as histórias de usuário de uma só vez.

Agora que adicionei todos esses detalhes do projeto,

posso verificar o cartão de tarefa concluído que me mostra os critérios de aceitação da história de usuário e do épico em um só lugar.

Ao terminar de adicionar os critérios de aceitação para todas as histórias de usuário, meu quadro do Asana aparece assim.

Criei com sucesso meu backlog do produto para o projeto do Virtual Verde. Agora é a sua vez. Vá para o próximo item do curso, onde você encontrará instruções detalhadas para concluir esta atividade no Asana. À medida que você avança no curso, terá a oportunidade de concluir mais ações de projeto no Asana. Em breve, compartilharei com você como usar o Asana nesses casos também.

Atividade: Criar um backlog do produto no Asana

Quiz. 1 questão | Duração: 30 min | Nota Final: 100%

Asana Guide (opens in a new tab)

Refinamento de backlog e estimativa de esforço

Video. Duração: 7 min

Bem-vindo de volta, estamos explorando tudo o que há para saber sobre um backlog de produto. Embora o proprietário do produto seja proprietário ou responsável pelos dados no Backlog, a equipe deve trabalhar em conjunto para manter o documento vivo atualizado.

Neste vídeo, discutiremos como fazer isso por meio de um processo chamado refinamento do backlog.

O Refinamento do backlog se refere ao ato de manter o backlog descrito, estimado e priorizado, para que a equipe Scrum possa operar de forma eficaz.

Após o proprietário do produto adicionar os itens do backlog com uma descrição e uma declaração de valor, ele faz o refinamento do Backlog.

É quando o Proprietário do Produto e alguns dos membros ou toda a equipe Scrum revisa o backlog para garantir:

• Que ele contém os itens apropriados e que nada de novo é necessário ou precisa ser removido,

• Que os itens sejam priorizados pelo Proprietário do Produto, (isso também é chamado de definir o camo ordem),

• Que os itens na parte superior do backlog está pronto para entrega, com critérios de aceitação claros,

• Que os itens do backlog incluem estimativas ou uma avaliação informada sobre a quantidade de trabalho para um determinado item do backlog.

Vamos discutir estimativas, pois são cruciais no refinamento do backlog. Adicionamos estimativas aos itens do Backlog para informar a nossas práticas de planejamento a quantidade de esforço que será necessária para terminar cada item ou história do usuário.

Com estimativas, podemos descobrir quanto trabalho temos pela frente.

Pode ser difícil estimar a quantidade de tempo necessária para concluir uma tarefa. Na maioria das vezes, nós, seres humanos, tendemos a subestimar o tempo para a conclusão. Quando se trata de grandes projetos, esse efeito pode ser multiplicado muitas vezes e pode ser a causa raiz de projetos atrasados e acima do orçamento.

Então, no Scrum, tentamos superar esse problema praticando estimativa relativa, em vez de estimativa absoluta.

A estimativa absoluta também é chamada de estimativa de tempo e esforço no gerenciamento de projetos tradicional.

A estimativa relativa significa que, em vez de tentar determinar exatamente quanto tempo uma tarefa levará, comparamos o esforço dessa tarefa ao esforço de outra tarefa, e isso se torna a estimativa.

Essa estimativa não é feita em unidades tradicionais de horas, dias ou semanas, em vez disso, atribuímos cada item do backlog de valor, que é uma unidade ou tamanho relativo.

Existem dois métodos comuns de estimativa relativa que considero mais úteis ao estimar histórias de usuários. Eles são: tamanhos de T-shirts e Pontos de história. Vamos começar com o mais simples dos dois:

• Tamanhos de T-shirts. Para começar, a equipe simplesmente escolhe um item no backlog que parece ser uma carga de trabalho de tamanho médio e chama isso de "médio" no campo de estimativa. Depois disso, eles pegam outro item no backlog e o comparam com o item médio que acabaram de identificar e respondem à pergunta: se esse primeiro item era médio, que tamanho eu daria para este? A equipe repetirá esse processo em cada item adicional ou história do usuário no backlog até que todos sejam endereçados e concluídos.

Por exemplo, vamos pegar quatro itens do backlog do produto do Virtual Verde:

• adicionar árvores Bonsai ao catálogo,

• criar um aplicativo móvel,

• lançar um novo logotipo e

• criar a nova página da conta.

A equipe decide que o lançamento de um novo logotipo é o seu “médio”. A equipe, em conjunto, compara os outros três itens com aquele item médio, o que lhes dá a estimativa de esforço relativo.

Outra forma de estimar histórias de usuários, tarefas e itens do backlog, é conhecido como pontos de história.

• Pontos de história são mais avançados do que Tamanhos de T-shirts, mas o conceito é semelhante. O primeiro passo é o mesmo: a equipe escolhe um item como âncora e realiza estimativas em relação a esse item. Em vez de usar Tamanhos de T-shirts, esse processo usa o que chamamos de pontos de história. A maioria das equipes usa uma famosa sequência matemática de números chamada sequência de Fibonacci. A sequência é 0,1,1,2,3,5,8,13, 21, e continua até o infinito. Por exemplo, para os pontos de história, pulamos zero e começamos com 1. Esses números são especiais porque começam próximos um do outro, mas, à medida que os números aumentam, eles se afastam cada vez mais.

Isso é útil, porque, à medida que a estimativa aumenta, a incerteza e o risco também aumentam. Esse número combina esforço e risco em um número. Em outras palavras, não há muito uso em debater valores de estimativa entre 21 e 25 pontos, mas escolher entre 21 e 34 é uma conversa real. Esse conceito pode ser complicado no início, e a prática é a melhor maneira de aprender para explicar este conceito. Nas aulas que dou no Google, usamos esse exemplo.

Digamos que você queira medir o esforço para consumir completamente diferentes tipos de fruta. Você tem na sua frente: uma laranja, um morango, uma banana, uma manga, um abacaxi e uma cereja. Quais são os fatores que entram nessa estimativa? Há sementes? Preciso comer com guardanapo? Posso comer em uma mordida? Tenho que descascar ou preciso de alguma ferramenta para preparar? Certo. Vamos tentar. Se eu escolher uma manga como nossa fruta inicial com cinco pontos, como você poderia estimar o resto? Eu as classificaria assim: Laranja é três, porque descascar é mais fácil do que cortar uma manga. Morango: um, porque não me preocupo com comer talos, baixo esforço. Banana: três, porque eu tenho que descascar, igual a laranja. Abacaxi: 13, porque é gigante, não consigo comer de uma só vez. Cereja: dois. Tem caules, sementes, você sabe o que quero dizer.

É muito divertido descobrir como as pessoas aprenderam a cortar um abacaxi de maneira diferente. Mas, mais importante, o que os exercícios de estimativa fazem para uma equipe é descobrir ótimas ideias sobre como fazer algo e trazer à tona as partes mais arriscadas do projeto. Por que gosto mais de pontos de história do que de Tamanhos de T-shirts? Vamos aplicá-los ao nosso backlog do Virtual Verde.

Agora, podemos ver que adicionar um novo usuário e adicionar árvores Bonsai ao nosso catálogo não são exatamente do mesmo tamanho, como os Tamanhos de T-shirts podem ter feito parecer. Usando pontos de história, um novo usuário vale oito pontos, e as árvores Bonsai valem 13. Por que eu os marcaria dessa maneira? Bem, implementar uma nova página de usuário é uma simples atualização de software. Adicionar árvores Bonsai é mais do que apenas software, inclui encontrar fornecedores, construir uma cadeia de suprimentos e muito mais.

Mencionei anteriormente que o refinamento do backlog, que inclui adicionar estimativas e atualizar o campo de ordem, deve ocorrer regularmente. Assim como cabe à equipe escolher qual método de estimativa selecionar, cabe à equipe decidir quando e com que frequência conduzir o refinamento do backlog. Algumas equipes preferem marcar reuniões especiais apenas para refinar o backlog. Outras simplesmente refinarão o backlog continuamente em conversas ou e-mails. E, finalmente, algumas equipes conduzirão o refinamento do backlog como parte de um evento agendado, como a reunião de Planejamento do Sprint.

Agora você sabe como definir o refinamento do backlog e pode explicar a estimativa de esforço relativa, Tamanhos de T-shirts e pontos de história.

No próximo vídeo, vamos aprender mais sobre Planejamento do Sprint.

Técnicas de estimativa de esforço Agile

Leitura. Duração: 10 min

Existem diversos tipos de técnica que podem ser usados ao estimar o esforço de forma Agile. A estimativa efetiva do esforço relativo leva a resultados de Sprint bem-sucedidos e previsíveis, o que leva a um projeto bem-sucedido em geral. De um modo geral, os principais passos para a estimativa Agile são os mesmos, mesmo que a abordagem específica varie. Alguns exemplos de técnicas de estimativa Agile são:

• Planning Poker™

• Votação de pontos

• O sistema Bucket

• Grande/incerto/pequeno

• Método de pedido

• Mapeamento de afinidade

Planning Poker™

Esse método específico é bem conhecido e comumente usado quando as equipes Scrum precisam fazer estimativas de esforço para um pequeno número de itens (abaixo de 10). O Planning Poker é baseado em consenso, o que significa que todos têm que concordar com o número escolhido. Nessa técnica, cada indivíduo tem um baralho de cartas com números da sequência de Fibonacci. Na sequência de Fibonacci, um número é a soma dos dois últimos números (por exemplo, 0, 1, 2, 3, 5, 8, 13 e assim por diante).

Às vezes, os baralhos do Planning Poker também incluem cartas com xícaras de café e pontos de interrogação. O cartão de ponto de interrogação significa que a pessoa não entende o que está sendo discutido ou não tem informações suficientes para tirar uma conclusão. O cartão da xícara de café significa que a pessoa precisa de uma pausa.

A estratégia de Planning Poker é usada nas reuniões de Planejamento do Sprint. À medida que cada item/história de usuário do backlog do produto é discutida, cada membro da equipe coloca um cartão virado para baixo na mesa. Então, todos entregam o cartão ao mesmo tempo, e a equipe discute as estimativas, principalmente quando estão distantes umas das outras. Ao ocultar primeiro as estimativas, o grupo evita qualquer viés apresentado quando os números são ditos em voz alta. Às vezes, ao ouvir números em voz alta, as pessoas reagem a essa estimativa ou ao próprio estimador, e isso muda o que seu pensamento inicial pode ter sido. No Planning Poker, as equipes podem facilmente evitar esse preconceito.

Votação de pontos

A Votação de pontos, como o Planning Poker, também é boa para sprints com um baixo número de itens de backlog do Sprint. Na Votação de pontos, cada membro da equipe começa com pequenos adesivos de pontos, codificados por cores pelo esforço estimado necessário (por exemplo, S = verde, M = azul, L = laranja, XL = vermelho). Os itens ou histórias de usuários são escritos em pedaços de papel colocados ao redor de uma mesa ou colocados na parede. Em seguida, os membros da equipe andam pela mesa e adicionam seus adesivos coloridos aos itens.

O sistema Bucket

O sistema Bucket é útil para backlogs com muitos itens, pois pode ser feito muito rapidamente. De fato, algumas centenas de itens podem ser estimados em apenas uma hora com o sistema Bucket. O sistema Bucket é uma estratégia eficaz para dimensionar itens porque explora cada item em termos de “baldes” pré-determinados de complexidade. Lembre-se de que esses baldes são metafóricos; essa estratégia não requer o uso de baldes reais e, em vez disso, usa notas adesivas ou cartões de notas como baldes.

Nesta técnica, a equipe começa configurando uma linha de cartões de nota no centro da mesa, cada um marcado com um número representando um nível de esforço. Em seguida, a equipe escreve cada item ou história do usuário em um cartão. Cada pessoa desenha e lê um item aleatório, depois o coloca em algum lugar ao longo da linha de cartões de nota numerados. Não há necessidade de discutir mais com a equipe. Se uma pessoa desenha um item que não entende, ela pode oferecê-lo a outra pessoa. Além disso, se uma pessoa encontrar um item que acha que não se encaixa onde foi colocado, pode discuti-lo com a equipe até que um consenso sobre um posicionamento mais preciso seja alcançado. Os membros da equipe não devem gastar mais de 120 segundos em cada item.

Grande/incerto/pequeno

Grande/incerto/pequeno é outro método rápido de estimativa aproximada. É ótimo para pendências de produtos que têm vários itens semelhantes ou comparáveis.

Essa é a mesma ideia geral do sistema Bucket, mas, em vez de vários intervalos, você usa apenas três categorias: grande, incerto e pequeno. Começando com as histórias de usuários mais simples e óbvias, a equipe coloca os itens em uma das categorias. Em seguida, a equipe discute e coloca itens mais complexos, até que cada um seja atribuído a uma categoria.

Método de pedido

O Método de pedido é ideal para projetos com uma equipe menor e um grande número de itens de backlog do produto. Primeiro, uma escala é preparada e os itens são colocados aleatoriamente, variando de baixo a alto. Então, um de cada vez, cada membro da equipe move qualquer item um ponto mais baixo ou mais para cima na escala ou passa sua vez. Isso continua até que os membros da equipe não queiram mais mover nenhum item.

Mapeamento de afinidade

O Mapeamento de afinidade é útil para equipes que têm mais de 20 itens no backlog de produtos.

Uma prática recomendada é conduzir essa técnica usando notas adesivas colocadas em uma parede, quadro branco ou mesa. Cada nota adesiva apresenta uma história ou item de usuário diferente. O uso de notas adesivas permite que a equipe mova histórias de usuários para agrupá-las por tema, grupo e padrão semelhantes. A equipe começa colocando uma nota adesiva no quadro. Em seguida, a equipe pega a próxima nota adesiva e discute se ela é semelhante ao primeiro item. Com base na avaliação da equipe, a segunda nota adesiva é colocada no primeiro grupo ou em seu próprio grupo.

Depois que todos os itens estiverem agrupados (deve haver de três a dez grupos no total), a equipe dá um nome a cada grupo que representa o tema geral dos itens. Em seguida, os grupos são priorizados pela importância, para que a equipe saiba quais itens abordar primeiro.

Características da estimativa efetiva

Independentemente da técnica escolhida pela sua equipe, existem várias características importantes que as técnicas compartilham que levam a uma estimativa eficaz:

• Evita a coleta de falsas precisões de estimativas.No Scrum, atribuir estimativas aproximadas resulta em mais precisão em todo o projeto. Portanto, se a equipe se concentrar em identificar estimativas relativas, em vez de uma equipe ter um longo debate sobre se uma tarefa levará sete ou dez dias de trabalho, a equipe economizará tempo e evitará prazos potencialmente perdidos.

• Evita o viés de ancoragem. Muitas dessas técnicas (por exemplo, Planning Poker) mantêm a estimativa inicial privada, o que permite que os membros da equipe formem uma opinião independente sobre a estimativa antes de compartilhar seus pensamentos com a equipe. Isso evita um fenômeno conhecido chamadoviés de ancoragem, em que os indivíduos se vêem compelidos a fazer estimativas semelhantes a outras na sala para evitar constrangimento.

• Promove a inclusão. Essas técnicas de estimativa de grupo não apenas levam a melhores estimativas, mas também ajudam a equipe a desenvolver confiança e coesão.

• Leva à descoberta de esforços. A estimativa dessas formas dinâmicas pode ajudar a equipe a descobrir estratégias para concluir itens que, de outra forma, não teriam sido revelados.

Principal conclusão

Existem várias estratégias para se alistar quando se trata de estimar o esforço e solicitar seu backlog do produto. Qualquer uma dessas técnicas é útil. Escolher uma estratégia específica é apenas uma questão do que sua equipe prefere.

Tamanhos de T-shirts e pontos de história

Leitura. Duração: 10 min

Nos vídeos anteriores, você aprendeu sobre tamanhos de camisetas e pontos de história, as duas unidades mais comuns usadas para ajudar as equipes a estimar histórias de usuários em projetos Agile.

Nesta leitura, exploraremos os processos de estimativa de histórias de usuários nessas unidades.

Para recapitular, a estimativa relativa significa comparar o esforço estimado para concluir um item do backlog com o esforço estimado para outro item do backlog. Fazer isso em vez de tentar determinar exatamente quanto tempo uma tarefa levará permite que suas comparações e estimativas sejam mais precisas umas em relação às outras.

Tamanhos das T-shirts

No início, os Tamanhos das T-shirts podem parecer uma maneira um tanto incomum de medir um item ou a história do usuário. Mas quando você pensa em atribuir estimativas a itens com base em tamanhos (por exemplo, XS, S, M, L, XL, XXL), é realmente muito útil e fácil. Alguns dos benefícios de usar essa técnica são que ela é rápida, bem compreendida pelos especialistas em Agile e uma boa introdução para equipes que estão apenas aprendendo estimativas relativas.

Então, o que implica o processo de atribuição de tamanhos de camisetas? Existem várias técnicas específicas que uma equipe pode tentar, mas cada uma geralmente segue essas etapas. A equipe:

• Concorda com a escala e as métricas escolhidas a serem usadas.

• Identifica pelo menos um item de backlog âncora. Esse item receberá um tamanho de camiseta. Algumas equipes escolherão dois itens âncora, um na parte superior do intervalo e outro na parte inferior do intervalo.

• Classifica os itens restantes da lista de pendências e concorda com os Tamanhos das T-shirts para cada um deles.

Pontos da história

Usar pontos da história como unidade de estimativa é um pouco mais avançado do que o tamanho das camisetas, mas é essencialmente o mesmo conceito. Esse método é bom para equipes experientes. Ao usar pontos da história, as equipes geralmente usam a sequência de Fibonacci. Como um lembrete, essa sequência vem da adição dos dois números anteriores na sequência juntos. Por exemplo, 1 + 2 = 3 e 2 + 3 = 5. O importante a notar sobre essa sequência é que, à medida que a lista continua, os números se distanciam um do outro. Por causa disso, os pontos da história fornecem mais precisão e especificidade do que os Tamanhos das T-shirts.

Então, o que implica o processo de atribuição de pontos da história? Existem várias técnicas específicas que uma equipe pode tentar, mas as etapas básicas são as mesmas dos tamanhos de camisetas. A equipe:

• Concorda com os valores de pontos permitidos. Algumas equipes limitam o tamanho em um determinado número, como 21. Algumas equipes decidem saltar de 21 para 100 como o próximo valor maior. Essa é uma decisão da equipe.

• Identifica pelo menos um item de backlog âncora e concorda em atribuir a ele um valor de pontos. Algumas equipes escolherão dois itens âncora, um na parte superior do intervalo e outro na parte inferior do intervalo.

• Classifica os itens restantes do backlog em conjunto, concorda com uma estimativa para cada item e a captura no sistema de gerenciamento de backlog.

Práticas recomendadas

Algumas práticas recomendadas, independentemente da técnica usada, incluem:

• Fazer perguntas ao Proprietário do Produto sobre a história ou o item do usuário para garantir que haja informações suficientes para estimá-lo.

• Discutir estimativas divergentes de vários membros da equipe para que todos tenham a chance de entender como implementar o item.

• Concordar com os tamanhos finais da camiseta ou o valor dos pontos e capturá-los no sistema.

• Se certos itens se enquadrarem no tamanho maior da camiseta ou no intervalo de valor dos pontos da história, discuta se faz sentido dividi-los em pedaços menores antes de avançar.

Principal conclusão

Qualquer uma dessas unidades de estimativa de esforço é eficaz para estimar seus itens e histórias de usuários. Como equipe, é importante gastar o tempo apropriado decidindo qual é o melhor para você. Se você é uma equipe menos experiente, tente começar com tamanhos de camisetas, mas as equipes mais avançadas devem se sentir à vontade para usar qualquer um dos métodos.

Atividade: Adicionar estimativa

Quiz. 3 questões | Duração: 30 min | Nota Final: 100%

Link do modelo: Adicionar Estimativa (opens in a new tab)

Exemplo de atividade: Adicionar estimativa

Leitura. Duração: 10 min

Link do modelo: Adicionar Estimativa conluído (opens in a new tab)

Caso você não tenha uma conta do Google, faça o download do exemplo diretamente pelo anexo:

Atividade exemplar: Adicionar estimativa concluido

Adicionar estimativas no Asana

Video. Duração: 3 min

Se você perdeu meu último vídeo, em que mostrei como criar um backlog no Asana, vá dar uma olhada. Neste vídeo, vou demonstrar como adicionar estimativas de esforço no Asana, assim como você fez na planilha do backlog do Virtual Verde.

Conduzirei você por um exemplo de cada etapa, para que você saiba exatamente como é feito.

Então, na atividade a seguir, vamos apresentar uma visão geral detalhada e instruções de cada etapa, para que você possa tentar realizá-las no Asana.

Desta vez, vou criar o projeto do Virtual Verde usando uma planilha existente, e a ferramenta de importador de CSV do Asana para inserir os detalhes do projeto.

Um arquivo CSV usa uma vírgula para separar valores. É daí que vem o nome CSV (Comma Separated Values).

Esse arquivo contém os dados de uma planilha. Assim, a ferramenta importador de CSV é uma ótima opção para mover seu fluxo de trabalho de um software de planilha, como Excel ou Planilhas Google, diretamente para o Asana.

Dessa forma, você pode começar imediatamente em qualquer projeto. Eu já baixei a Planilha de Estimativa de Acréscimo da última atividade como um arquivo CSV. Agora, vou carregá-la aqui.

Vou importar minha planilha, esse é o arquivo CSV.

Vou nomear o backlog do projeto do Virtual

Verde e selecionar um arquivo CSV para importar.

Quando a visualização aparecer, vou para o meu projeto.

Por padrão,o backlog aparece na exibição de lista.

O Asana gera automaticamente alguns campos personalizados para mim da planilha que eu estava usando. Épico, valor e estimativa. Vou adicionar estimativas de esforço aos campos vazios na coluna de estimativas.

Vou adicionar oito para opções de baixa manutenção, 13 para ferramentas de cuidados com as plantas e 8 para ajuda especializada e conselhos. Em seguida, classificarei as histórias de usuários. Dependendo de como você quer organizar as histórias em seu backlog, pode optar por classificar por qualquer um dos campos personalizados. Por enquanto, vou classificar por valor e salvar como padrão.

Agora que minhas histórias estão organizadas, vou mudar para a visualização de quadro para rever o backlog e salvar como minha visualização padrão.

A beleza de usar uma ferramenta como o Asana para gerenciar um backlog é a rapidez e a facilidade para converter seus planos em ação. Você pode dar a cada história do usuário um destinatário e uma data de validade, para deixar claro quem é responsável pelo quê e quando isso precisa ser feito.

Então, mantenha todos na mesma página publicando atualizações de status semanais e destacando realizações, progresso e bloqueios.

Agora é a sua vez. Vá para o próximo item do curso, onde você encontrará instruções detalhadas para concluir esta atividade no Asana. Em breve, compartilharei com você mais formas de usar o Asana para ajudar a gerenciar seus projetos.

Atividade: Adicionar estimativas no Asana

Quiz. 1 questão | Duração: 30 min | Nota Final: 100%

2. Eventos Scrum

Introdução ao Sprint

Video. Duração: 3 min

Como você já viu, Sprints, que também chamamos de iterações, fornecem todo o ritmo para a equipe e são um dos cinco eventos Scrum. Eles nos permitem obter feedback mais rápido, incentivar a colaboração em equipe e fornecer mais foco para as equipes Scrum.

Dentro de um Sprint, a quantidade de trabalho é planejada com base na capacidade histórica da equipe e é preparada para o evento de Planejamento do Sprint.

Pode ser mais fácil pensar em cada Sprint como um miniprojeto com planejamento, execução, entrega, fechamento e uma retrospectiva toda embrulhada um pequeno pacote.

Sprints são tão importantes para o Scrum que os outros quatro eventos Scrum giram em torno do Sprint.

O Guia do Scrum

O Guia do Scrum define tecnicamente cinco eventos:

• O Sprint
• Planejamento do Sprint
• Daily Scrum (reuniões diárias)
• Revisão do Sprint
• Retrospectiva do Sprint

Nesta seção de vídeos, vou compartilhar qual é a duração recomendada, ou período de tempo, para cada um desses eventos.

Períodos de Tempo (Timeboxes)

Períodos de tempo são um conceito importante no Scrum. Alguns exemplos de benefícios são:

• Criam um senso de urgência que impulsionará a priorização

• Fornecem uma janela de foco para melhorar a produtividade

• Ajudam a equipe a desenvolver um ritmo previsível de trabalho.

O período de tempo de um Sprint pode variar de uma a quatro semanas. Como você escolhe? Bem, há três considerações.

1. Primeiro, pense qual é a frequência de mudanças esperada. Com que frequência você acha que seus requisitos podem mudar? Se você espera que seu projeto tenha novas solicitações a cada semana, pode querer que a duração do Sprint seja uma semana, para se adaptar com mais frequência. Se as necessidades forem mais estáveis, talvez um tempo maior possa estar bem.

2. Em segundo lugar, pense em quanto tempo de foco seus desenvolvedores de soluções podem precisar para construir um item de backlog. Se o esforço de linha de base para a maioria das atividades requerem pelo menos uma semana para a criação de algo valioso, então a duração do Sprint deve ser de pelo menos duas semanas, para dar tempo de execução à equipe sem que ela sinta que precisa fazer hora extra.

3. Terceiro, pense na sobrecarga envolvida na entrega do seu produto. Se a entrega ou solução requer uma grande revisão, com muitas partes interessadas, ou passa por um rigoroso teste processo de garantia de qualidade que leva vários dias, você deve levar isso em consideração na duração do Sprint e escolher um Sprint mais longo, como três ou quatro semanas.

Como a maioria das coisas no Scrum, não existe uma abordagem única. Se você definir uma duração do Sprint e decidir que é muito longa ou muito curta após alguns Sprints, poderá sempre fazer alterações.

Por exemplo, minha equipe atual tem Sprints que duram uma semana, porque esperamos muitas mudanças e a chegada de novas solicitações ao nosso backlog toda semana, mas, muitas vezes, nosso trabalho leva mais de uma semana para ser concluído. Estamos refletindo sobre essa contradição e considerando mudar a duração do Sprint para duas semanas. Excelente.

Agora você sabe mais sobre como definir o Sprint. Nos próximos vídeos, falaremos da relação entre os outros eventos Scrum e o Sprint. Começaremos com os eventos que antecedem o Sprint, realizar o Planejamento do Sprint e compilar o backlog do Sprint.

O Sprint: Visão geral do Guia do Scrum

Leitura. Duração: 10 min

Para recapitular, leia esta visão geral do Sprint tirada diretamente do Guia do Scrum 2020 (opens in a new tab)

O Sprint

Sprints são o coração do Scrum, onde as ideias são transformadas em valor.

São eventos de duração fixa de um mês ou menos para criar consistência. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior.

Todo o trabalho necessário para atingir a Meta do Produto, incluindo Planejamento do Sprint, Daily Scrums (reuniões diárias), Revisão do Sprint e Retrospectiva do Sprint, acontece dentro dos Sprints.

Durante o Sprint:

• Nenhuma mudança é feita que possa colocar em risco a Meta do Sprint;

• A qualidade não diminui;

• O backlog do produto é refinado conforme necessário; e

• O escopo pode ser esclarecido e renegociado com o Proprietário do Produto à medida que mais é aprendido.

Sprints permitem a previsibilidade, garantindo a inspeção e a adaptação do progresso em direção a uma meta de produto pelo menos mensalmente. Quando o horizonte de um Sprint é muito longo, a Meta do Sprint pode se tornar inválida e a complexidade e o risco podem aumentar. Sprints mais curtos podem ser empregados para gerar mais ciclos de aprendizado e limitar o risco de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado um projeto curto.

Existem várias práticas para prever o progresso, como burn-downs, burn-ups ou fluxos cumulativos. Embora comprovadamente úteis, eles não substituem a importância do empirismo. Em ambientes complexos, não se sabe o que acontecerá. Somente o que já aconteceu pode ser usado para a tomada de decisões prospectivas.

Um Sprint pode ser cancelado se a meta do sprint se tornar obsoleta. Somente o Proprietário do Produto tem autoridade para cancelar o Sprint.

Teste seu conhecimento: O Sprint

Quiz. 4 questões | Duração: 8 min | Nota Final: 100%

Planejamento do Sprint

Video. Duração: 4 min

No último vídeo, falamos dos parâmetros de um Sprint. Aprendemos que um Sprint é um dos cinco eventos Scrum e cria o quadro em torno de todos os outros eventos Scrum.

O próximo passo é o Planejamento do Sprint, o primeiro evento do Sprint, que prepara sua equipe para o sucesso nas próximas uma a quatro semanas, dependendo da duração que você escolheu.

Planeamento do Sprint (Sprint Planning)

Para o Planejamento do Sprint, toda a equipe Scrum se reúne para confirmar a capacidade, ou seja, quanto tempo e quantas pessoas, estão disponíveis durante o Sprint, e, em seguida, identifica quais itens do backlog serão realizados durante o Sprint. Isso se torna o backlog do Sprint, e, finalmente, a meta do Sprint.

Esse é o momento em que o Scrum Master facilita a comunicação da equipe e responde às seguintes perguntas ao longo do evento:

• Quem está disponível durante o Sprint?

• Existem férias ou conflitos que devamos saber?

• Qual foi a nossa velocidade média, ou seja, quantos pontos ou itens do backlog conseguimos concluir em um único Sprint no passado?

• O que pode e deve ser realizado pela equipe no próximo Sprint?

• Qual é a meta final do Sprint? Como o trabalho será feito?

• Ao longo do Sprint, quem é responsável por quais tarefas?

Falamos da duração dos Sprints e dos tamanhos das histórias. Então, vamos explorar o significado de Definição de Conclusão.

Definição de Conclusão (Definition of done)

Definição de Conclusão se refere a um conjunto acordado de itens que devem ser concluídos antes que a história de usuário ou item do backlog seja considerado completo.

Algumas coisas que podem estar na sua Definição de Conclusão são:

• A revisão do código ou da solução por um grupo independente de pares.

• O produto ou unidade passa por todos os requisitos de teste, que podem incluir testes de segurança ou desempenho.

• A documentação está concluída.

• Todos os critérios de aceitação da história do usuário especificados pelo proprietário do produto são atendidos.

• O proprietário do produto aceita a história do usuário.

Essa lista não é abrangente, e a equipe deve determinar o que deve estar nessa lista e melhorá-la conforme necessário. Uma das principais entregas do evento Planejamento do Sprint é o backlog do Sprint.

Backlog do Sprint (Sprint Backlog)

O backlog do Sprint é o conjunto de itens do backlog do produto identificados para a serem concluídos no próximo Sprint. Em outras palavras, o backlog do Sprint é um subconjunto de itens do backlog do produto que você pretende terminar durante esse Sprint específico.

Por exemplo, o backlog do produto do Virtual Verde pode ter 50 itens de backlog, e o Virtual Verde criou Sprints de quatro semanas que são nomeados por mês: Sprint de maio, Sprint de junho, Sprint de julho e assim por diante. Para o Sprint de maio, a equipe determinou que pode concluir os cinco principais desses itens, com base na capacidade da equipe para maio e no tamanho do esforço desses itens.

Esses cinco itens agora compõem o backlog do Sprint. A meta do Sprint é o objetivo abrangente que a equipe pretende alcançar e ajuda a equipe a entender o porquê do Sprint. Isso deve ser feito a partir de uma visão geral dos itens no backlog do Sprint.

O benefício de ter uma Meta do Sprint maior identificada é que ajuda a equipe a se concentrar em um objetivo de equipe mais amplo, em vez de colocá-los em fluxos de trabalho separados.

Sprint Backlog

Por exemplo, digamos que o Virtual Verde tenha identificado esses cinco itens como o backlog do Sprint de maio:

• Os usuários do Virtual Verde podem comprar árvores Bonsai.

• Eles também podem acessar um fórum de discussão online sobre decoração de home office.

• A equipe de gerenciamento de fornecedores pode adicionar resultados de auditoria para fornecedores.

• Os usuários do Virtual Verde podem usar um cupom para comprar acessórios de home office.

• O suporte ao cliente do Virtual Verde pode conectar produtos a tíquetes de suporte.

Assim, o objetivo do Sprint é fornecer uma experiência abrangente ao usuário que deseja ter uma árvore Bonsai em seu home office. Todos esses itens do backlog podem ser conectados a esse objetivo do Sprint de alguma forma. Por exemplo, há um novo cupom para Bonsai, os fornecedores são auditados para a qualidade da árvore Bonsai e assim por diante.

Para recapitular, acabamos de saber que Planejamento do Sprint resultará em um backlog do Sprint estimado e bem definido, além de uma meta do Sprint para manter a equipe motivada para a conquista final.

Vejo você no próximo vídeo, em que abordaremos mais eventos de Sprint.

Criar um Planejamento do Sprint e Backlog do Sprint

Até, Jul 2, 11:59 PM WEST | Teste de Avaliação. | Duração: 1 h | Nota Final: 100%

Link: PGA-Planeamento do Sprint e Backlog do Sprint (opens in a new tab)

Criar um Planejamento do Sprint e Backlog do Sprint

Até, Jul 5, 11:59 PM WEST | Avaliar Colegas | Duração: 1 h | Nota Final: 100%

• Avaliou 3 colegas

Criar e gerenciar Sprints no Asana

Video. Duração: 3 min

Se você perdeu meus dois últimos vídeos, nos quais mostrei como criar um backlog e adicionar estimativas no Asana, vá dar uma olhada neles.

Neste vídeo, vou demonstrar como criar e gerenciar Sprints no Asana. Vou conduzir você por um exemplo de cada etapa, para que você saiba exatamente como isso é feito.

Ao planejar Sprints no Asana, as equipes podem ter total clareza sobre os planos do Sprint, marcos, datas de lançamento e backlog, com esforços de trabalho e comunicação em um só lugar.

Então, na atividade a seguir, vamos apresentar instruções detalhadas para você tentar por conta própria.

Vou começar abrindo o backlog do Virtual Verde que criei na atividade anterior,

Adicionar estimativas no Asana.

Nesta atividade, vamos priorizar e agendar cada item no backlog para um próximo Sprint. Adicionarei um campo personalizado para Sprints, o que me permitirá encontrar facilmente para qual Sprint cada tarefa está agendada.

Adicionarei “Sprint” ao título do campo e confirmarei o tipo de campo como suspenso.

Em seguida, alterarei a opção 1 para “Sprint Atual” e opção 2 para “Próximo Sprint”.

Agora, vou atribuir itens para o backlog do Sprint para os dois primeiros Sprints. Para esta etapa, recomendo mudar para a visualização de lista, pois é mais fácil ver todas as suas tarefas de uma só vez.

Atribuirei itens ao Sprint atual ou ao próximo Sprint usando as listas suspensas na coluna Sprint.

E então vou reordenar o projeto por Sprint, para agrupar meus itens do Sprint juntos.

Por padrão, o Asana classificará minhas tarefas nas seções que eu criei.

Se eu desativar a classificação em seções, verei minhas tarefas agrupadas pelo campo personalizado que estou usando para classificar.

Nesse caso, por Sprint.

Também verei a soma de qualquer campo personalizado numérico na parte inferior de cada grupo.

Isso torna mais fácil acompanhar quantos pontos eu atribuí a cada Sprint. Então, eu me certifico de não exceder a capacidade da minha equipe.

E, finalmente, adicionarei datas de vencimento para cada tarefa.

uma seguida de outra.

Você pode fazer muito mais com o Planejamento da Sprint no Asana! Pode personalizar os detalhes do seu projeto, planejar o Sprint com uma linha do tempo, gerenciar cargas de trabalho do Sprint e monitorar o progresso do projeto do Sprint.

O Planejamento do Sprint é apenas uma das formas como a Asana pode ajudar você a gerenciar projetos e tarefas de equipe. Desde atingir metas e prazos até acompanhar o progresso e a solução de problemas, automatizando e simplificando seu trabalho e vinculando todos os seus fluxos de trabalho em um só lugar, O Asana tem muitos recursos para garantir que todos os projetos estejam preparados para o sucesso.

Agora é a sua vez. Vá para o próximo item do curso, em que encontrará instruções detalhadas para concluir essa atividade no Asana por conta própria.

Atividade: Criar e gerenciar Sprints no Asana

Quiz. 1 questão | Duração: 30 min | Nota Final: 100%

A reunião diária e a Revisão do Sprint

Video. Duração: 5 min

Como já vimos, um dos princípios do manifesto Agile diz: os métodos mais eficientes e eficazes de transmitir informações em e para uma Equipe de Desenvolvimento é a conversa cara a cara. Então, neste vídeo, falaremos da comunicação com a equipe por meio de dois tipos de evento pessoais que ocorrem durante e após o Sprint, Daily Scrum (reuniões diárias) e Revisão do Sprint.

Daily Scrum

O Daily Scrum, às vezes chamados de reunião curta, é um momento para a equipe Scrum sincronizar e priorizar as atividades do dia.

Em 15 minutos, e nos mesmos horário e lugar todos os dias, cada membro da equipe responde às seguintes perguntas:

• O que eu fiz ontem que ajudou a equipe a atingir a meta do Sprint?

• O que farei hoje para ajudar a equipe de Desenvolvimento a atingir a meta do Sprint?

• Eu notei algum impedimento que faz com que eu ou a Equipe de Desenvolvimento não possa cumprir nossas metas?

Reuniões breves diárias devem dar ao Scrum Master a oportunidade de desbloquear a equipe rapidamente, com pouco atraso. E as reuniões curtas diárias são uma oportunidade de reforçar o foco no backlog do Sprint e na meta do Sprint. O Guia do Scrum oficial diz que reuniões curtas diárias devem acontecer todos os dias, embora eu deva dizer que tive equipes Scrum de sucesso que se encontravam com menos frequência. Minha equipe Scrum atual tem um Sprint de uma semana, e temos reuniões curtas duas vezes por semana. Descobrimos que isso funciona muito bem para nós. Experimente e veja o que funciona melhor para sua equipe.

No encerramento de um Sprint, a equipe vai completar outro evento, conhecido como Revisão Sprint. Esse evento do Sprint é crucial para os pilares Scrum de inspeção e adaptação, e demonstra os valores de abertura, coragem e respeito. Vamos discutir o que quero dizer com isso.

Revisão do Sprint

A Revisão do Sprint é uma reunião com toda a Equipe Scrum na qual o produto é demonstrados a fim de determinar quais aspectos estão concluídos e quais não estão.

Durante uma Revisão do Sprint, a Equipe de Desenvolvimento e o Proprietário do Produto desempenharão um papel pesado na inspeção e discussão.

• Eles também deverão explorar quais itens devem ser considerados concluídos no backlog do produto

• E demonstrar e inspecionar o produto.

Revisões do Sprint devem ser muito divertidas e edificantes. A Revisão do Sprint é quando a equipe começa a se impressionar com as coisas legais que realizou nas últimas uma a quatro semanas. Essas reuniões de equipe fechadas não devem exceder quatro horas e são uma boa oportunidade para a equipe praticar os valores Scrum de abertura e respeito, à medida que todos dão feedback sobre o trabalho concluído.

Muitas vezes, algumas das melhores ideias de produto saem de Revisões de Sprint. Vamos ver um exemplo Com o novo serviço, a equipe do Virtual Verde precisa lançar sua nova página do site, mostrando plantas de home office. Vamos imaginar que a equipe Scrum tem um especialista em marketing. Lembre-se de que as equipes Scrum são multifuncionais. Durante a reunião de Revisão do Sprint de agosto, um dos itens do backlog do Sprint foi criar um e-mail de lançamento para enviar aos atuais clientes corporativos da Plant Pals sobre a nova aventura da marca.

Durante a reunião de Revisão do Sprint, a equipe recebe uma demonstração do e-mail. Ela puxam o e-mail na tela compartilhada e dá o feedback de especialista ali mesmo na reunião, como: Eu amo essa linha de abertura ela é realmente atraente; vamos aumentar a imagem de abertura; podemos tornar mais fácil para o destinatário encaminhar isso para seus amigos; podemos encurtar esse texto? Está um pouco longo. Essa inspeção em grupo de um produto de trabalho da equipe tem muitos benefícios, que vão muito além de apenas um melhor e-mail de marketing.

1. Primeiro, ela torna o feedback o mais imediato possível. Não há necessidade de esperar que as pessoas revisem sozinhas e enviem o seu feedback depois. Feedback e ajustes podem ser feito ali na reunião.

2. Em segundo lugar, todo mundo tem voz, levando a um senso de propriedade compartilhada em todos os aspectos do lançamento do produto.

3. Por último, mas não menos importante, a equipe aprende mais sobre como o marketing faz seu trabalho, levando a uma maior confiança e compreensão entre os membros da equipe.

A Revisão do Sprint é um momento para a equipe demonstrar o que realizou. É na Revisão do Sprint que membros da equipe revelam o que é chamado de Incremento do Produto.

Incremento do Produto

O Incremento do Produto é o que é produzido após um determinado Sprint e é considerado pronto para ser liberado.

Um produto está pronto para ser liberado quando a equipe desenvolveu um Produto Mínimo Viável, que tem um conjunto de recursos ou requisitos implementados.

Produto Mínimo Viável

Um Produto Mínimo Viável é uma versão de um produto com recursos suficientes para satisfazer os primeiros clientes.

No final de cada Sprint, apenas itens que atendem a Definição de Conclusão são considerados parte do Incremento do Produto. Qualquer coisa que não está concluída volta ao backlog do produto.

Ótimo trabalho. Nós já abordamos as atividades que acontecem durante um Sprint para garantir que a equipe esteja focada e construindo soluções valiosas.

No próximo vídeo, falaremos de outra reunião importante que ocorre em uma equipe Scrum: a Retrospectiva do Sprint.

Sarah: Os benefícios de uma reunião breve diária

Video. Duração: 2 min

Eu sou Sarah, e eu sou gerente de programa, na Equipe de educação em engenharia do Google. Um modo que uso para centralizar e organizar que eu acho que não é falado com tanta regularidade quanto a documentação é ter uma reunião curta diária ou stand up ou uma reunião curta semanal com sua equipe de projeto multifuncional. Às vezes, como gerente de projeto, você está inclinado a dizer: “Bem, nosso analista de dados pode não precisar saber o que o profissional de marketing está fazendo porque são coisas bem diferentes”. Mas, honestamente, dar a todos a oportunidade de entrar em uma reunião semana após semana e apenas falar rapidamente: “Isso é o que eu acabei de terminar. É nisso que estou trabalhando”, cria uma certa visibilidade, transparência e uma sensação de camaradagem e trabalho em equipe de uma forma que apenas documentar tudo isso sem ter uma conversa sobre isso realmente não resolve. A meta de uma reunião curta não é ser apenas algo em uma retrospectiva ou como uma audiência. Elas devem ser o mais curtas possível. Eu costumo agendar 15 a 20 minutos, e fico feliz se são mais curtas. Nós realmente queremos que as pessoas passem rapidamente o que estão trabalhando no momento e, se tiverem algum bloqueio, qualquer coisa que possa estar atrapalhando um colega de equipe ou projeto específico, parte do projeto e o progresso, então você pode precisar estabelecer um tempo adicional com essa pessoa específica ou proprietário do fluxo de trabalho para realizar essas tarefas e ver o que você pode fazer para ajudar a desbloqueá-las. Outra coisa a considerar em uma reunião curta diária é que você provavelmente deverá trabalhar com pessoas em vários fusos horários diferentes, muitos locais diferentes. Minha recomendação é enviar uma verificação ou pesquisa como: "Tudo bem para você fazer às 11h ET? "Tudo bem para você se for às 16h ET?”, e, em seguida, manter isso para se certificar de que seja um consenso antes de você colocar no calendário e esperar que todo mundo apareça todas as vezes. Quando você trabalha em um projeto, com um prazo muito apertado, e está fazendo uma reunião curta todos os dias, tento não criar uma cultura em que é obrigatório que todos estejam presentes. Isso acontece todos os dias, e pode haver alguns componentes e um orçamento de projeto que se movem mais rápido em alguns momentos do que outros. Uma ótima maneira de manter as pessoas no período de tempo em uma reunião curta diária ou qualquer tipo de reunião é, antes da reunião, criar uma agenda e realmente escrever ao lado dela quantos minutos você espera alocar para qualquer atualização que seja. Mas, se algo acontecer, eu geralmente tento dizer: não os corte no meio da frase. Nunca é uma boa maneira de trabalhar com as partes interessadas ou com sua equipe de projeto dizendo: “Dois minutos se passaram, seu tempo acabou”. Mas apenas diga em algum momento, quando houver uma pausa natural na conversa: “Ei, nós realmente precisamos dar mais 10 a 15 minutos a essa outra coisa, então, vamos fazer uma pausa e voltaremos a isso se tivermos tempo mais tarde e, caso contrário, na próxima reunião?”

Incremento liberável versus produto mínimo viável

Leitura. Duração: 10 min

No último vídeo, você aprendeu que o incremento do produto é o que é produzido após um determinado Sprint e é considerado liberável.

O Guia do Scrum afirma que “um incremento é um trampolim concreto em direção à meta do produto. Cada incremento é adicionado a todos os incrementos anteriores e completamente verificado, garantindo que todos os incrementos funcionem juntos. Para fornecer valor, o Incremento deve ser utilizável”.

Incremento de produto potencialmente liberável

O incremento de produto potencialmente liberável (ou enviável) é uma maneira prática para as equipes pensarem sobre o resultado desejado de um Sprint. O objetivo de cada Sprint é resultar em uma adição completa, testada e pronta para envio ao produto ou solução. Isso não significa que o produto será realmente enviado aos clientes, é por isso que é usada a palavra “potencialmente”. Considere, por exemplo, criar um aplicativo para encontrar e adotar animais de estimação. Três recursos na lista de pendências do produto podem ser:

1. Apresentar informações sobre animais de estimação disponíveis

2. Classificação de possíveis correspondências com base nos adotantes

3. Permitir ao usuário entrar em contato com o centro de adoção

Não faz sentido enviar qualquer um desses recursos isoladamente, mas terminar um incremento de produto potencialmente liberável é útil porque permite que a equipe veja um recurso em sua totalidade, em vez de trabalhar em pedaços de todos os três recursos sem nenhum deles realmente concluído. Com um incremento de produto potencialmente liberável, você criará uma implementação completa, funcional e testada de um recurso em um único sprint.

Ter um Incremento potencialmente liberável também permite que a equipe obtenha feedback antecipado sobre o produto, garanta que o trabalho seja de alta qualidade e tenha a oportunidade de responder às mudanças. Você deve sempre se concentrar em um incremento de produto potencialmente liberável como sua Meta do Sprint.

Definição de Conclusão

Um termo relacionado é a Definição de Conclusão. A Definição de Conclusão é uma descrição formal do estado do incremento de produto potencialmente liberável e o que significa quando atende às medidas de qualidade exigidas para o produto. São os requisitos acordados pela equipe para qualquer item de backlog considerado “concluído”. Em projetos de software, as equipes geralmente decidem que “concluído” significa que o software foi concluído, revisado e passou nos testes. Em um projeto que não seja de software, uma Definição de Concluído pode ser um documento que inclui uma revisão jurídica com aprovação ou um relatório de encerramento formalizado. A parte importante de descobrir a Definição de Concluído da sua equipe é ter uma compreensão explícita e compartilhada do que significa ser “feito”.

Mas como saber quando uma solução pode ser enviada ou liberada? Em uma equipe Scrum, em última análise, é decisão do Proprietário do Produto garantir que haja valor antes de liberar um item. Para determinar isso, eles podem considerar algumas coisas:

1. O incremento está completo?

2. Isso trará valor e atenderá às medidas de qualidade? Foi bem testado?

3. É utilizável pelo usuário final? Podemos usar o feedback direto ou indireto deles para melhorar as versões futuras do produto?

Comparando o incremento do produto liberável com o produto mínimo viável

Como você aprendeu no vídeo anterior, um produto mínimo viável (MVP) é uma versão de um produto com recursos suficientes para satisfazer os primeiros clientes. Eric Ries, empresário e autor, cunhou o termo neste guia e definiu um MVP como “aquela versão de um novo produto que permite que uma equipe colete a quantidade máxima de aprendizado validado sobre os clientes com o mínimo esforço”. Em outras palavras, coletar insights de um MVP permite um feedback mais rápido dos usuários do que desenvolver um produto completo que pode não ser 100% testado ou seguro. Alguns exemplos de um MVP podem ser uma página de destino para o seu site ou um botão “comprar agora” que não faz nada além de registrar que alguém clicou nele. Um produto mínimo viável é um pacote de recursos que pode levar vários sprints para ser desenvolvido, mas o objetivo de cada sprint é produzir um incremento de produto. Para diferenciar entre um incremento potencialmente liberável e um MVP, vamos pegar nosso exemplo do aplicativo de adoção de animais de estimação online e os três recursos que discutimos anteriormente. Observamos que cada um desses recursos por si só não era uma versão útil da solução. No entanto, o Proprietário do Produto pode decidir que o MVP para essa experiência do usuário deve implementar esses três requisitos apenas para gatos. Ao reduzir o escopo do MVP, o Proprietário do Produto é capaz de liberar a solução no mercado e coletar feedback dos usuários que desejam adotar gatos. Esse feedback será valioso não apenas para o processo de adoção de gatos, mas para qualquer tipo de adoção de animal de estimação em futuras iterações do produto.

Principal conclusão

Então, um incremento liberável pode ser um MVP? Sim! Sempre precisa ser um MVP? Não necessariamente. Um Scrum Master ou Proprietário do Produto está sempre se certificando de que a equipe crie incrementos potencialmente liberáveis da solução ou do produto. Em seguida, o Proprietário do Produto usa esses incrementos de produto e insights de negócios para determinar o que constituirá um lançamento valioso e viável do produto para seus clientes. Isso se baseia tanto no valor fornecido pelo usuário quanto na capacidade de coletar feedback que melhorará continuamente o produto.

A Retrospectiva do Sprint

Video. Duração: 3 min

Se você tem acompanhado este programa, aprendeu muito sobre retrospectivas, uma parte importante do gerenciamento de projetos, independentemente da abordagem que você esteja tomando.

Neste vídeo, abordaremos o último dos cinco eventos do Scrum: a Retrospectiva do Sprint.

Retrospectiva do Sprint

A Retrospectiva do Sprint é uma reunião essencial, de até três horas, para a equipe Scrum dar um passo atrás, refletir e identificar melhorias sobre como trabalhar em equipe.

Em uma Retrospectiva do Sprint, a equipe Scrum refletirá sobre aquilo que:

• Está funcionando ou não para a equipe em relação às pessoas, aos processos e às ferramentas?

• Quais melhorias devem ser exploradas no próximo Sprint?

• Quais melhorias foram implementadas no último Sprint? Eles foram úteis ou não. Por quê?

Na minha experiência, existem algumas medidas-chave a serem tomadas para garantir que as Retrospectivas de Sprint tenham sucesso.

Primeiro, é importante demonstrar o valor Scrum de respeito e sempre permitir que a equipe não se sinta culpada. Se algum membro da equipe estiver preocupado, poderá haver consequências negativas para fornecer feedback, seu resultado não será tão benéfico.

Você precisará criar um espaço seguro para a franqueza, reconhecendo o possível constrangimento e, se necessário, criar um espaço para feedback anônimo ou privado. A participação é fundamental porque as retrospectivas só funciona se os participantes sentem que sua contribuição é valorizada.

Se você notar que as pessoas não estão oferecendo suas perspectivas, procure maneiras de gerar novas ideias, como perguntar a elas:

• O que podemos tentar no próximo Sprint?

• O que nos atrasou?

• O que aconteceu que não esperávamos?

As respostas a essas perguntas podem ajudar a entender como melhorar.

Por exemplo, recentemente, minha equipe descobriu que depender de partes interessadas fora da nossa equipe Scrum estava nos atrasando. Em nossa retrospectiva, decidimos aumentar a conscientização sobre nossas prioridades com essas partes interessadas externas por meio de alguns novos canais de comunicação.

Em seguida, equilibre o negativo com o positivo. Não pergunte apenas em que você pode melhorar, mas também pergunte coisas como: onde notamos sucesso? Você quer que sua equipe sinta que foi bem-sucedida e você também deseja recriar esses resultados bem-sucedidos.

Finalmente, certifique-se de realizar ações sobre o que foi dito. As equipes podem ficar desencorajadas de participar de futuras retrospectivas se parecer que o feedback não inspirará mudanças.

Procure melhorias ou simplesmente converta as coisas que funcionaram melhor em hábitos e normas da equipe. Facilitar a conversa dentro da equipe Scrum, tanto durante as retrospectivas quanto nos fluxos de trabalho diários, é um aspecto incrivelmente importante de ser o Scrum Master e um gerente de projeto.

No próximo vídeo, vamos falar sobre se manter transparente com o fluxo de trabalho por meio do uso de ferramentas essenciais do Scrum. Elas também ajudarão a facilitar a boa comunicação dentro da equipe.

Retrospectivas de Sprint: Armadilhas e práticas recomendadas

Leitura. Duração: 10 min

Ao longo deste programa, falamos sobre retrospectivas que são um aspecto integral do gerenciamento de projetos, especialmente quando se trata de trabalhar no Scrum. Como mencionamos no vídeo anterior, as retrospectivas são um dos cinco eventos da Sprint no Scrum. Nesta leitura, você aprenderá algumas práticas recomendadas a serem implementadas e armadilhas a serem evitadas ao realizar Retrospectivas de Sprint.

Retrospectivas de Sprint

Para relembrar, retrospectivas são workshops ou reuniões que dão às equipes de projeto tempo para refletir sobre um projeto e debater possíveis melhorias futuras. Na estrutura do Scrum, as Retrospectivas de Sprint ocorrem no final de cada Sprint, que geralmente ocorre e períodos que variam de uma a quatro semanas.

Retrospectivas de Sprint são uma prática fundamental que apoiam a teoria e os valores do Scrum. Elas são um momento crítico para inspecionar e se adaptar aos resultados produzidos dentro do período de tempo do Sprint. As retrospectivas ocorrem com muito mais frequência no Scrum do que no gerenciamento de projetos tradicional, por isso, é importante considerar algumas práticas recomendadas e armadilhas a serem evitadas para ajudar a torná-las envolventes e produtivas para toda a equipe.

Armadilhas

• Evite muitos truques. Existem muitos jogos e exercícios divertidos que podem ser usados por um Scrum Master ao facilitar uma Retrospectiva do Sprint. No entanto, nem todas as equipes gostam desse estilo. Considere usar esses exercícios apenas ocasionalmente ou quando a equipe solicitar novas maneiras de fazer retrospectivas.

• Tente não se concentrar apenas no negativo. Não só é necessário que a equipe reconheça o que não está funcionando bem, também é importante destacar expectativas que foram superadas. Isso garante que a equipe evite falhas e repita sucessos também.

• Evite alterar os processos após cada retrospectiva. Não há problema em manter um novo processo em vigor por alguns Sprints antes de decidir se foi útil ou não. Você sempre pode anotar as oportunidades de mudança, mas tente esperar alguns Sprints antes de implementar novas mudanças.

Práticas recomendadas

• Faça perguntas abertas e investigativas. Faça perguntas que exijam uma discussão cuidadosa em vez de uma resposta de sim ou não. Por exemplo, pergunte: “Como poderíamos ter alcançado melhor nossa Meta do Sprint?”, em vez de: “Alcançamos a Meta do Sprint?”

• Considere diversos estilos de comunicação e participação. Torne mais fácil para todos os membros da equipe contribuírem com suas ideias e feedback. Por exemplo, nem todo mundo se sente confortável falando em um grande grupo. Experimente coisas como começar a retrospectiva com uma reflexão silenciosa, registrando um diário ou colocando a equipe em pares antes de iniciar uma conversa em grupo maior.

• Aborde os muitos aspectos do Sprint ao conduzir uma retrospectiva.

1. A produtividade e a eficiência da equipe

2. O escopo e a compreensão da Definição de Conclusão

3. Comunicação e interações dentro da equipe

4. Comunicação com as partes interessadas

5. Progresso em direção a planos de lançamento de longo alcance

• Considere refletir periodicamente sobre a teoria e os valores do Scrum fazendo perguntas específicas. Por exemplo, pergunte: “Como a equipe pode se tornar mais transparente?” ou “Como cumprimos nossos valores do Scrum nesse Sprint?”

Atividade: Recapitular a Retrospectiva do Sprint

Quiz. 1 questão | Duração: 30 min | Nota Final: 100%

Exemplo de atividade: Recapitular a Retrospectiva do Sprint.

Leitura. Duração: 10 min

Veja aqui um exemplo completo com uma explicação sobre como ele atende às expectativas da atividade.

Exemplo completo

Para usar o exemplo para este item de curso, clique no link abaixo e selecione "Usar modelo".

Link para o exemplo: E-mail de Retrospectiva do Sprint (opens in a new tab)

OU

Caso você não tenha uma conta do Google, faça o download do exemplo diretamente pelo anexo abaixo.

Activity Exemplar_Sprint retrospective email_POR

Avaliação do exemplo

Compare o exemplo com seu e-mail de retrospectiva preenchido. Analise seu trabalho usando cada um dos critérios presentes no exemplo. O que você fez bem? Em que é possível melhorar? Use suas respostas a essas perguntas como guia ao longo da realização do curso.

Observação: Seu e-mail pode abordar resultados diferentes, dependendo das principais conclusões que você decidiu enfatizar.

Vamos revisar o exemplo de e-mail seção por seção:

• A linha Assunto é breve e descreve o conteúdo da mensagem.

• A Introdução cumprimenta a equipe e explica o motivo do e-mail.

• A Recapitulação resume o conteúdo da reunião e reconhece o trabalho árduo da equipe.

• As Principais conclusões são itens acionáveis das notas da reunião que podem ajudar a melhorar os processos para futuros Sprints. Por exemplo:

1. A conclusão das notas sobre codificação e atualizações do site é:“Nossas equipes de produto e desenvolvimento fizeram um ótimo trabalho ao colocar os novos recursos do site em operação! Qualquer problema de codificação foi resolvido rapidamente!”

2. A conclusão da nota sobre os problemas com o folheto de cuidados é:“Podemos integrar melhor os processos de conteúdo e design no futuro”.

3 A conclusão da nota sobre os atrasos no envio dos itens do kit de cuidados é:“Vamos criar um plano para uma melhor comunicação com o fornecedor, para que possamos cumprir as programações de envio”.

As Próximas etapas fazem conclusões e descrevem o que a equipe deve fazer a seguir.

O Fechamento de e-mail inclui uma assinatura.

3. Ferramentas Scrum

Gráficos de velocidade e burndown

Video. Duração: 5 min

Neste vídeo, vamos explorar dois conceitos muito importantes que permitem que uma equipe Scrum gerencie seu trabalho à medida que progride em um Sprint e em todo o backlog do produto.

Esses dois conceitos são gráficos de burndown e velocidade.

Gráfico Burndown

Vamos começar com o propósito de um gráfico de burndown e como uma equipe Scrum o usa.

Um gráfico de burndown avalia o tempo em relação à quantidade de trabalho realizado e à quantidade de trabalho restante. O objetivo de usar um gráfico de burndown é manter a equipe ciente de seu progresso em relação a suas metas gerais.

Em uma equipe Scrum, gráficos de burndown refletem a evolução da equipe para a conclusão de histórias de usuários durante o Sprint.

O Scrum Master revisará o gráfico de burndown, às vezes diariamente, para examinar se a equipe vai atingir as metas ou não. Existem alguns cálculos e números simples aqui.

Agora é um bom momento para mencionar o que fazer se sua equipe estiver usando tamanhos de camiseta em vez de pontos de história. Nesse caso, basta mapear os tamanhos para um número e usar esse número para os cálculos de burndown e velocidade.

Por exemplo: talvez um tamanho extrapequeno seja um ponto, um pequeno seja dois pontos, um médio seja cinco, um grande seja oito e assim por diante.

Aqui está um exemplo: vamos imaginar que os Sprints da nossa equipe do Virtual Verde tenham duração de quatro semanas, o que contará como 20 dias úteis. No Sprint de julho, o backlog do Sprint tinha histórias que somavam um total de 200 pontos a serem concluídos.

Se você assumiu uma queima de pontos uniforme ao longo dos dias úteis, esperaria que dez pontos fossem queimados a cada dia. No quinto dia do Sprint, 22 pontos foram usados ou concluídos. Isso é apenas 25% do Sprint, então, talvez as coisas estejam no caminho certo. No décimo dia, 45 pontos foram concluídos. Devíamos estar aproximadamente na metade do caminho agora, o que seria 100 pontos. De acordo com o gráfico de burndown, estamos atrasados, de acordo com a meta do Sprint.

Agora não é hora de entrar em pânico e estressar a equipe. Nesse ponto, como Scrum Master, você já deve estar discutindo com sua equipe para saber como pode ajudar e desbloqueá-la. No dia 15, o burndown é de 140 pontos. Ufa! A equipe está de volta no caminho. No dia 20, o burndown é de 188 pontos concluídos. Bom trabalho.

Vamos discutir o que aconteceu na retrospectiva. No Scrum, há um termo para quantos pontos uma equipe queima em um Sprint, em média. Esse termo é velocidade.

Velocidade

A velocidade é uma medida de quantos pontos uma equipe queima, em média, durante um único Sprint.

Quando a equipe está realizando o Planejamento do Sprint, usa a velocidade média de pelo menos três Sprints para determinar quantos itens pode adicionar com segurança ao backlog do Sprint. Há algumas coisas dignas de nota quando se trata de calcular a velocidade.

• Em primeiro lugar, não existe uma velocidade boa ou uma velocidade ruim. A velocidade é simplesmente o que, historicamente, a equipe conseguiu atingir em um prazo pré-determinado.

• A próxima coisa é que cada equipe terá uma velocidade diferente, especialmente porque cada equipe decide sua própria calibração do sistema de pontos. É impossível comparar a velocidade da sua equipe com a de outra equipe.

Por exemplo, estou atualmente em uma equipe de três pessoas, e estamos queimando 70 pontos em um Sprint de uma semana, então, nossa velocidade é 70. Mas em uma equipe anterior, de cinco pessoas, nossa velocidade para um Sprint de duas semanas era de apenas 120 pontos. Uma equipe foi melhor ou pior que a outra? Não. Apenas diferente.

Uma vez que você tenha uma velocidade estável e um backlog refinado, com priorização e estimativas, isso desbloqueia uma superpotência incrivelmente valiosa. Agora você pode dizer às partes interessadas e aos patrocinadores duas coisas importantes.

• Você pode dizer a eles qual o tempo aproximado que levará para concluir o backlog do produto inteiro

• E quanto do seu Backlog será concluído em um determinado tempo.

Essa capacidade de prever com confiança quando as coisas podem ser concluídas é uma das ferramentas mais poderosas em Agile e Scrum, na minha opinião.

Vamos imaginar que nossa equipe do Virtual Verde tenha em média 200 pontos em cada Sprint mensal nos últimos três meses. A equipe sabe que tem 1.500 pontos restantes no seu backlog do produto. Ela podem agora dizer que levará aproximadamente sete ou oito Sprints para concluir todo o backlog do produto. E se for julho e a equipe quiser saber o que estará disponível até 1º de janeiro? Sem problemas, faltam cinco meses. Basta percorrer o backlog a partir do topo e desenhar uma linha até atingir mil pontos.

Essa é uma estimativa bastante confiável, com base n o desempenho passado da equipe. Bastante poderoso.

Se você quiser puxar as datas, poderá usar essas informações para decidir adicionar pessoas à equipe e aumentar a velocidade, reorganizar as prioridades ou tomar outras decisões importantes do projeto. Em qualquer equipe, pode levar vários Sprints para alcançar uma velocidade estável, e isso é perfeitamente normal. À medida que a equipe se acostuma a estimar e trabalhar em conjunto, a velocidade deve começar a se estabilizar.

Agora você sabe como definir a velocidade, tendências de velocidade e gráficos de burndown. Você também aprendeu um pouco sobre como uma equipe Agile atinge uma velocidade estável e o que isso implica. O uso dessas ferramentas é essencial para qualquer equipe Scrum de alto desempenho. São meios poderosos para alcançar a previsibilidade de execução.

Vou demonstrar outra ferramenta útil de visualização no próximo vídeo.

Interpretação da velocidade: Prós e contras

Leitura. Duração: 10 min

No vídeo anterior, definimos velocidade como “a medida de quantos pontos a equipe queima em um determinado Sprint, em média”. A velocidade mede a quantidade de trabalho que uma única equipe pode concluir durante uma iteração. Quando nos referimos a pontos de história, estamos nos referindo a uma unidade de medida que expressa o esforço estimado necessário para implementar esse item do backlog do produto. Esses pontos de história são calibrados e decididos pela equipe.

Cálculo da velocidade

Conforme descrito no vídeo e nas leituras, o esforço de estimativa pode ser feito em uma variedade de unidades. Na maioria das vezes, em equipes Agile, pontos de história ou tamanhos de camisetas são usados para estimar o esforço. Se você usar tamanhos de camiseta, sua equipe mapeará esses tamanhos para um valor numérico com o objetivo de calcular a velocidade de uma equipe.

Quando sua equipe começar a executar Sprints ou iterações, ela não poderá determinar com precisão a velocidade, porque não terá base histórica para calcular um número médio de pontos concluídos em um Sprint. Em seu primeiro Sprint, a equipe fará uma estimativa aproximada de quantos itens pode concluir, apenas para começar. Depois que alguns Sprints forem concluídos, sua equipe terá uma boa medida da velocidade e usará esse número para determinar quais itens incluir no backlog do Sprint. Isso será fácil de fazer se sua equipe tiver um backlog devidamente priorizado e estimado para trabalhar. Como você se lembrará dos vídeos, esse processo é chamado de refinamento de backlog.

Uso da velocidade de forma definitiva

Ao interpretar a velocidade, é importante ter algumas coisas em mente. Você pode se sentir inclinado a compartilhar a velocidade com membros de fora de sua equipe ou a usar a velocidade como uma métrica de desempenho ou comparação. Você também pode se sentir inclinado a usá-la para determinar uma data de entrega projetada. No entanto, alguns especialistas em Agile alertam contra essas práticas. Vamos explicar.

O que fazer: ter cuidado ao compartilhar a velocidade com partes interessadas externas

A velocidade pode ser útil para indivíduos de fora da equipe Scrum, mas, ao compartilhá-la com membros que não são da equipe, tenha muito cuidado. Como a velocidade é diferente para cada equipe, uma parte interessada pode não ter contexto suficiente para interpretá-la. Compartilhe materiais de apoio relevantes para ajudar a adicionar contexto. Um bom exemplo disso é compartilhar a velocidade com um intervalo de datas e visualização correspondentes que indicam tendências ao longo do tempo. Pode haver quedas e picos na velocidade que geram insights e incentivam melhorias em projetos futuros.

O que não fazer: usar a velocidade como uma métrica de desempenho

É natural que os indivíduos queiram quantificar o desempenho por meio de dados, mas pode ser prejudicial para uma equipe sentir esse tipo de pressão em seus Sprints. Alguns executivos, patrocinadores ou partes interessadas podem querer usar a velocidade como métrica de desempenho, mas isso só prejudicará a equipe, incentivando táticas como intimidação. Se a equipe estiver preocupada com que a velocidade possa fazer parecer que o desempenho está baixo, a cultura da equipe poderá ser prejudicada como resultado.

Não o faças: Usar a velocidade como métrica de comparação

Se você estiver liderando algumas equipes Scrum diferentes, poderá ficar tentado a comparar a produtividade das equipes com base na velocidade. Você pode ter o impulso de verificar quais equipes completam mais pontos da história por iteração. No entanto, o peso de diferentes pontos da história é subjetivo, porque eles são criados pela equipe.Uma equipe pode considerar uma história como cinco pontos, mas outra equipe pode considerá-la mais próxima de três pontos. Portanto, julgar a produtividade apenas pela velocidade não é preciso ou justo. Além disso, a velocidade não é uma medida de valor. A velocidade de uma equipe pode ser diferente da de outra equipe, mas essa variabilidade é boa, desde que ambas as equipes estejam agregando valor às partes interessadas.

O que fazer: ter cuidado ao utilizar a velocidade como uma métrica para a data de entrega do projeto

Usar a velocidade para estimar a data de entrega de um projeto abrangendo vários Sprints pode ser complicado. A velocidade pode ser usada como um ponto de pressão por partes interessadas externas que desejam definir uma data para o lançamento de seus produtos. A velocidade também pode criar falsas expectativas e uma cultura fortemente competitiva quando a equipe não atinge as datas estimadas. Projetar datas de entrega é prejudicial porque uma equipe pode precisar de vários Sprints para realmente entender o que é capaz de entregar em cada iteração. Além disso, se você mapear muitas datas com antecedência, não poderá levar em conta as mudanças e problemas que surgirão. Portanto, certifique-se de ter cuidado para não usar as datas de entrega estimadas como compromissos.

Utilizar quadros Kanban

Video. Duração: 3 min

Aprendemos a importância de visualizar o progresso usando gráficos de burndown no último vídeo. As boas notícias são que há outras ferramentas visuais que também podem ajudar uma equipe a progredir ao longo do Sprint. A ferramenta que abordamos neste vídeo pode ser familiar para você, pois falamos dela brevemente em um vídeo anterior. É o quadro Kanban. Algumas equipes se referem a ele como quadro Scrum em vez de quadro Kanban. Embora os dois tenham pequenas diferenças, se referem à mesma ferramenta básica.

O Guia do Scrum não especifica exatamente o que é um quadro Scrum, mas algumas ferramentas Scrum disponíveis no mercado fornecem um quadro que adiciona recursos a um quadro Kanban.

Esses recursos o tornam adequado especificamente para o Scrum. Ambos os quadros têm três recursos principais que os tornam ótimos para monitoramento do Sprint para todas as equipes Scrum.

• Visualização
• Limites de trabalho em andamento (também conhecidos como limites de WIP)
• Fluxo de trabalho.

A visualização pode ser uma estratégia importante para aprender e monitorar.

Esse quadro Kanban comunica tudo o que precisamos saber rapidamente. Podemos apontar para itens de trabalho específicos no quadro que queremos discutir, usar imagens com variação, e cores e tamanhos, à medida que verificamos os itens de trabalho, e podemos perceber onde estão os desafios em nossa equipe.

Sem essa visualização, não é tão fácil descobrir onde podemos fazer melhorias. Esses quadros facilitam a observação dos limites de WIP.

Aprendemos anteriormente neste curso que os limites comuns de que WIP são restrições de quantos itens de trabalho a equipe trabalha ativamente em um determinado momento. Isso dá foco à equipe, o que é um dos nossos valores Scrum.

Você já ouviu a ideia de que não existe multitarefa? No Scrum, isso pode ser muito verdadeiro. Quanto mais trabalho você tem, menos eficiente você pode se tornar. Quando você usa um quadro Kanban ou Scrum, cada equipe pode definir um limite de WIP com base na configuração e contexto. Dessa forma, fica bem óbvio perceber quando a equipe ultrapassa o limite de WIP.

E, finalmente, usar um quadro Kanban pode dar uma melhor noção do fluxo de trabalho por meio dos processos de execução da equipe.

Post-it físicos ou mesmo versões virtuais de quadros Kanban ou Scrum permitem que a equipe vivencie o movimento do trabalho de uma fase para outra. Ao usar um quadro Kanban ou Scrum, a equipe moverá os itens pelas seguintes etapas: a fazer, em andamento e feito. Essa ação geralmente ocorre durante Daily Scrums (reuniões diárias), mas a equipe pode mover itens a qualquer momento.

Por exemplo, com nossa equipe do Virtual Verde, digamos que Leo, nosso fornecedor de plantas, finalizou o item para finalizar os contratos com os três principais fornecedores de plantas que planejamos usar em nosso lançamento inicial.

No quadro Kanban, Leo moverá seu item para “feito” e descobrirá o que fazer a seguir.

Se por algum motivo isso era sua última tarefa no Sprint, ele pode entrar em contato com a equipe para checar como ajudar no trabalho de um colega.

Então, para recapitular, os quadros Kanban e Scrum são realmente úteis porque ajudam a visualizar seu progresso, definir e manter a carga de trabalho da equipe e os limites de WIP e dão uma noção do fluxo de trabalho em todo o processo de execução da equipe.

Ótimo. Vejo você no próximo vídeo, no qual analisaremos alguns produtos de software que ajudam uma equipe Scrum a gerenciar todas essas informações.

Prática: Usar um quadro Kanban

Plugin. Duração: 30 min

Use o Kanban para visualizar o fluxo de trabalho e o progresso do projeto

Speats é uma empresa de entrega de comida que tenta melhorar a experiência do cliente. Como gerente de projeto, ajuste o quadro Kanban para refletir as atualizações mais recentes do projeto.

Ferramentas para transparência e colaboração

Video. Duração: 4 min

Bem-vindo de volta. Abordamos muita coisa nesta seção. Aprendemos tudo sobre os vários eventos Scrum e o que cada um deles faz para garantir o sucesso de uma equipe Scrum. Para encerrar esta seção, revisaremos as ferramentas disponíveis para implementar e facilitar os fluxos de trabalho Scrum e Agile. Elas podem ajudar a melhorar a colaboração e a manter o fluxo de trabalho transparente.

Para relembrar, um dos pilares do Scrum é a transparência. Então, o sucesso de uma equipe Scrum depende muito da transparência dentro da equipe, e ferramentas incentivam todos a estar totalmente cientes do progresso e de atualizações. Essas ferramentas serão usadas para armazenar o backlog do produto, o backlog do Sprint e qualquer outra documentação essencial. O uso de ferramentas Scrum ajudará a equipe a manter todo o progresso organizado e em um lugar centralizado.

Já ouvimos falar de agendamento e gerenciamento do trabalho, colaboração e ferramentas de produtividade. Vamos revisitar essas ferramentas agora da perspectiva de uma equipe Scrum.

Vamos falar sobre ferramentas de agendamento e gerenciamento de trabalho. No gerenciamento de projetos tradicional, aplicativos como o Microsoft Project fornecem a você uma agenda e capacidades de gerenciamento de recursos poderosas. Em uma equipe Scrum, no entanto, a ferramenta mais importante de que você precisa é algo para gerenciar seu backlog e seus Sprints. Jira, da Atlassian, é uma ferramenta de gerenciamento de projetos de equipe Agile popular e é compatível com todos os aspectos de gerenciamento de equipe e backlog. Pode ser personalizada para sua equipe e fornecerá um lugar centralizado para encontrar todas as coisas relacionadas à sua equipe Scrum, seu backlog do produto, suas definições de Sprint, sua velocidade, seus gráficos de burndown e muito mais.

Depois do Jira, existem outras ferramentas no mercado que sua equipe pode comprar e que fornecem recursos semelhantes. Algumas equipes constroem suas próprias ferramentas Agile dentro de planilhas também. Na hora de escolher uma ferramenta, a maioria delas permitirá que você tenha um período de teste gratuito antes de fazer uma escolha permanente.

Se você está procurando algo simples e divertido para experimentar, eu recentemente comecei a usar os recursos Kanban do Trello em meus próprios projetos pessoais. Isso me ajudou a planejar uma mudança e a organizar uma grande festa de aniversário para o meu pai.

Asana é outra ferramenta de que falamos neste programa que funciona muito bem para Planejamento do Sprint e gerenciamento de Backlog. O Asana ajuda as equipes a planejar e coordenar o trabalho, desde de tarefas diárias até iniciativas estratégicas.

Com o Asana, todos podem visualizar, discutir e gerenciar as prioridades da equipe, Isso permite que as equipes entendam quem está fazendo o quê e o prazo de cada tarefa.

É ótimo para atribuir tarefas, automatizar fluxos de trabalho, acompanhar o progresso e se comunicar com as partes interessadas.

Esses aplicativos são criados especificamente para ajudar uma equipe a gerenciar um backlog e seus Sprints, mas há muitas atividades que esses produtos não podem realizar. É aqui que entram ferramentas adicionais de documentação, colaboração e produtividade.

Você precisará de alguma forma de documentação ou ferramenta de processamento de texto. Isso garante que você capture informações importantes sobre seu projeto em um formato longo. Muitos produtos neste espaço apresentam tanto documentação como colaboração, tudo em uma única ferramenta. O Google Docs é um ótimo exemplo, mas não é o único. Planilhas, como o Microsoft Excel ou o Planilhas Google, são úteis para a maioria das equipes. Você pode usar planilhas para capturar backlogs e Informações do item de backlog ou qualquer número de outras peças de informações para seu projeto.

Você também pode querer uma ferramenta para criar apresentações, usando o Apresentações Google ou o equivalente Apresentações Microsoft. Essas ferramentas de apresentação são usadas o tempo todo para que você apresente as informações atuais para a equipe.

E, finalmente, como se trata de Agile, valorizamos indivíduos e interações, então, é essencial ter excelentes ferramentas de colaboração e comunicação.

Os tipos de colaboração que você experimentará em uma equipe Scrum são:

• Videoconferências,
• Bate-papos individuais e em equipe online
• E-mails.

Essas ferramentas resultarão em grandes melhorias de produtividade para sua equipe. Elas permitem que os colegas de equipe se comuniquem de forma mais eficaz, obtenham respostas mais rápidas e se desbloqueiem muito antes da Daily Scrum do dia seguinte.

Existem muitos aplicativos úteis por aí para ajudar as equipes Scrum a manter a transparência desejada entre os membros da equipe. No Scrum, eles decidem o que usar juntos. Rápido assim, você está quase no final do módulo.

No próximo vídeo, revisaremos e resumiremos o que você aprendeu até agora.

4. Revisão: Implementação do Scrum

Finalização

Video. Duração: 1 min

Parabéns pela conclusão de outro conjunto de vídeos. Espero que você se sinta tão animado com o Scrum e o Agile como eu me sinto todos os dias.

Passamos muito tempo falando de uma das partes mais importantes do Scrum: o backlog do produto.

Aprendemos sobre o refinamento do backlog e a importância da estimativa de esforço relativo usando métodos como tamanhos de camiseta e pontos da história.

Identificamos os cinco eventos Scrum importantes, que são o próprio Sprint, Planejamento do Sprint, Daily Scrum (reunião diária), Revisão do Sprint e Retrospectiva do Sprint.

Aprendemos quando realizar cada um deles e as implicações de seus propósitos.

Falamos do aprendizado visual usando ferramentas como gráficos de burndown e quadros Kanban.

Também exploramos ferramentas como Jira, Asana, e Trello, o que o torna mais fácil manter o fluxo de trabalho transparente e manter todos os membros da equipe atualizado sobre os progressos realizados durante o Sprint.

Eu realmente quero parabenizar você por chegar até aqui. Você já aprendeu e realizou muito, e estou animado para que continue aprendendo.

No próximo passo, aprenderemos sobre o uso do Agile e do Scrum para se adaptar em situações da vida real.

Opcional: Agile em poucas palavras

Leitura. Duração: 10 min

Nós abordamos muito material sobre Agile e Scrum. Este vídeo do YouTube, Agile Product Ownership in a Nutshell (opens in a new tab), (Propriedade do Produto Agile em poucas palavras) é uma ótima recapitulação de alguns dos principais termos e conceitos que abordamos neste curso.

Desafio semanal 3

Até, Jul 2, 11:59 PM WEST | Quiz. 10 questões | Duração: 50 min | Nota Final: 88%

FIM! - Semana 3 - Curso 5