No Scrum, a discussão sobre o que foi feito ontem deve ser limitada às tarefas no quadro ou a todo o trabalho realizado?

Eu sei que as regras do Scrum em standups diários dizem que a equipe deve falar apenas sobre o que eles fizeram ontem, o que estão fazendo hoje e qualquer coisa que os esteja bloqueando. Nada mais. Mas o problema é que, às vezes, os desenvolvedores passam o dia fazendo um trabalho irrelevante para suas tarefas e depois falam sobre isso em pé. Foi o que eles fizeram ontem!

Na minha experiência, descobri que é mais eficaz falar sobre tarefas no quadro, manter o standup focado e manter o foco de todos em suas tarefas, revisar suas estimativas e acompanhar seus registros diariamente.

É válido limitar a discussão às tarefas no quadro?

agile scrum meetings

— Shadin
fonte

Que os desenvolvedores passem dias inteiros sem trabalhar em suas tarefas pode ser um problema que seria invisível se não fosse mencionado?

— RemcoGerlich

Todo mundo fala 30 segundos para dizer o que fez antes. Quanto mais focado você quer? Você não revisa as estimativas. Você rastreia tarefas quando as passa para o próximo profissional (revisor ou testador).

— gnasher729

Respostas:

De acordo com o conteúdo do Guia Scrum em standups diários, as três perguntas para discussão são:

O que fiz ontem que ajudou a equipe de desenvolvimento a atingir a meta da Sprint?

O que farei hoje para ajudar a Equipe de Desenvolvimento a atingir a meta da Sprint?

Vejo algum impedimento que impeça a mim ou à equipe de desenvolvimento de atingir a meta da Sprint?

Todas as perguntas se concentram no Objetivo da Sprint, não nas tarefas que estão no quadro. Novamente, de acordo com o Guia do Scrum, o Objetivo da Sprint é criado no Sprint Planning e define "um objetivo que será alcançado dentro da Sprint através da implementação do Backlog do Produto e fornece orientação à Equipe de Desenvolvimento sobre por que está construindo o Sprint. Incremento".

Tudo o que sua equipe de desenvolvimento faz deve, idealmente, ajudar a equipe a progredir em direção ao Objetivo da Sprint. Essas podem ser atividades não planejadas que não estão no quadro que precisam ser realizadas, ou podem ser coisas em um nível mais baixo que podem ter sido consideradas e estimadas, mas em um nível mais baixo do que um item do quadro.

Eu diria que deixe sua equipe falar sobre tudo o que eles fizeram ontem. Se eles estão falando sobre coisas que não ajudam a equipe a alcançar a meta da Sprint, alguém deve trazer isso à tona, especialmente se houver outras coisas que eles poderiam ter feito que levaram a equipe a se aproximar mais da conclusão da meta da Sprint.

Uma exceção pode ser se um indivíduo estiver apoiando várias equipes do Scrum. Na reunião, eles provavelmente não deveriam falar sobre tudo o que fizeram ontem, mas o que fizeram em apoio à equipe que está atualmente enfrentando dificuldades.

A Retrospectiva da Sprint é um ótimo momento para conversar sobre esse assunto com a equipe. Há muitas perguntas a serem consideradas:

A equipe está com pouco trabalho em itens relacionados ao Objetivo da Sprint?
Há muito trabalho não planejado?
De onde vem o trabalho não planejado e quem o autoriza?
Por que as pessoas estão trabalhando em coisas que não estão no quadro?
Deveríamos mostrar mais detalhes no quadro para amarrar as coisas que você faz aos itens do quadro mais facilmente?

— Thomas Owens
fonte

o problema com o "Objetivo da sprint" é muito vago e sujo. na prática Objetivo da Sprint == complete as tarefas no quadro. Se o que você trabalhou em is not lá ou ele deve ser ou você não deveria estar trabalhando nisso

— Ewan

@Ewan Um cliente liga e nos diz que o software ao vivo travou e temos um log e um relatório de erro. É importante reservar um tempo para triar esse relatório imediatamente, mesmo que não esteja no quadro no momento. Pode ser colocado em escopo ou colocado em lista de pendências, mas foi algo que fiz ontem e pode ser por isso que não pude ajudar Bob com o problema dele até depois do almoço. Eu não deveria fazer essa tarefa às cegas, mas provavelmente ninguém a colocará no quadro, a menos que seja incluída neste Sprint. Também consigo pensar em outros exemplos.

