← Volver al listado de tecnologías ← Índice de BMAD Method

El Scrum Master: Stories Atomicas

17 de diciembre de 2024 Por: Artiko

bmadscrum-masterstoriescontext-sharding

El Scrum Master: Process Orchestrator

El Scrum Master es el cuarto agente en el flujo de BMAD. Su mision es tomar los Epics del PM y la arquitectura del Architect, y fragmentarlos en stories atomicas que un Developer Agent pueda implementar una por una.

Se le llama Process Orchestrator porque orquesta el orden de ejecucion de todo el trabajo.

Que es Context Sharding

Context Sharding es el concepto mas importante de esta fase y posiblemente de todo BMAD.

El problema: los LLM tienen una ventana de contexto limitada. Si le pasas a un Developer Agent el PRD completo, la arquitectura completa, todas las user stories y todo el codigo existente, el contexto se satura. El agente pierde precision, alucina y produce codigo inconsistente.

La solucion: en lugar de darle todo, le das solo lo que necesita para una story. Cada story es un fragmento autocontenido con la informacion minima necesaria para implementarla.

El ahorro: en la practica, Context Sharding reduce el consumo de tokens en un 90%. En lugar de enviar 50,000 tokens de contexto para cada tarea, envias 5,000 tokens especificos. El agente trabaja mas rapido, mas barato y con mayor precision.

Sin Context Sharding:
  Developer recibe: PRD + Arquitectura + 20 stories + codigo existente
  Resultado: contexto saturado, errores frecuentes

Con Context Sharding:
  Developer recibe: story-003.md (solo CRUD tableros)
  Resultado: implementacion precisa y enfocada

Como fragmenta Epics en Stories

El Scrum Master aplica estas reglas para crear stories:

Atomicidad: cada story se completa en maximo 1 dia de trabajo
Independencia: una story no depende de otra que este en progreso
Verificabilidad: tiene criterios de aceptacion claros
Autocontencion: incluye toda la info necesaria para implementarla

Si una story necesita mas de un dia, se divide en sub-stories. Si depende de otra, se marca explicitamente.

Formato de un archivo story

Cada story es un archivo Markdown con estructura estandarizada:

# Story [ID]

## Descripcion
[Que se debe implementar y por que]

## Dependencias
- story-XXX (debe estar DONE)

## Prerequisitos
- [Que debe existir antes de empezar]

## Subtareas
- [ ] Subtarea 1
- [ ] Subtarea 2
- [ ] Subtarea 3

## Criterios de Aceptacion
- [ ] Criterio verificable 1
- [ ] Criterio verificable 2

## Archivos Relevantes
- docs/ARCHITECTURE.md (seccion X)
- docs/db-schema.md (tabla Y)
- docs/api-spec.json (endpoint Z)

## Notas de Implementacion
[Guias especificas del Architect o PM]

Los campos clave son:

Dependencias: que stories deben estar completas antes de empezar esta
Subtareas: pasos concretos que el Developer sigue en orden
Criterios de aceptacion: como se verifica que esta completa
Archivos relevantes: solo los documentos que necesita (Context Sharding en accion)

Stories del Kanban

Veamos como el Scrum Master fragmenta los Epics del Kanban:

story-001: Setup del proyecto y base de datos

# Story 001: Setup del Proyecto y Base de Datos

## Descripcion
Inicializar el monorepo con backend (Express + TypeScript) y frontend
(React), configurar PostgreSQL con Prisma y crear las migraciones
iniciales con todas las tablas.

## Dependencias
- Ninguna (primera story)

## Prerequisitos
- Node.js 20+ instalado
- Docker disponible para PostgreSQL

## Subtareas
- [ ] Crear estructura de directorios backend/ y frontend/
- [ ] Inicializar backend con Express + TypeScript
- [ ] Inicializar frontend con Vite + React + TypeScript
- [ ] Configurar Prisma con schema completo (users, boards, columns, cards)
- [ ] Crear docker-compose.yml con PostgreSQL
- [ ] Ejecutar migracion inicial
- [ ] Verificar conexion a DB con un health check endpoint

## Criterios de Aceptacion
- [ ] `docker-compose up` levanta PostgreSQL
- [ ] `npx prisma migrate dev` ejecuta sin errores
- [ ] GET /api/health responde { status: "ok" }
- [ ] Las 4 tablas existen en la base de datos

## Archivos Relevantes
- docs/tech-stack.md (todas las secciones)
- docs/ARCHITECTURE.md (estructura de directorios)
- docs/db-schema.md (esquema completo)

story-002: Autenticacion con JWT

# Story 002: Autenticacion con JWT

## Descripcion
Implementar registro e inicio de sesion con email/password.
Passwords hasheados con bcrypt. Tokens JWT para sesiones stateless.
Cubre FR-01 y NFR-02.

## Dependencias
- story-001 (DONE)

## Prerequisitos
- PostgreSQL corriendo con tabla users
- Estructura backend configurada

## Subtareas
- [ ] Crear modulo auth/ (controller, service, routes)
- [ ] Implementar POST /api/auth/register
- [ ] Implementar POST /api/auth/login
- [ ] Crear middleware de autenticacion JWT
- [ ] Validar inputs (email formato valido, password 8+ chars)
- [ ] Escribir tests para registro, login y token invalido

## Criterios de Aceptacion
- [ ] Registro crea usuario con password hasheado (no texto plano)
- [ ] Login retorna JWT valido con expiracion de 24h
- [ ] Endpoints protegidos rechazan requests sin token (401)
- [ ] Email duplicado retorna error 409
- [ ] Tests pasan con `npm test`

