“ Vinte perguntas para você – o novo Scrum Master – que cabem em um intervalo de tempo de 60 minutos. Comece aprendendo como seu novo Time Scrum está entregando o produto e fique atualizado: desde a análise forense do Backlog do Produto até métricas, desafios da equipe e dívida técnica…
Comece a aprender o que compete a um novo Scrum Master.
Recentemente, fui convidado a participar do refinamento do Product Backlog de uma equipe que estava procurando um novo Scrum Master. Eu estava cético no começo. Eu tinha apenas um conhecimento limitado sobre o projeto – um site comercial baseado em um CMS -, a sessão de refinamento durou 60 minutos, e eu não conhecia os membros da equipe antes além de um breve “alô”.
Então, preparei um questionário com tópicos relacionados à equipe. Eu queria aprender mais e ouvir o Time Scrum, refinando vários itens de trabalho. Quando apropriado, fiz uma das perguntas preparadas. Surpreendentemente, os insights revelaram-se muito mais qualificados do que eu esperava. Particularmente, eu poderia identificar os “frutos do Scrum” mais simples para melhorar a entrega do produto com relativa facilidade. Lembre-se de que, como um Scrum Master, os stakeholders sempre julgarão você se “seu Time Scrum” pode entregar um incremento de produto valioso, potencialmente liberável e “pronto” regularmente.
- Qual é o tamanho do seu Product Backlog?
Não acredito em Backlogs de produtos maiores do que a equipe pode controlar em três, talvez quatro Sprints. Se o Product Backlog exceder esse limite, o Product Owner pode precisar de algum suporte.
- Qual é a idade típica de um item do Backlog do produto?
Um item do Backlog do produto que não foi tocado em cinco meses está obsoleto. Encher o Backlog do Produto com ideias, lembretes ou outros itens de baixo valor aumenta o ruído, provavelmente impedindo a entrega de valor do Time Scrum. (Reconheço que sou um fã da análise forense do Product Backlog.)
- Qual é o seu lead time médio desde a adição de uma ideia ao Backlog do produto até sua entrega?
Ninguém conseguiu responder a essa pergunta na sessão mencionada anteriormente. Mas, na verdade, é uma das poucas métricas que podem fornecer alguns insights sobre se o Scrum foi adotado com sucesso pela sua organização. (Leia mais: Métricas ágeis – o bom, o ruim e o feio .)
- Seu Backlog do produto contém itens de trabalho com os quais nenhum dos membros da equipe atual está familiarizado?
Nesse caso, os itens do Backlog do produto em questão podem não ter mais valor. Considere refinar ou excluí-los.
- Com que frequência você está refinando o Product Backlog?
Isso deve ser um processo contínuo. Como um novo Scrum Master, no entanto, eu adoraria ter uma sessão de refinamento do Product Backlog uma vez por semana com toda a equipe.
- Em quantos itens do Product Backlog você está trabalhando em paralelo durante o refinamento do Product Backlog?
Idealmente, uma equipe não deve trabalhar em mais itens de trabalho do que pode lidar nos próximos dois ou três Sprints. Caso contrário, o risco de alocar recursos em itens de trabalho que podem nunca entrar em um Sprint Backlog torna-se muito alto.
- Quanto tempo leva o refinamento de um item típico do Backlog do Produto?
O refinamento não deve demorar mais do que um a dois Sprints. Caso contrário, o Product Owner pode precisar de algum suporte na preparação de ideias de maneira adequada para as sessões de refinamento.
- Como você está criando itens do Backlog do produto? (É um esforço conjunto da equipe com o PO ou o Product Owner está escrevendo os itens de trabalho e a Equipe de Desenvolvimento os estima?)
Há uma tendência de observar que os Proprietários do Produto se tornam mais um tipo “redator técnico” dos itens do Backlog do Produto que são estimados pela equipe. Sugiro, no entanto, transformar a criação de itens do Product Backlog em um esforço conjunto de toda a equipe. Lembra do CCC de Ron Jeffries: cartão, conversa, confirmação ?
9. Onde você está discutindo os itens do Backlog do produto? (Apenas durante as sessões de refinamento ou também no Slack ou por meio de comentários em tickets, por exemplo?)
Cada equipe tem seus próprios hábitos e talvez comentar no Confluence, Jira, Github ou utilizando o Slack seja um meio eficaz de comunicação em sua organização. Contanto que isso aconteça antes de um item de trabalho ser selecionado para um Sprint Backlog, isso deve funcionar. Discutir seus fundamentos posteriormente é um problema, pois o objetivo do Sprint pode estar comprometido.
Quem está escrevendo os critérios de aceitação e em que formato?
- Deve ser o Dono do Produto em colaboração com a Equipe de Desenvolvimento seguindo a Definição de “Pronto”, criando assim um entendimento compartilhado do que a equipe precisa construir.
Como você está estimando o esforço provável de um item do Product Backlog?
- Existem muitas práticas sobre como estimar um item de trabalho se o seu Time Scrum estimar. (Pense em # noestimates ou em criar itens de trabalho de tamanho semelhante.) A ênfase deve ser na criação de um entendimento compartilhado entre todos os membros da equipe sobre o que deve ser criado. Uma estimativa é um efeito colateral, não o objetivo principal.
12.Você está estimando em horas-homem ou pontos de história?
Estimar em horas-homem é melhor do que nem estimar. No entanto, prefiro pontos da história, principalmente se o aplicativo em questão estiver sobrecarregado com código legado e / ou dívida técnica. A previsibilidade e as comunicações com as partes interessadas tornam-se mais fáceis desta forma, pois os pontos da história têm um buffer integrado.
- Como você está praticando o processo de estimativa, se a equipe compartilha opiniões diferentes?
De preferência, você deve observar o processo de estimativa da equipe na vida real. Mas caso você tenha que perguntar: é um ciclo típico de votação-discussão-revogação? Ou: quando e como você escolhe um orçamento? (Exemplos: divisão 50:50, por exemplo, 3 * 3 e 3 * 5 – qual você escolhe? Ou uma divisão por maioria: 2 * 3 e 4 * 5. Ou as estimativas cobrem um intervalo, por exemplo, de 2 a 8?) É uma boa maneira de aprender mais sobre o estado de construção da equipe também.
- Qual é a distribuição típica de tamanhos de itens de trabalho em seu Sprint Backlog?
Esta questão tenta descobrir onde está o ponto ideal de produtividade da equipe, com base na composição do Sprint Backlog. Em minha observação, os Times Scrum geralmente trabalham com mais sucesso quando um Sprint Backlog compreende um ou dois itens maiores do Backlog do Produto, algumas histórias de tamanho médio e algumas pequenas.
- Você está reestimando itens de trabalho no final de uma Sprint? Em caso afirmativo, sob quais circunstâncias você está fazendo isso?
Isso sempre deve ser feito se um item do Backlog do Produto estiver muito longe de sua estimativa original. As reavaliações também são bons pontos de dados para as retrospectivas do Sprint.
- Qual foi a sua velocidade nos últimos três Sprints?
Um Time Scrum deve saber sua velocidade ou produtividade, de outra forma, como poderia melhorar?
- Quantas histórias de usuário normalmente não são concluídas em uma Sprint e por quais motivos?
Se a equipe está otimista e escolheu mais itens do Product Backlog do que provavelmente poderia lidar no início da Sprint, que seja – nada com que se preocupar se a Equipe de Desenvolvimento cumprir a Meta da Sprint. Se a Equipe de Desenvolvimento, no entanto, está regularmente deixando itens de trabalho no quadro e não cumprindo as Metas do Sprint, esta deve ser uma grande preocupação para o novo Scrum Master. Consulte também: Scrum: a obsessão com a velocidade de correspondência de compromisso .
- Você está mudando itens do Backlog do Produto assim que eles se tornam parte de um Sprint Backlog? E em caso afirmativo, em que circunstâncias?
Tornar os itens de trabalho menores se a equipe de desenvolvimento encontrar um problema certamente não é ótimo, mas é aceitável – se o item de trabalho em sua forma reduzida ainda agregar valor e a meta do Sprint for atingida. Prorrogá-lo após o Planejamento do Sprint, entretanto, só seria tolerável se a Equipe de Desenvolvimento concordasse com a extensão e o Objetivo do Sprint não fosse comprometido.
- Como você avalia o nível de endividamento técnico?
Como um novo Scrum Master, você deseja saber tudo sobre o nível atual de dívida técnica e dependências de outros Times Scrum ou fornecedores externos. Essas questões são diretamente responsáveis pela capacidade do seu Time Scrum de entregar incrementos de produtos. (Leia mais: Dívida técnica e Scrum: Quem é o responsável? )
- Quais são os três principais desafios que o Time Scrum está enfrentando hoje?
Esta pergunta de fechamento é, por design, uma pergunta aberta para obter algumas ideias para a próxima Retrospectiva da Sprint.”
Por: Stefan Wolpers
Fonte: https://www.scrum.org/resources/blog/20-questions-new-scrum-masters-should-ask-their-teams-get-speed
Comentários