— Thomas Owens

você deve adicionar um ticket "triagem ao vivo" ao quadro e marcá-lo como concluído. Então, no final do sprint, você pode dizer com certeza. 'neste sprint, passamos X horas observando erros do usuário. É por isso que estamos atrasados. precisamos treinar melhor o serviço de assistência técnica 'Caso contrário, você não fará nada nesse sprint e o gerente de equipe só tem desculpas da equipe' oh, havia muitos bugs para analisar esta semana! shrug '

— Ewan

@ Ewan Eu acho isso incrivelmente desnecessário. Não quero passar o dia escrevendo bilhetes. Um processo precisa permitir que eu faça meu trabalho, e levar 90 minutos para a triagem, em vez de 95 minutos para a triagem e, em seguida, colocar um ticket dizendo que eu triaguei um ticket é bobagem. Especialmente se você tiver que triar vários tickets. Você não precisa de ingressos para discutir as coisas na retrospectiva. Se você estiver usando ferramentas eletrônicas, poderá encontrar tickets modificados pela equipe no Sprint para ver se havia muitas coisas para triagem - não há boatos lá.

— Thomas Owens

o nível de relatório, até o seu scrummaster / pm / empresa. você pode simplesmente escrever um ingresso para "trigaing bugs" para cobrir todo o seu trabalho do dia. Mas o importante é que você a registre como parte do SPRINT. Não assumir que é apenas contabilizado por alguma outra métrica

— Ewan

Não, você deve falar sobre o que você fez ontem.

Se não estiver no quadro, siga um destes procedimentos:

coloque no quadro,
pare de fazer isso
ou mudar de equipe.

O mais comum, digamos, para trabalhos de emergência não planejados, é escrever um cartão e colá-lo no quadro. Isso garante que, no final do sprint, você possa medir a velocidade e explicar por que os objetivos do sprint não foram alcançados.

Um membro da equipe que trabalha em coisas que não estão no sprint é, a meu ver, uma das principais razões pelas quais as adoções ágeis falham. Geralmente, esse desenvolvedor é desviado para corrigir problemas dinâmicos em outro projeto.

Outra coisa chata nos sprints é "MP falando sobre reuniões para outros projetos". Na minha opinião, o PM não faz parte da equipe de scrum, eles desempenham a função Scrum de 'Product Owner' e, portanto, estão lá para responder perguntas, não para relatar o progresso.

— Ewan
fonte

Existe algo como trabalho não planejado - trabalho que precisa ser feito para desbloquear alguém ou executar outras tarefas que estão no quadro, mas que não está no quadro. Muitas vezes, pode ser mais rápido fazê-lo do que colocá-lo no quadro. Cabe à equipe discutir como lidar com isso. Minha equipe atual tem regras - tudo o que é implantado em um ambiente de produção ou controle de qualidade, ou tarefas que levam 2 horas vão para o conselho. Às vezes, ainda existem tarefas mais curtas que precisam ser discutidas, mas que não entram no quadro porque não se encaixam nos critérios.

— Thomas Owens

@ Ewan, você pode expandir isso? Quem lida com a correção de bugs ativos, se não estiver no Sprint? Como o Proprietário do Projeto pode ao mesmo tempo ser Gerente de Projetos? (Quero dizer que é ele, ou ele está fazendo malabarismos com ambas as funções)

— Dennis

editadas para maior clareza

— Ewan

@Dennis: Gerente de Projeto não é um papel do Scrum.

— RemcoGerlich 23/11

@ Ewan, obrigado. Isso não é essencial para a resposta, mas estou curioso - o "MP falando sobre reuniões para outros projetos", como isso funciona? Os PMs entram em uma reunião sobre o projeto X, mas falam sobre Y? Tenho dificuldade em visualizar isso. Como / por que isso é possível? Você quer dizer que eles entram e essencialmente começam a fofocar ou a sair de tópico, ou há uma razão mais profunda para que eles falem sobre metas / necessidades não imediatas específicas para reuniões? Eu diria "ei, é bom ouvir isso, mas não faço parte do projeto Y ... nenhum conhecimento / experiência lá, podemos voltar ao X?"

— Dennis