## Archivos Relevantes
- docs/tech-stack.md (seccion Auth)
- docs/api-spec.json (endpoints /api/auth/*)
- docs/db-schema.md (tabla users)

## Notas de Implementacion
- NFR-02: no revelar si el email existe en errores de login
- JWT payload: { userId, email, iat, exp }

story-003: CRUD de tableros

# Story 003: CRUD de Tableros

## Descripcion
Implementar creacion, lectura, actualizacion y eliminacion de tableros.
Al crear un tablero se generan automaticamente 3 columnas:
To Do, In Progress, Done. Cubre FR-02 y FR-03.

## Dependencias
- story-002 (DONE) — necesita auth middleware

## Prerequisitos
- Autenticacion JWT funcionando
- Tablas boards y columns en DB

## Subtareas
- [ ] Crear modulo boards/ (controller, service, routes)
- [ ] Implementar POST /api/boards (crea tablero + 3 columnas)
- [ ] Implementar GET /api/boards (listar del usuario autenticado)
- [ ] Implementar GET /api/boards/:id (detalle con columnas)
- [ ] Implementar PUT /api/boards/:id (actualizar nombre)
- [ ] Implementar DELETE /api/boards/:id (eliminar cascada)
- [ ] Verificar que solo el owner puede modificar/eliminar
- [ ] Escribir tests para cada endpoint

## Criterios de Aceptacion
- [ ] Crear tablero genera 3 columnas con posiciones 0, 1, 2
- [ ] Listar tableros solo muestra los del usuario autenticado
- [ ] Eliminar tablero elimina sus columnas y tarjetas
- [ ] Usuario no-owner recibe 403
- [ ] Tests pasan con `npm test`

## Archivos Relevantes
- docs/api-spec.json (endpoints /api/boards/*)
- docs/db-schema.md (tablas boards, columns)

story-004: CRUD de tarjetas

# Story 004: CRUD de Tarjetas

## Descripcion
Implementar creacion, lectura, actualizacion y eliminacion de tarjetas
dentro de columnas. Cada tarjeta tiene titulo, descripcion, prioridad
y asignado. Cubre FR-04.

## Dependencias
- story-003 (DONE) — necesita tableros y columnas existentes

## Prerequisitos
- Tableros con columnas funcionando
- Tabla cards en DB

## Subtareas
- [ ] Crear modulo cards/ (controller, service, routes)
- [ ] Implementar POST /api/columns/:columnId/cards
- [ ] Implementar PUT /api/cards/:id
- [ ] Implementar DELETE /api/cards/:id
- [ ] Validar que priority es enum (low, medium, high)
- [ ] Asignar posicion automatica al crear (ultima posicion)
- [ ] Escribir tests para cada endpoint

## Criterios de Aceptacion
- [ ] Crear tarjeta la agrega al final de la columna
- [ ] Prioridad solo acepta low, medium, high
- [ ] assigned_to debe ser un userId valido o null
- [ ] Solo miembros del tablero pueden crear/editar tarjetas
- [ ] Tests pasan con `npm test`

## Archivos Relevantes
- docs/api-spec.json (endpoints /api/cards/*)
- docs/db-schema.md (tabla cards)

Workflow Status: Seguimiento de progreso

El Scrum Master genera un archivo workflow-status.md que rastrea el estado global:

# Workflow Status — Kanban Project

## Stories

| Story | Titulo | Estado | Dependencias |
|-------|--------|--------|-------------|
| story-001 | Setup proyecto y DB | TODO | — |
| story-002 | Auth con JWT | TODO | story-001 |
| story-003 | CRUD tableros | TODO | story-002 |
| story-004 | CRUD tarjetas | TODO | story-003 |
| story-005 | Drag & drop | TODO | story-004 |
| story-006 | Frontend auth | TODO | story-002 |
| story-007 | Frontend tableros | TODO | story-003, story-006 |
| story-008 | Frontend tarjetas | TODO | story-004, story-007 |

## Progreso
- Total: 8 stories
- TODO: 8
- IN_PROGRESS: 0
- DONE: 0

Cuando el Developer completa una story, el estado cambia a DONE. El Scrum Master verifica las dependencias antes de marcar una story como lista para implementar.

Aprobacion humana cada 2-3 stories

BMAD incorpora puntos de control humano. El Scrum Master pausa despues de definir cada grupo de 2-3 stories y pregunta:

¿Las subtareas son claras?
¿Los criterios de aceptacion son suficientes?
¿El orden de dependencias es correcto?
¿Quieres ajustar el alcance de alguna story?

No se sigue automaticamente. El humano revisa, ajusta y aprueba antes de que las stories pasen al Developer.

El orden importa: dependencias entre stories

Las dependencias forman un grafo dirigido aciclico (DAG):

graph LR
    S1[story-001<br>Setup] --> S2[story-002<br>Auth]
    S2 --> S3[story-003<br>Tableros]
    S3 --> S4[story-004<br>Tarjetas]
    S4 --> S5[story-005<br>Drag & Drop]
    S2 --> S6[story-006<br>Frontend Auth]
    S3 --> S7[story-007<br>Frontend Tableros]
    S6 --> S7
    S4 --> S8[story-008<br>Frontend Tarjetas]
    S7 --> S8

El Scrum Master garantiza que nunca se asigna una story cuyas dependencias no esten completas. Esto evita el clasico problema de implementar features sobre cimientos incompletos.

Notar que algunas stories pueden ejecutarse en paralelo: story-006 (Frontend Auth) puede empezar cuando story-002 este completa, sin esperar a story-003.

Artefactos generados

Al finalizar esta fase, el repositorio tiene:

docs/
  stories/
    story-001.md
    story-002.md
    story-003.md
    story-004.md
    ...
  workflow-status.md

Cada archivo es autocontenido. El Developer solo necesita leer uno para empezar a trabajar.

← Capitulo 5: El Architect | Capitulo 7: El Developer →