Introdução
Tem muita gente querendo usar Scrum! Porém acabam adotando a metodologia de qualquer jeito. É muito fácil encontrar material explicando o funcionamento do Scrum, explicando como fazer isso ou como fazer aquilo. Isso é muito legal, porém quando as equipes vão colocar em prática todo o conhecimento que obtiveram através de suas pesquisas e iniciar o primeiro Sprint, elas percebem que está faltando alguma coisa. Ou tudo, ou quase tudo, praticamente igual como prega o ciclo de vida do Scrum, porém ainda não dá pra começar, os que começam normalmente têm grandes desprazeres com a metodologia e acabam abandonado o uso da mesma (ainda culpam a metodologia!). Isso se dá ao fato de não saberem que existem pelo menos 7 pré requisitos que devem ser checados e resolvidos antes de iniciar o primeiro Sprint.

Primeiro
Visão Geral sobre o que será desenvolvido. Antes de qualquer esforço que venha a ser gasto para preencher o product backlog, é importante que se tenha uma visão definida sobre o objetivo do projeto. Essa visão irá nortear o Product Owner(cliente) durante a idealização e priorização dos ítens do product backlog.

Segundo
Os papéis do Scrum devem estar muito bem befinidos. Isso siginifica que o Product Owner, O Team(Equipe) e o Scrum Master já devem ter sido nomeados, treinados, motivados e disponíveis para trabalhar no projeto. Todos os envolvidos precisam, obrigatoriamente, saber como o Scrum funciona e o quanto seus níveis de comprometimento influenciam no resultado final.

Terceiro
O product backlog já deve ter sido incialmente preenchido e priorizado. O product backlog deve conter pelo menos os ítens sufucientes para dois sprints, mesmo que tudo venha a mudar nos bastidores do primeiro sprint. Fique atento com os ítens do product backlog, uma vez que eles são descobertos em diferentes níveis de granularidade. Quanto mais priorizado for o item, mais detelhado ele precisa estar(o requisito deve ser o mais atômico possível), para que o time possa estimar da melhor forma possível, em relação ao ítens da parte de baixo da lista(menos priorizados) eles podem ser quebrados em outros ítens em um momento mais oportuno.

Quarto
Ambientes de Desenvolvimento e Teste já devem estar configurados. Se o ambiente não estiver pronto para realização das tarefas, o time não conseguirá terminar nada e nenhum roi (retornor sobre investimento) será gerado para cliente. Parace absurdo, mas esse tipo de erro é muito comum. Não se esqueçam de deixar tudo prontinho pra trabalhar.

Quinto
O time deve estimar o tamanho dos ítens do Product Backlog. Quando ocorrer o primeiro Sprint Planning, o team deverá escolher um certo números de ítens para serem desnvolvidos. Devido a esse detalhe, é necessário que product backlog seja anteriormente estimado. Como o scrum defende o conceito de equipes auto-gerenciáveis, então o próprio time (aqueles que vão desenvolver os ítens) são os mais áptos a dizer algo sobre o tamanho de cada ítem do product backlog. Outras vantagens desse tipo de abordagem se dão ao fato do time passar ao Product Owner o nível de granularidade desejável nos itens do product backlog, bem como, essa prática também possibilita que a equipe já tenha uma visão antecipada sobre o que os aguarda.

Sexto
O Product Owner(PO) precisa identificar um objetivo para o Sprint. Durante o planejamento do sprint, o Sprint Planning Meeting, o PO deve apresentar à equipe o objetivo, a meta do Sprint. É de extrema importância que um sprint tenha um objetivo, afinal, a equipe precisa saber onde deve chegar. Normalmente sprints sem meta, ou com objetivos muito vagos não resultam em sucesso

Sétimo
O ScrumMaster prepara a Reunião de Planejamento do Sprint (Sprint Planning Meeting). O ScrumMaster deve garantir que a reunião não ultrapasse a barreira de 4 horas. Tudo no Scrum é “Time Boxed”, ou seja, tem um intervalo de tempo fechado para acontecer. Fica a critério de cada ScrumMaster a forma a qual será utilizada para organizar a Reunião. Muitos ScrumMasters têm utlizado uma pequena agenda que divide em horários cada etapa da reunião. Veja o que se adapta melhor a sua empresa.

Conclusão
Depois que os ítem a cima tiverem sido resolvidos, o seu time estará aparentemente pronto para iniciar o primeiro Sprint sem problemas. Perceba que os ítens quinto, sexto e sétimo devem ser checados durante todos os sprints do projeto, não somente no primeiro Sprint.