Com a disseminação das práticas ágeis pelo mundo, muitas mentiras ou meias verdades foram espalhadas por aí. Por isso, separamos alguns mitos mais comuns que ouvimos e vamos desvendar as principais falácias dentro da agilidade, principalmente do framework Scrum.

Todo o time Scrum deve estar no mesmo lugar

Muitas pessoas acreditam que, para realmente fazer o framework funcionar, é necessário que o time Scrum esteja presente 100% e isso, com certeza, é um mito. Existem times Scrum que trabalham 100% remotos, uns que fazem encontros semanais e outros que preferem o presencial.    Mas é importante entender que isso não interfere em nada nas demandas e na produção do time. O que irá fazer com o que tudo ocorra bem, serão as ferramentas, as metas e os objetivos de toda a equipe. 

Os times só podem ter de 3 à 9 pessoas

Sim, limitar o time até 9 pessoas é uma recomendação que está no Scrum Guide, pois experiências mostram que lidar com time com mais pessoas pode ser mais complicado. Porém, isso não impede que você tenha mais pessoas em seu time! 

É necessário fazer um lançamento em todo final de Sprint

Os lançamentos de produtos podem acontecer independentemente da Sprint. Muitas pessoas acreditam que é obrigatório que ao final da Sprint o time entregue algum incremento ou produto final para o cliente, porém isso não é uma regra. Você pode entregar um incremento ao final de cada sprint ou em uma única sprint fazer várias entregas de um mesmo produto.  

Uso dos Story Points ou Planning Poker é obrigatório 

Os Story Points e o Planning Poker são ferramentas que podem fazer parte dos times, mas não são obrigatórios. Ou seja, são práticas complementares que podem te ajudar em diferentes pontos dentro do time, mas não significa que se você utilizá-las ou não, quer dizer que você está fazendo algo errado.

Uma pessoa não pode exercer mais de um papel dentro do time

No Scrum Guide, não tem nada declarado sobre uma pessoa desempenhar mais de um papel dentro do time. Pelo contrário, é muito comum você encontrar múltiplos papéis dentro do time, por exemplo, um Scrum Master também pode ser um Developer.  

A equipe precisa ser full time sempre

Na verdade, esse mito se torna uma falha no entendimento do framework, já que os integrantes do time, podem trabalhar em outras equipes. Por exemplo, um Product Owner pode ser PO em outros times, assim como os Desenvolvedores e o Scrum Master. Mas é necessário ter cuidado quando utilizar essa dinâmica, pois terá sempre um ponto de falha entre os times. 

O Product Owner não deve estar presente na 2ª parte da Sprint Planning

Primeiro precisamos deixar claro que não existe mais essa diferenciação na Sprint Planning. Em antigas publicações do Scrum Guide ocorreu essa separação, mas atualmente isso não acontece mais. A primeira parte era onde o time discutia sobre as demandas que seriam realizadas na próxima Sprint e, na parte dois, somente o time de desenvolvimento fazia a quebra dessas demandas e etc.    Hoje em dia, entendemos que ainda possam existir dúvidas a serem tiradas com o Product Owner. Então, se o PO não participar dessa segunda parte, ele precisa estar disponível para caso o time queira solucionar algumas questões.

O refinamento do Product Backlog é um evento

O refinamento do Backlog acontece de maneira recorrente, ou seja, ele acontece sem as características formais das reuniões do Scrum. Por exemplo, ele pode ou não acontecer e ele não possui uma recorrência de limite de tempo como a Sprint. Seu processo pode acontecer ao longo da Sprint ou na Sprint Planning, conforme for necessário.  

O Product Backlog é sinônimo para os requisitos do Produto 

Quando pensamos em requisitos, entendemos como uma lista detalhada ou todo o escopo que o Produto terá. Porém, o Product Backlog a visão deve ser um pouco diferente, já que ele vai sendo construído com o passar do tempo… Podemos até chamá-lo de “artefato vivo”, pois ele vai sendo reordenado, priorizado, alterado, demandas entram em saem e etc, durante o processo todo.   

A História de Usuário é um item do Scrum 

Assim como as ferramentas complementares, a História de Usuário não foi criada junto com o framework, ela surgiu a alguns anos atrás e times Scrum passaram a utilizá-la como um meio para auxiliar no desenvolvimento de Produtos. Ou seja, ela não é especificamente um item!  

Para finalizar

Ainda existem muitos outros mitos sobre o Scrum que são espalhados por aí, uns mais novos, outros mais antigos… Vamos até trazer uma parte dois em breve! Entretanto, é importante deixar claro que não existem regras que devem sempre ser cumpridas fielmente.    Como é falado no próprio Scrum Guide, o Scrum pode ser adaptado de acordo com as necessidades do time, a fim de funcionar melhor para cada realidade e proporcionar mais benefícios para as pessoas e para a organização.   Para você realmente entender sobre o framework e suas funcionalidades, aqui na Agile School temos o treinamento Applying Professional Scrum, uma imersão com conteúdo direto dos criadores do Scrum, ensinamento de todos os conceitos, princípios, valores e práticas para o seu dia a dia.   Além disso, ao realizar o treinamento Applying Professional Scrum, você além de poder se tornar um especialista em Scrum, você ganha duas tentativas para a prova de certificação Professional Scrum Master I (PSM I). Ou seja, essa é uma grande oportunidade para dar um salto em sua carreira e ter o conhecimento mais pedido pelas empresas modernas e digitais. Clique aqui e saiba mais sobre o APS!   https://ead.agileschool.com.br/aps-applying-professional-scrum