29 perguntas para a equipe obter um novo Scrum Master
1. Qual é o tamanho do seu backlog de produto?
Eu não acredito em backlogs de produtos que são maiores do que o que a equipe pode suportar em três, talvez quatro sprints. Se o backlog do produto exceder esse limite, o proprietário do produto pode precisar de algum suporte.
2. Qual é a idade típica de uma história de usuário no backlog do produto?
Mais uma vez, não acredito no valor de uma história de usuário com cinco meses de idade. E um "mas eu tenho trabalhado nisso desde então" é uma desculpa aos meus olhos.
Dica: Baixe gratuitamente a nossa Apostila de Scrum | Gestão Ágil de Projetos. 
3. Qual é o tempo médio de espera de uma ideia sendo adicionada ao backlog do produto até a entrega?
Ninguém poderia responder a essa pergunta na sessão antes mencionada. Mas na verdade é apenas uma das três métricas que podem fornecer algumas dicas sobre se a “agilidade” foi adotada com sucesso pela sua organização.
4. Seu backlog de produto contém histórias de usuários com as quais nenhum membro da equipe atual está familiarizado?
Talvez eles devam ser reestimados com os membros atuais da equipe para garantir que a estimativa ainda seja precisa?
5. Com que frequência você está preparando o backlog do produto?
Isso deve ser feito pelo menos uma vez por semana, dependendo do estado do projeto.
6. Em quantas histórias de usuário você está trabalhando em paralelo durante a preparação do backlog?
O ideal é que uma equipe não trabalhe em mais histórias de usuário do que pode lidar nos próximos dois ou três sprints. Caso contrário, o risco de alocar recursos em histórias de usuários que talvez nunca se transformem em um backlog de sprint se torna muito alto.
7. Quanto tempo demora a preparação de uma típica história de usuário?
A preparação não deve levar mais de um a dois sprints.
8. Como você está criando histórias de usuários? (É um esforço de equipe conjunta com o PO ou o proprietário do produto está escrevendo as histórias do usuário e a equipe as estima?)
Há uma tendência de observar que os proprietários de produtos se tornam mais "escritores técnicos" de histórias de usuários que são estimadas pela equipe. Sugiro, no entanto, transformar a criação da história do usuário em um esforço de junção de toda a equipe.
9. Onde você está discutindo histórias de usuários?
Apenas durante as sessões de preparação ou também no Slack ou através de comentários em bilhetes, por exemplo, cada equipe tem hábitos próprios, e talvez comentar no Confluence, Jira, Github ou utilizar o Slack é um meio eficaz de comunicação em sua organização. Contanto que isso aconteça antes que uma história de usuário seja selecionada para um backlog de sprint, isso deve ser bom. Discutir seus fundamentos depois é um problema, no entanto.
10. Você aplica um padrão de “definição de pronto” às suas histórias de usuário?
Isso deveria ser um padrão. Uma velocidade volátil pode ser atribuída, pelo menos em parte, à falta dela.
11. Em caso afirmativo, de que critérios a sua “definição de pronto” é composta?
Critérios típicos para uma “definição de pronto” são: A descrição está disponível, os critérios de aceitação são definidos, a história pode ser entregue em uma sprint, todas as entregas UI estão disponíveis, todas as dependências (prováveis) são identificadas, critérios de desempenho são definidos, rastreamento critérios são definidos e a história é estimada pela equipe.
12. Quem está escrevendo os critérios de aceitação e em que formato?
Deve ser o proprietário do produto em colaboração com a equipe para criar um entendimento compartilhado do que precisa ser construído.
13. Como você está estimando o provável esforço de uma história de usuário?
Um poker de estimativa seria útil.
14. Você está estimando em horas-homem ou pontos de história?
Estimar horas-homem está apostando do que não estimando nada. No entanto, prefiro os pontos de história do usuário, especialmente se o aplicativo em questão estiver sobrecarregado com código legado e / ou dívida técnica. A previsibilidade e as comunicações das partes interessadas se tornam mais fáceis dessa maneira, pois elas são apresentadas com um buffer interno.
15. 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 no caso de você ter que perguntar: é um típico ciclo de votação-discussão-revogação? Ou: quando e como você escolhe uma estimativa? (Exemplos: divisão de 50:50, por exemplo, 3 * 3 e 3 * 5 - qual você toma? Ou uma divisão majoritária: 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 formação de equipes também.
16. O que é uma distribuição típica de tamanhos de histórias em seus backlogs de sprint?
Este tenta descobrir onde está o ponto de compromisso da equipe, baseado na composição do sprint backlog. Para minha observação, as equipes geralmente trabalham de maneira mais bem-sucedida, quando um backlog de sprint é composto por uma ou duas histórias de usuário maiores, algumas histórias de tamanho médio e algumas pequenas.
17. Você está reestimando histórias de usuários ao final de um sprint?
Em caso afirmativo, sob quais circunstâncias você está fazendo isso? Isso sempre deve ser feito se as histórias de um usuário acabarem ficando fora de sua estimativa original.
18. Qual foi a sua velocidade dos últimos três sprints?
A equipe deve saber sua velocidade, como poderia, de outra forma, melhorar?
19. Quantas histórias de usuário geralmente não são concluídas em um sprint e por quais motivos?
Se a equipe é otimista e escolheu mais histórias de usuário do que provavelmente poderia ser manipulado no início do sprint, assim seja - nada para se preocupar. Além disso, há outros incidentes que podem afetar negativamente a velocidade real da equipe, por exemplo, licença médica ou um erro crítico em alguns dias no sprint. Se a equipe, no entanto, está regularmente deixando as histórias do usuário no quadro porque as estimativas estavam erradas, isso é um sinal de preocupação.
20. Você está mudando as histórias de usuários quando elas se tornam um item de um backlog de sprint?
E, em caso afirmativo, em que circunstâncias? Bem, reduzi-los se a equipe depara com um problema certamente não é grande, mas aceitável - se a história do usuário em sua forma reduzida ainda fornecer um valor. Tornar-se maior depois do planejamento da sprint, no entanto, não é aceitável.
21. Quais são os obstáculos que a equipe enfrenta hoje?
22. Quais são as dependências de outras equipes?
E se houver dependências, você está esperando que outras equipes concluam suas tarefas?
23. Defina e discuta pelo menos três metas importantes da equipe para o projeto.
Algumas das respostas podem parecer óbvias, isto é, cumprir nosso prazo dentro do nosso orçamento, mas essa discussão pode muitas vezes trazer outros objetivos que não são óbvios para a equipe inicialmente. Isso pode ajudar o Scrum Master a entender as motivações e dinâmicas da equipe.
24. Quais são os principais fatores de sucesso para atingir os objetivos da nossa equipe?
Definir e discutir os principais fatores de sucesso, ou seja, minimizar o impacto das dependências, pode ajudar a identificar impedimentos, riscos e problemas em nível de projeto que o Scrum Master pode começar a abordar. Também é uma boa referência para revisar e atualizar conforme o andamento do projeto.
25. O que os membros da equipe esperam alcançar com este projeto?
É interessante ter uma noção das metas pessoais das pessoas para o projeto, além das metas da equipe que vamos estabelecer de forma colaborativa. Ter essa informação pode ajudar a manter as pessoas motivadas ao longo do projeto. Algumas pessoas podem querer aprender novas tecnologias, fazer parte de uma equipe ágil de alto desempenho ou ter outras metas.
26. Que tipo de ambiente de trabalho queremos criar neste projeto?
Essa pergunta pode estimular uma boa discussão sobre como os integrantes da equipe desejam interagir uns com os outros para atingir as metas do projeto. Muitas vezes, a discussão gira em torno da confiança, da comunicação, da colaboração e do respeito, mas é bom garantir que haja algum acordo (ou uma aceitação das diferenças) por parte da equipe sobre o que é importante.
27. O que podemos fazer em equipe para nos certificarmos de que nos apoiamos mutuamente para alcançar as metas de nossa equipe?
Esta pergunta pode ajudar o Scrum Master a entender como os membros da equipe entendem a importância de assumir compromissos como uma equipe e não como indivíduos. Também pode ajudar a equipe a estabelecer acordos informais sobre a necessidade de todos se apoiarem mutuamente, assumir papéis fora de sua especialidade e confiar em sua equipe quando precisarem pedir ajuda.
28. O que devemos fazer quando não estamos atingindo nossos objetivos ou não apoiando uns aos outros?
Obviamente, isso pode ser abordado em uma retrospectiva, mas ter a discussão antecipada pode ser útil para entender como os membros da equipe percebem como essas situações devem ser tratadas. Pode ajudar a estabelecer a necessidade de uma comunicação aberta e honesta baseada na confiança.
29. Como devemos celebrar o sucesso para alcançar nossos objetivos?
É importante que a equipe visualize e espere sucesso. Essa discussão pode ajudar a equipe a discutir as recompensas significativas e mantê-las concentradas em realizar essas recompensas.
Qual é a sua melhor prática como um novo Scrum Master para entender como uma equipe está trabalhando?
Qual é a sua técnica preferida para se familiarizar com uma nova equipe Scrum o mais rápido possível? Por onde você começa?
Por favor, compartilhe sua experiência nos comentários :)
