Sprint System · 2026-04-30
Decisões · João + Claude

7 decisões para fechar antes
de construir o Sprint System.

O Sprint System é uma camada de foco em cima do sistema de Tasks que já existe — não substitui nada. Antes de mexer numa migration ou num componente, há 7 decisões de produto que mudam o schema, a UX e o tempo de build. Cada uma com recomendação, alternativa séria e tradeoff.

→ Ordem proposta 7 decisões Resumo
01 · Ordem de resolução

Três blocos. Algumas decisões dependem das outras.

Cadência e scope (cross-project ou não) determinam o schema. Goal e commitment afectam a UX. Rollover, review e widget são polish.

Bloco A · Schema
Decisões de fundação
Mudam a tabela sprints e a relação com tasks/projects. Decidir primeiro.
  • #1 Cadência (14d / 7d / flex)
  • #2 Cross-project ou tied to project
Bloco B · UX
Mecânica do sprint
Definem como planeas e como interages com o sprint no dia-a-dia.
  • #3 Granularidade do goal
  • #4 Committed vs stretch (ou tier único)
Bloco C · Polish
Fim de ciclo + integração
Importantes mas reversíveis. Podem evoluir depois do primeiro sprint real.
  • #5 Rollover de tasks
  • #6 Estrutura da review
  • #7 Widget no /today
02 · As 7 decisões em detalhe

Recomendação, alternativa, tradeoff.

Para cada uma: o que recomendo, a alternativa séria, e o que perdes a escolher a recomendação. Clica numa para registar a tua escolha.

#1 · BLOCO A Schema · decidir primeiro Cadência do sprint
Recomendação
14 dias fixos · Segunda → Domingo (2 semanas)
  • Standard da indústria — não inventar nada novo
  • Tempo suficiente para entregas project-shaped (website, módulo, refactor)
  • Cadência fixa = ritual previsível: Segunda planning, Sexta da 2ª semana review
  • Schema simples: start_date + end_date derivados do número do sprint
Alternativas
  • 7 dias fixos: feedback loop mais curto · obriga a decompor melhor · risco de ficar sempre apertado
  • Flexível 7–21d: adaptas ao tipo de trabalho · perdes ritual e disciplina · exige campo duration_days
Tradeoff 14 dias significa que se apanhares uma semana má (energia, viagem, cliente urgente), perdes meio sprint. A disciplina do container é precisamente o ponto — se mudares cadência cada vez que falhas, nunca aprendes a planear.
#2 · BLOCO A Schema · decidir primeiro Sprint cross-project ou tied to project
Recomendação
Cross-project (operator sprint)
  • Sprint é o teu container de foco, não milestone de projecto
  • Reflecte a realidade: trabalhas em N projectos em simultâneo
  • Tasks de qualquer projecto podem entrar no sprint actual
  • Schema: sprint_tasks(sprint_id, task_id) — sem project_id no sprint
Alternativas
  • Tied to one project: Agile clássico · ver burn-down por projecto · não reflecte como trabalhas
  • Both modes: sprints de operador + sprints de projecto · 2x complexidade · adia a decisão
Tradeoff Cross-project perde a clareza de "quanto progresso fiz no projecto X este sprint?" — mas isso já vives nas páginas de cada projecto. O sprint serve para foco semanal/quinzenal, não para gestão de projecto. Aceitar essa separação.
#3 · BLOCO B UX · mecânica Granularidade do sprint goal
Recomendação
1 frase única (theme statement)
  • Ex: "Lançar Forever Young v2 com pipeline de imagem."
  • Força clareza máxima — se não cabe em 1 frase, sprint não tem foco
  • Schema simples: goal text
  • Outcomes mensuráveis ficam nas tasks committed (não duplicar)
Alternativas
  • 1–3 outcomes estruturados: array outcomes[] · mais clareza · risco de tratar sprint como to-do list de outcomes
  • Open notes (markdown): liberdade total · perdes o constraint que força foco
