Pular para conteúdo

Ata — Sprint 1 Planning — 08/09/2026

Reunião de Sprint Planning da Sprint 1, realizada na noite de 08/09/2026 e conduzida por Vinicius como Scrum Master. A reunião reuniu dois momentos: o esclarecimento, ao restante da equipe, dos achados da reunião presencial realizada mais cedo no Instituto — da qual participaram apenas Vinicius, Daniel e Maria Eduarda — e a Sprint Planning propriamente dita.

Identificação

Campo Registro
Código ATA-2026-09-08-SP
Tipo Sprint Planning
Data 08/09/2026 (terça-feira)
Horário 21:33 – ~23:07 · duração ~94 min
Local / plataforma Google Meet
Formato Remoto
Participantes — CyberSetor Maria Eduarda, Vinicius, Rodrigo, Daniel e Lucas
Participantes — externos Não se aplica
Ausentes justificados Caio
Condução Vinicius (Scrum Master)
Registro Transcrição automática da reunião · consolidação: Vinicius
Gravação Sim · Google Meet
Transcrição automática Sim, arquivada no repositório de trabalho da equipe
Documentos vistos Nenhum documento formal apresentado; debrief da reunião presencial com o Instituto ocorrida mais cedo no mesmo dia
Documentos entregues Nenhum
Técnicas de ER aplicadas Não se aplica — reunião interna de planejamento
Sprint Sprint 1
Documentos relacionados Ata da reunião presencial de 08/09/2026 · Plano da Sprint 1

1. Pauta

Reunião sem pauta formal previamente distribuída, estruturada em dois blocos: (1) esclarecimento à equipe, por quem esteve presente, dos achados da reunião presencial no Instituto realizada mais cedo no mesmo dia; (2) Sprint Planning da Sprint 1, conduzida por Vinicius como Scrum Master — método de priorização do Product Backlog, estruturação da sprint em duas semanas e organização da comunicação da equipe e com o Instituto.


2. Resumo

A equipe fez o debrief da reunião presencial de aproximadamente duas horas realizada com o Instituto mais cedo no mesmo dia, avaliando o projeto como altamente factível e de forte valor social. Na sequência, decidiu formalmente substituir o Planning Poker pelo método MoSCoW para priorização do Product Backlog da Sprint 1, por considerá-lo mais semântico e adequado ao escopo de uma sprint de requisitos. Estruturou-se a sprint em duas semanas — a primeira dedicada a dojos técnicos e de processo, a segunda ao Product Backlog — e definiu-se a adoção dos critérios INVEST e do formato Given/When/Then para as histórias de usuário. Por fim, a equipe organizou os canais de comunicação com o Instituto e discutiu, sem decidir, uma possível realocação das duplas.

  • Debrief da reunião com o Instituto — impressões, complexidade operacional revelada e oportunidades de captação e visibilidade.
  • Método de priorização — adoção do MoSCoW no lugar do Planning Poker.
  • Estrutura da Sprint 1 — semana 1 de dojos, semana 2 de Product Backlog.
  • Padrão de histórias de usuário — critérios INVEST e Given/When/Then.
  • Comunicação — grupo com o Instituto, reuniões recorrentes, registro em vídeo.
  • Dinâmica da equipe — possível realocação das duplas discutida, sem decisão.

3. Decisões

