Guia de Artefatos e Cerimônias do Framework Scrum

Dashboard

Visto que o Scrum prega a transparência dentro de uma equipe de desenvolvimento, um quadro onde todas as histórias (requisitos) existentes para um produto estejam expostas é extremamente útil. Este quadro é conhecido como Dashboard. Nele estão registradas, preferencialmente através de post-its, as issues a serem entregues para o desenvolvimento de um produto. O Dashboard possui o status das issues a serem entregues pela equipe. As issues vão se movendo no Dashboard com o passar do tempo de acordo com seu status, por exemplo: issue no Product Backlog (não está contida na Sprint atual), issue no Sprint Backlog (está contida na Sprint atual), issue no Work in Progress (trabalho sendo feito no momento exato), issue na revisão e issue finalizada. As divisões existentes podem ser modificadas de acordo com a necessidade de cada equipe.

Product Backlog

É a lista principal de funcionalidades para o desenvolvimento de um dado produto. O Product Backlog pode e deve mudar no decorrer das sprints, tornando-se maior, melhor especificado e mudando as prioridades das issues. É um elemento essencial na reunião de Planning, pois é com o Product Backlog priorizado que o Product Owner irá se comunicar com a equipe de desenvolvimento com o objetivo de expressar suas maiores necessidades para aquela sprint.

Sprint Backlog

Na reunião de planejamento da Sprint (Planning), o Product Owner deverá mostrar o Product Backlog priorizado e a equipe irá escolher quais issues daquela lista serão realizadas durante aquela sprint. As issues escolhidas serão colocadas na seção de Sprint Backlog, ou seja, a lista de funcionalidades a serem implementadas na sprint corrente.

Issue ou Estória

Cada elemento da lista é conhecido como Issue e deve ser identificado com um nome e/ou ID com objetivos de identificação e rastreamento. Essas issues devem possuir também uma breve descrição das funcionalidades requeridas pelo Product Owner para um dado produto. O time pode dividir uma issue em tarefas, de preferência pequenas, para que, com a conclusão de todas as tarefas, a própria issue esteja concluída. É uma forma de usar a abordagem "dividir para conquistar" em gerenciamento de projetos.

Sprint Planning

É a reunião principal do Scrum. Nela são planejadas as atividades para a sprint corrente. Nesta reunião, o Product Owner apresenta o Product Backlog priorizado para que, então, os membros da equipe decidam quais issues do Product Backlog serão incluídas no Sprint Backlog. De forma coletiva, o Product Owner e a equipe de desenvolvimento definem um objetivo para a Sprint, que é, na verdade, uma breve descrição sobre o que se deseja entregar na Sprint.

Sprint Review

No final de cada sprint, a equipe de desenvolvimento, o Scrum Master e o Product Owner se reúnem para verificar o que foi feito durante a sprint. A equipe apresenta as funcionalidades prontas e o Product Owner aprova ou desaprova o produto. Essa reunião é aberta para qualquer outra equipe presente na empresa que queira observar a apresentação das issues completadas durante a sprint. A reunião possui a forma de uma demo de produto, onde são apresentadas novas funcionalidades, bugs corrigidos, entre outras coisas.

Sprint Retrospective

É realizada logo após o Sprint Review e tem como objetivo extrair para todos da equipe a essência do que houve de melhor e do que pode melhorar na sprint analisada. Essa reunião é fechada apenas para a equipe e o Scrum Master. Durante essa reunião serão colhidas, através de comunicação cara a cara entre os integrantes da equipe, informações sobre o andamento do projeto. Os membros da equipe são incentivados a falar sobre o que estão achando do projeto (em todos os sentidos) e é realizada pelos próprios membros uma retrospectiva em formato de timeline, especificando as datas-chave para a sprint. Essa reunião é considerada muito importante para o crescimento da equipe, pois é nela onde serão mostrados os erros e, consequentemente, as lições aprendidas durante a sprint.

Daily Scrum

É uma reunião realizada diariamente entre os membros da equipe, o Scrum Master e, opcionalmente, com a presença do Product Owner, com o objetivo de analisar o que cada membro da equipe fez no dia anterior, o que pretende fazer durante o dia presente e quais os impedimentos ou obstáculos que tem para cumprir com as tarefas. Normalmente é feita em formato de Stand-up Meeting e possui uma duração bem curta. É uma forma eficiente de manter a comunicação aberta entre os membros da equipe de desenvolvimento e o Scrum Master.