Tradeoff 1 frase pode ficar vaga ("melhorar plataforma"). A disciplina é tua: se a frase não passa o teste "isto justifica 14 dias de foco?", ainda não está pronta. Adicionar campo de outcomes estruturados depois é trivial — começar com isso é overhead.
#4 · BLOCO B UX · mecânica Committed vs stretch ou tier único
Recomendação
2 tiers: committed (must-ship) + stretch (nice)
  • Committed = esses são o critério de sucesso do sprint
  • Stretch = se sobrar tempo / energia
  • Force review honesta: "completaste todos os committed?" é binário
  • Schema: commitment: 'committed' | 'stretch' em sprint_tasks
Alternativas
  • Tier único "selected": mais simples · sem distinção entre crítico e bonus · perde clareza no review
  • 3 tiers MoSCoW: must/should/could · overhead corporate · não precisas com 5–10 tasks
Tradeoff 2 tiers obrigam-te a uma decisão dura no planning ("isto é committed ou stretch?"). É exactamente onde o valor está — sem essa decisão, vais encher a lista até pareceres ambicioso e falhar metade. Custo: 1 toggle no UI, 1 enum no schema.
#5 · BLOCO C Polish · reversível Rollover de tasks não terminadas
Recomendação
Manual review no fim do sprint
  • No fecho do sprint, lista das tasks não-feitas com 3 acções: passar para próximo, devolver à backlog, matar
  • 5 min de overhead que ensinam o que estás a planear demais
  • Sem decisão automática — força reflexão
  • API: POST /api/sprints/[id]/close com decisions: [{task_id, action}]
Alternativas
  • Auto-roll para o próximo: zero fricção · perdes o sinal de que planeaste demais · backlog inflada
  • Drop tudo (volta à backlog): clean slate · pode parecer punitivo
Tradeoff Manual force-review adiciona ~5 min ao fim do sprint. Se não fizeres essa decisão consciente, o sprint vira "lista ambiciosa permanentemente" e perde o seu poder de container. Compensa o atrito.
#6 · BLOCO C Polish · reversível Estrutura da sprint review
Recomendação
Score 0–10 + 2 textos curtos
  • Score: 0–10 produtividade percebida
  • O que correu bem: textarea curta
  • O que travou: textarea curta
  • 2 minutos de review, suficiente para ver padrões a 3–5 sprints
Alternativas
  • Só score numérico: trivial · não consegues fazer retro real só com número
  • 5 perguntas estruturadas: mais profundo · vais skipar quando não te apetecer
  • Markdown livre: flexível · sem comparabilidade entre sprints
Tradeoff Score + 2 textos é o mínimo para ter retro útil sem virar burocracia. Sem os textos, score sozinho é ruído. Com 5 perguntas, vais saltar reviews. O ponto cego: precisas de fazer 3+ reviews para o histórico ser valioso — não desistas após 1.
#7 · BLOCO C Polish · reversível Widget de sprint no /today
Recomendação
Card compacto: goal + dias restantes + progresso committed
  • Topo: "Sprint 04 · 6 dias restantes"
  • Linha 1: goal em destaque
  • Linha 2: barra de progresso committed (3/5 done)
  • CTA: "Ver sprint →"
  • Lembra propósito sem competir com o briefing existente
Alternativas
  • Goal + top 3 committed tasks inline: mais informação · /today fica denso
  • Board completo embedded: tudo num sítio · mata a página /today
  • Nada — só link na sidebar: mínimo · perdes contexto diário
Tradeoff Card compacto é equilíbrio entre presença e ruído. Se viesses a usar /today todos os dias e o sprint goal estivesse só uma navegação à frente, tornavas-te o tipo de pessoa que esquece o foco da quinzena. Custo: ~80px de altura no /today.
03 · Resumo das tuas escolhas

As 7 decisões que tomaste.

Clica em Recomendação ou Alternativa em cada card acima. O resumo actualiza-se automaticamente. No fim, copia para colar no chat e arrancar o build.

Nenhuma decisão tomada ainda. Sobe até às 7 decisões, clica na opção que preferes em cada uma (ou na zona de "outra escolha") e volta aqui para copiar o resumo.
0/7 decisões