# Decisão Justificativa Impacto
D1 Adoção do método MoSCoW (Must/Should/Could/Won't) como instrumento único de priorização e dimensionamento do Product Backlog, sem Planning Poker nem pontos de história O MoSCoW é mais semântico e adequado ao escopo desta sprint — que é de requisitos, não de esforço de codificação — do que a estimativa relativa em pontos, cuja utilidade plena só se manifesta a partir da Sprint 3 (primeira sprint de código). A opção é deliberadamente minimalista: no método DSDM, de onde o MoSCoW vem, a própria regra de proporção de esforço entre as categorias faz o papel de dimensionamento, dispensando uma escala numérica paralela Método único de priorização do Product Backlog. Qualquer mudança de método passa a exigir decisão em Sprint Retrospective
D2 Sprint 1 estruturada em duas semanas: semana 1 dedicada a dojos técnicos e de processo; semana 2 dedicada à produção do Product Backlog Nivelar o vocabulário técnico-normativo e a técnica de redação de histórias antes de produzir o backlog evita histórias genéricas Estrutura de trabalho da Sprint 1
D3 Padronização das histórias de usuário pelos critérios INVEST, com critérios de aceitação em formato formal (Given/When/Then) Garante histórias independentes, negociáveis, valiosas, estimáveis, pequenas e testáveis, e critérios de aceitação objetivos, não vagos Padrão de redação do Product Backlog
D4 Gravação de todas as sessões de dojo e reuniões, para consulta por quem não puder comparecer Pedido de Daniel, aceito pelo grupo, para não excluir quem falta pontualmente Prática de registro da equipe
D5 Reuniões recorrentes às terças e quintas à noite, agendadas no Google Agenda Padronizar a cadência de encontros da equipe e alinhar as atividades com o Instituto Cadência de comunicação da equipe

4. Próximas etapas

# Ação Responsável Prazo Situação
A1 Solicitar ao Instituto o relatório e a planilha-template pendentes Maria Eduarda manhã de 09/09 Pendente
A2 Disponibilizar esta ata no repositório de trabalho da equipe, para consulta de quem não participou Rodrigo Pendente
A3 Criar grupo de WhatsApp com o Instituto e adicionar as pessoas relevantes Maria Eduarda Pendente
A4 Enviar a ata desta reunião aos contatos do Instituto Maria Eduarda Pendente
A5 Agendar reuniões recorrentes de terça e quinta com o Instituto no Google Agenda Equipe Pendente
A6 Preparar materiais educacionais dos dojos (tecnologias e escrita de histórias de usuário) Vinicius até 10/09 Pendente
A7 Realizar os dojos (Dojo P1 e P2) Equipe 10/09 (noite) Pendente
A8 Consultar a administração financeira do Instituto sobre licitações e editais, como insumo das histórias de usuário Equipe Pendente
A9 Revisar criticamente, entre pares, as histórias e critérios de aceitação escritos pela outra dupla Equipe Semana 2 Pendente
A10 Publicar o Plano da Sprint 1 no GitHub Pages Vinicius Em curso
A11 Publicar esta ata no GitHub Pages Vinicius Pendente — aguarda orientação do professor sobre commits pós-U1

5. Detalhes por tópico

Debrief da reunião presencial com o Instituto

A equipe considerou a reunião de aproximadamente duas horas com o Instituto um forte indício de abertura e interesse dos representantes em apresentar sua dinâmica de negócio. Avaliou o projeto como altamente factível, com valor para o crescimento técnico da equipe, visibilidade e potencial de captação de recursos, dado o valor social da iniciativa.

Achado novo sobre o cliente: o Instituto administra uma diversidade de setores operacionais além do núcleo pedagógico — marcenaria, lavanderia, oficinas de estilografia e atendimento social a pessoas em situação de rua — e a falta de um sistema adequado torna extremamente difícil o controle de estoque e de tarefas nesses setores, sobrecarregando os envolvidos. Este achado amplia a leitura de complexidade organizacional do cliente e deve ser incorporado à ficha do cliente e ao mapa de stakeholders.

A plataforma foi discutida como potencial ponte entre o ambiente privado e o público, permitindo ao Instituto atender mais demandas e eventualmente expandir para outros estados, caso organize melhor seus processos internos.

Potencial de impacto social adicional: a equipe destacou que a plataforma pode auxiliar na capacitação profissional dos beneficiários — por exemplo, conectando a produção de mobiliário da marcenaria ao mercado de trabalho. Não é escopo do produto, mas é argumento de valor a registrar na declaração do problema e na validação com o cliente.

Confirmou-se a ausência de cultura organizacional hierarquizada no Instituto: ninguém assume explicitamente responsabilidade por cargos ou tarefas, o que gera gargalos operacionais e dificulta a cobrança de prazos — achado consistente com a concentração de captação, prestação de contas e resolução de emergências na Diretoria de Projetos, já identificada na reunião presencial.

Dados e LGPD

Confirmou-se a necessidade de uma base única de usuários para histórico de participação, contatos e atendimentos — hoje tratada de forma dispersa e insegura via WhatsApp e Google Drive.

Vinicius esclareceu à equipe que a conformidade com a LGPD é viável porque o sistema não tratará dados financeiros sensíveis, focando em recibos e registros operacionais. Este esclarecimento fixa o limite prático da restrição de escopo já adotada pela equipe quanto a dados sensíveis.

Infraestrutura e ideias de produto para o roadmap

Reafirmada a intenção de usar soluções de código aberto e contêineres (Coolify) para hospedagem a custo inicial zero, com capacidade de escalar conforme a base de usuários cresça.

Ideia para o roadmap, não comprometida nesta sprint. Bots de monitoramento automático de portarias e editais, eliminando parte do trabalho manual de busca de oportunidades — mencionada como possibilidade futura, não como item do Must desta sprint.

Ideia de produto para avaliação futura. Permitir que o usuário anexe o PDF do edital e o sistema extraia os requisitos automaticamente, evitando o preenchimento manual de planilhas. Candidato de baixa prioridade (Could) para priorização em sprint futura.

Discutidas as limitações de PWA entre Android e iOS (Safari), especialmente quanto ao armazenamento offline via IndexedDB — a equipe concorda em deixar essas limitações explícitas ao cliente, não em tentar contorná-las nesta fase.

Método de priorização (MoSCoW)

A equipe avaliou o MoSCoW como framework mais semântico e adequado ao escopo desta sprint do que o Planning Poker, e decidiu adotá-lo para a priorização das funcionalidades e histórias de usuário do Product Backlog (ver Decisão D1).

A adoção é exclusiva: o MoSCoW passa a ser o único instrumento de priorização e dimensionamento do backlog, sem escala numérica de estimativa em paralelo. O controle de escopo se dá pela proporção de esforço entre as categorias e pelo fatiamento de itens grandes, mantendo fixo o prazo da Sprint.

Estrutura da Sprint e dojos

Confirmou-se a estrutura de duas semanas: a primeira dedicada aos dojos técnicos e de processo; a segunda ao Product Backlog, com trabalho em pares e revisão crítica entre a equipe, preparando o grupo para questionamentos externos.

Detalhamento dos dojos: o primeiro cobre Prisma, NestJS e TanStack Query (nivelamento técnico); o segundo cobre a padronização de histórias de usuário e critérios de aceitação pelos critérios INVEST. Realização prevista para a noite de quinta-feira (10/09).

Objetivo da Sprint 1, conforme discutido: descrever o ciclo completo do projeto por meio de histórias de usuário e critérios de aceitação, validando esse entendimento com diferentes áreas do Instituto, de modo que o Product Backlog fique bem estruturado.

Dinâmica da equipe

A equipe discutiu a distribuição de carga entre as duplas e uma possível reestruturação, mas não decidiu: a composição atual foi mantida, com reavaliação prevista para 10/09. O Scrum Master registrou que a avaliação do projeto é coletiva e que o acompanhamento do engajamento é atribuição do papel, a ser tratada individualmente e retomada na Sprint Retrospective.

Comunicação e registro

Definido que as atas devem ser colocadas no Drive e que o calendário de reuniões deve ser integrado ao Google Calendar. Discutiu-se a criação de um canal no YouTube para o conteúdo gravado (sugestão de Maria Eduarda) e o uso de registros automáticos de reunião.


6. Pendências e pontos em aberto

# Pendência Depende de Encaminhamento
P1 Composição das duplas e distribuição de carga de trabalho Reavaliação da equipe Acompanhar na daily; decisão formal e seu registro cabem à Sprint Retrospective da Sprint 1, em 22/09
P2 Diversidade de setores operacionais do Instituto (marcenaria, lavanderia, estilografia, atendimento a pessoas em situação de rua) exige revisão de impacto no escopo Dupla responsável pela seção 1.3/1.6 Vinicius comunica o achado no grupo de WhatsApp da equipe para que a dupla avalie o impacto; o sistema é progressivo e o escopo desta disciplina já está definido — cobertura adicional destes desafios fica como melhoria futura, sujeita à concordância do Instituto após o encerramento da disciplina

Nota de processo. Esta ata, como toda Sprint Planning, é registro formal do que foi deliberado — não é revisada retroativamente à medida que a sprint avança. Aprendizados, débitos e melhorias de processo ou de template identificados durante a execução da Sprint 1 são registrados na Sprint Review e na Sprint Retrospective de 22/09/2026, que alimentam a melhoria contínua dos próprios documentos de Planning das sprints seguintes.


7. Insumos para o Documento de Visão

Achado desta reunião Entra em Situação
Adoção do MoSCoW como método único de priorização e dimensionamento do Product Backlog 5.2 — Atividades de ER por fase · seção 8 (U2) a redigir
Diversidade de setores operacionais do Instituto (marcenaria, lavanderia, estilografia, atendimento a pessoas em situação de rua) 1.3 — Descrição do cliente · 1.6 — Stakeholders registrado como pendência (P2, §6) — comunicado à dupla responsável antes da redação
Potencial de capacitação profissional como valor social adicional 1.4 — Declaração do problema (contexto) · 7.3 a redigir
Esclarecimento sobre o limite da LGPD (sem dados financeiros sensíveis) 2.4 — Restrições Já refletido na decisão de escopo do projeto; reforçar redação na U2
Ideia de extração automática de requisitos a partir do PDF do edital roadmap (Could) registrado como candidato, não comprometido
Critérios INVEST e Given/When/Then como padrão de histórias seção 8 (U2) Já em uso desde o Plano da Sprint 1

Histórico de versões

Versão Data Alteração Responsável
1.0 08/09/2026 Registro inicial, a partir da transcrição automática da reunião Vinicius
2.0 09/09/2026 Consolidação no template formal do projeto: identificação, decisão MoSCoW destacada, achados novos sobre a estrutura do Instituto e rastreabilidade para o Documento de Visão Vinicius
3.0 09/09/2026 Revisão final: participação confirmada pela equipe; pendência sobre a composição das duplas reencaminhada à Sprint Retrospective, conforme o escopo próprio de cada rito; achado sobre os demais setores do Instituto formalizado como pendência, com encaminhamento à dupla responsável Vinicius
4.0 09/09/2026 Revisão de estilo para publicação: substituição dos marcadores gráficos por texto corrido; decisão sobre o MoSCoW detalhada como método único Vinicius

Validação: ata interna da equipe — não requer validação do Instituto.