Guía de Planeación, Refinamiento y Seguimiento de Sprints (Scrum + Scrumban simple)
0) Objetivo
Consolidar las prácticas recomendadas para la planeación, estimación, ejecución y seguimiento de historias de usuario (US) en Brace, permitiendo operar con Scrum cuando hay certeza y activar un Scrumban simple cuando existe un bloque relevante de incertidumbre. En ambos modos se mantienen las mismas métricas clave del desarrollador: cumplimiento de estimación, rollovers y calidad.
1) ¿Cuándo usar cada modo?
1.1 Scrum (normal)
Usar cuando es posible planificar todo (o casi todo) el sprint con historias refinadas antes de iniciar.
1.2 Scrumban (simple)
Usar cuando no es posible llegar a ese nivel de certeza por motivos como: fase de soporte/garantía, dependencias externas, cierre de proyecto con backlog volátil, o backlog con alta entrada de trabajo no planificado. En estos casos, el sprint se compone de dos bloques explícitos:
- Bloque A (Planificado): trabajo claro, refinado y estimado antes del inicio del sprint.
- Bloque B (Incertidumbre): trabajo que se refina y planifica “on the fly” con el desarrollador, asignando estimación, fecha de inicio y fecha final igual que si hubiese sido planificado, pero agregado sobre la marcha.
Condición obligatoria: Todo sprint marcado como (Scrumban) debe justificarse durante el sprint previo, dejando constancia de: (1) motivo (backlog incierto, soporte, dependencias, etc.), (2) fechas clave (ej. fin de revisión de cliente, fecha estimada de entrega completa) y (3) distribución prevista entre Bloque A planificado y Bloque B reactivo.
2) Convención de nombres del sprint
- Scrum normal:
SYYMMDD(ej. S250714). - Scrumban:
SYYMMDD (Scrumban)(ej. S250714 (Scrumban)).
La etiqueta de Scrumban solo se usa en el nombre de la lista de cada sprint pero no en la etiqueta que se usa para filtrar en los tableros y estadísticas (Sprint ID).
3) Nuevo uso del campo “Alcance de Sprint”
Se agregan valores para distinguir el trabajo que ingresa durante el sprint sin alterar el compromiso inicial.
3.1 Valores del campo
- Planificada: historia incluida en el plan inicial del sprint.
- Añadida: historia que entra tras la planeación, sustituyendo o forzando un cambio de alcance.
- Retirada: historia que se saca del sprint (para hacer espacio a otra). Termina en UNCOMMITED y se reprograma en el siguiente sprint.
- Reactivo: historia no planificada que ingresa en un sprint marcado como (Scrumban). Se refina y estima en el momento, con fechas de inicio y fin con base en capacidad disponible. Cuenta para métricas de estimación y rollover.
- Pull: cuando se completó el plan planificado o reactivo a tiempo o antes del límite, se jala trabajo para adelantar, pero no se compromete. Si no termina, va a UNCOMMITED y se duplica para el siguiente sprint.
4) Parte I – Flujo cronológico del Sprint
Cada fase incluye acciones mínimas que debe ejecutar el Product Owner (PO) y el equipo, además de los tableros en ClickUp para verificar cumplimiento.
4.0 · Configuración inicial del Sprint (previa al refinamiento)
| Paso | Descripción |
|---|---|
| 0.1 Creación con plantilla | Crear el sprint usando la plantilla “Sprint Template”. Esto genera Custom Fields y Automations predeterminadas. |
| 0.2 Asignar Sprint ID y renombrar | Definir el Sprint ID con el formato SYYMMDD (fecha del lunes de inicio) y renombrar el sprint con el mismo identificador. Si el sprint operará en modo Scrumban, añadir (Scrumban) al nombre. |
| 0.3 Actualizar Automations | Editar las 3 automations de la plantilla para que apunten al Sprint ID actual. Si el ID no existe aún en el dropdown, crearlo antes de guardar los cambios. |
| 0.4 Propagar Sprint ID a las US | Verificar que todas las US dentro del sprint muestren el Sprint ID en el campo correspondiente. |
| 0.5 Justificación Scrumban | Solo si aplica: documentar en la tarjeta del sprint el motivo, fechas clave y porcentaje estimado de Bloque A vs Bloque B. |
4.1 · Refinamiento continuo (durante el sprint previo)
| Paso | Descripción |
|---|---|
| 1.1 Reuniones cortas y frecuentes | Programar micro‑sesiones de refinamiento a lo largo del sprint en curso. Beneficios: menor tiempo de planeación, detección temprana de riesgos y mayor calidad. |
| 1.2 Participación del equipo | Inicialmente pueden asistir solo Tech Lead + PO; el objetivo final es participación del equipo completo para mejores estimaciones colectivas. |
| 1.3 Historias listas antes del sprint | Plazo: todas las US del próximo sprint deben estar redactadas, refinadas y asignadas tentativamente a más tardar el penúltimo día del sprint actual (jueves), calculadas sobre una capacidad bruta de 10 días. Esto permite que durante la planeación la carga se ajuste a la capacidad neta real de 7–7,5 días sin riesgo de quedarse sin historias listas. |
| 1.4 Contenido obligatorio en la US | • Título y descripción funcional completa • Criterios de aceptación claros y medibles • Documento de negocio (business.md) preparado por el PO en el repositorio de GitHub del proyecto • Asignado, fecha de inicio y fecha final • Cambios posteriores se agregan como add‑ons sin borrar histórico • Cambios que alteren significativamente la estimación se convierten en nueva US para el siguiente sprint. |
| 1.5 Revisión de dependencias | En cada refinamiento se analizan dependencias internas o externas que puedan bloquear la ejecución. |
| 1.6 Validación en tableros | El viernes se valida en el Dashboard Sprint Refinement que todas las historias con el Sprint ID actual tengan inicio/fin definidos, y en Sprint Workload que la carga de cada persona cubra de lunes a miércoles de la 2.ª semana. |
4.2 · Planeación del Sprint (primer día laborable)
Aplica igual para Scrum y Scrumban. En Scrumban, el Bloque A se planifica aquí; el Bloque B se deja con capacidad disponible explícita.
| Paso | Descripción |
|---|---|
| 2.0 Agenda operativa del día de planeación | a) Reunión Kick‑off (mañana): 30–45 min por proyecto/persona para que el PO presente cada historia junto con su documentación de negocio (business.md) desde el repositorio de GitHub y el objetivo del sprint. No se dan estimaciones; se resuelven dudas de contexto. b) Bloque de trabajo individual (media mañana‑tarde): Desarrolladores preparan el checklist desglosando historias en tareas atómicas, registran dependencias y preguntas. PO/TL disponibles en canal abierto para resolver dudas al vuelo. c) Reunión de cierre (tarde): (1) revisar y ajustar checklist; (2) consignar estimaciones; (3) definir fechas inicio/fin; (4) dejar plan cerrado en el tablero. |
| 2.1 Bloque de planeación | Todo el lunes (o primer día laborable) se dedica íntegramente a la planeación siguiendo la agenda 2.0. |
| 2.2 Estimación de historias | Las US se estiman en equipo durante la reunión de cierre; solo TL y PO conocen la estimación “de venta”. |
| 2.3 Desglose en tareas | Durante el bloque individual, cada desarrollador crea su checklist de tareas atómicas para evidenciar comprensión. |
| 2.4 Capacidad neta y Time Estimate | Se respeta una capacidad neta de 7–7,5 días (~56 h) por desarrollador hasta el miércoles de la 2.ª semana. Cada tarea debe tener Time Estimate, fecha de inicio y final. Si se usan subtareas, la tarea principal lleva un Time Estimate “cero” (truco 1 s → 0 h). |
| 2.5 Revisión final del sprint | En la reunión de cierre se valida distribución, carga, dependencias y riesgos. |
| 2.6 Visualización con diagramas | Se genera un diagrama (Gantt o calendario) con estimados por desarrollador/historia. |
| 2.7 Manejo de historias no planeadas | En Scrum: solo se incorpora si la capacidad lo permite sin comprometer historias planificadas y se marca como Pull. En Scrumban, si entra dentro de la ventana Lun 1.ª semana – Mié 2.ª semana, marcar como Reactivo; si entra después de terminar el plan independiente de que sea planificado o reactivo, marcar como Pull. |
| 2.8 Asignación definitiva de historias | Al finalizar la reunión de cierre cada dev debe tener todas sus US del Bloque A asignadas y marcadas como Planificadas. En Scrumban, se deja capacidad reservada para el Bloque B. |
| 2.9 Validación en tableros | Verificar en Dashboard Sprint Planning: todas las tareas con Time Estimate, ocupación ≈ 56 h por persona. En Sprint Workload las tareas cubren del martes al miércoles de la 2.ª semana. |
4.3 · Ejecución y seguimiento (del martes 1.ª semana al miércoles 2.ª semana)
| Paso | Descripción |
|---|---|
| 3.1 Monitor de progreso | Dashboard Sprint Tracking refleja la transición de las US entre estados y Sprint Workload muestra si se cumplen fechas inicio/fin. |
| 3.2 Gestión de cambios | Cualquier cambio de alcance debe reflejarse en el campo Alcance Sprint usando estos valores: • Planificada (valor por defecto) • Añadida (se incorpora tras la planeación, por intercambio) • Retirada (se saca del sprint para hacer espacio a otra US) • Pull (se jala voluntariamente una US del siguiente sprint cuando existe capacidad adicional) • Reactiva (en caso de Scrumban son las tareas que se agregan sobre la marcha). Procedimiento especial para Retirada y Pull no finalizado: 1. Cambiar el estado final de la US original a Uncommited. 2. Clonar la US y relacionarla con la original mediante el campo Historia Origen. 3. Mover la copia al sprint siguiente y, si aplica, reestimar solo el trabajo pendiente. |
| 3.3 Bloque B (Scrumban) | Cuando aparezcan tickets Reactivo (Lun 1.ª – Mié 2.ª): refinar al momento, estimar con el dev, asignar fechas de inicio/fin según capacidad. Cuando se libere capacidad (antes del jueves 2.ª semana o si ya terminó el compromiso), hacer Pull siguiendo el mismo rigor de estimación/fechas. |
| 3.4 Buffer y Pull | El jueves de la 2.ª semana se mantiene como buffer. Si todo termina antes, se puede realizar Pull. Cualquier Pull debe quedar marcado como tal y seguir el flujo normal hacia Done o Uncommited. |
4.4 · Cierre del sprint (viernes 2.ª semana)
| Paso | Descripción |
|---|---|
| 4.1 Demo y retrospectiva | Se realiza demo funcional, retrospectiva y revisión de métricas. |
| 4.2 Registro de métricas | Se registran US completadas, velocidad, defectos, cumplimiento de estimaciones, rollovers, separando Planificadas/Añadidas/Retiradas de Reactivo/Pull. |
| 4.3 Estado final de historias | Toda US debe terminar en Done, Rollover o Uncommited. Done: completada y aceptada. Rollover: no se completa; clónala, relaciónala a Historia Origen, asigna el Sprint ID del siguiente sprint y estima solo el trabajo pendiente. Uncommited: historias Retiradas o Pull inconclusas. No se trasladan; se crea una copiasegún la sección 3.3. |
| 4.4 Validación de Alcance | En Dashboard Sprint Metrics 1 se evalúa el porcentaje de historias Planificadas, Añadidas, Retiradas, Reactivo y Pull. |
| 4.5 Defectos | Los defectos se crean como tipo Defecto, relacionan Historia Origen y registran Responsables. Se analizan en Dashboard Sprint Metrics 2, contados por fecha de creación. |
5) Métricas clave (se mantienen para todos los tipos de historias, incluidas Reactivo y Pull)
- Rollover.
- Defectos.
Nota: En Scrumban el cumplimiento de estimación y los rollovers se miden también para el Bloque B. No se diluye la responsabilidad del desarrollador en la calidad de su estimación a pesar de la incertidumbre.
6) Gobernanza y controles
- Sprints Scrumban deben aprobarse y justificarse antes de iniciar.
- Transparencia: cada ticket Reactivo o Pull debe llevar estimación, fechas de inicio/fin y responsable. El plan “sobre la marcha” debe poder auditarse igual que el plan inicial.
- Visibilidad en el nombre del sprint:
SYYMMDD (Scrumban). - Dashboards obligatorios para supervisión continua.
7) Parte II – Lineamientos complementarios
A. Alineación global de Sprints
- Todos los proyectos/personas comparten la misma cadencia; inician y terminan el mismo día (no se permiten sprints cruzados).
- Planeaciones y cierres simultáneos: planeación el primer día laborable y cierre el último.
- Se planifica la capacidad global de colaboradores que participan en varios proyectos.
- Nombramiento estándar: SYYMMDD y, si aplica, (Scrumban).
B. Integración de roles en historias de usuario
- Unificación de componentes (FE, BE, BD, QA) cuando sea viable.
- Valor independiente para cada US si la integración total no es factible.
- Excepciones justificadas: repos iniciales, configuraciones, prototipos, etc., previo acuerdo del equipo.
C. Gestión del tiempo y capacidad del Sprint
| Concepto | Valor |
|---|---|
| Duración estándar | 2 semanas (10 días laborables) |
| Capacidad bruta dev | 10 días |
| Deducciones | Planeación (½–1 d), Cierre (1 d), Margen imprevistos (1 d) |
| Capacidad neta | 7 – 7,5 días (~56 h) |
La unidad mínima de planificación es ½ día; subdividir más genera overhead.
D. Ejecución y manejo de cambios
- Decisiones técnicas de alto nivel requieren aprobación Tech Lead + Arquitecto.
- Se permite crear US de tipo Prototype/PoC para validar factibilidad en ≤ 1 sprint.
E. Seguimiento del progreso del proyecto
- El PO mide avance comparando US completadas vs. totales ponderadas por estimación.
- Todas las US y tareas viven en ClickUp con owner, fechas y Sprint ID.
- Basado en la velocidad real, el PO ajusta fecha estimada de finalización y comunica riesgos.
F. Defectos y calidad
Cada Defecto:
- se crea como tipo Defecto;
- relaciona Historia Origen;
- registra Responsables.
Se monitorean en Sprint Metrics 2.
G. Estados de Alcance del Sprint (resumen)
| Estado | Uso |
|---|---|
| Planificada | Historia definida y aprobada durante la planeación. |
| Añadida | Se incorpora tras la planeación inicial por intercambio u obligación externa. |
| Retirada | Se retira para hacer espacio a otra US. La original termina en Uncommited; se duplica la copia al siguiente sprint. |
| Reactivo | Aplica para sprints Scrumban y se agrega dentro del periodo planificable. Si se compromete para el sprint. |
| Pull | Se jala desde el siguiente sprint cuando hay capacidad adicional. No compromete. Si no se finaliza, va a Uncommited y se duplica. |
H. Dashboards clave
| Tablero | ¿Qué valida? |
|---|---|
| Sprint Refinement | Historias con inicio/fin definidos antes del viernes. |
| Sprint Planning | Time Estimate + capacidad ≈ 56 h por persona. |
| Sprint Workload | Distribución diaria de tareas (refinamiento, planeación y ejecución). |
| Sprint Tracking | Movimiento de historias entre estados durante el sprint. |
| Sprint Metrics 1 | Planificadas vs. Retiradas vs. Añadidas vs. Reactivo vs. Pull; % Done vs. Rollover vs. Uncommited. |
| Sprint Metrics 2 | Número y tendencia de Defectos creados. |
I. Glosario rápido
| Término | Definición breve |
|---|---|
| US (User Story) | Funcionalidad descrita desde la perspectiva del usuario final. |
| Sprint ID | Identificador único de sprint (formato SYYMMDD + opcional (Scrumban)). |
| PO (Product Owner) | Maximiza el valor del producto y gestiona el backlog. |
| Tech Lead | Líder técnico responsable de arquitectura y alineamiento. |
| QA (Quality Assurance) | Garantiza la calidad mediante pruebas y validaciones. |
| Defecto | Incidencia surgida tras desarrollo, ligada a la Historia Origen. |
| Alcance Sprint | Custom Field que indica si la US está Planificada, Añadida, Retirada, Reactivo o Pull. |
| Done / Rollover / Uncommited | Estados finales posibles de una US. |
| Velocity | Puntos/historias completadas en un sprint. |
| Capacity | Tiempo disponible del equipo tras deducciones. |
| Pull | Acción de adelantar una US del siguiente sprint sin compromiso. |
| Reactivo | Trabajo no planificado que se incorpora en sprint (Scrumban), con estimación y fechas. |
| Gantt | Diagrama de barras de planificación temporal. |
| Demo | Presentación funcional de avances al final del sprint. |
8) Beneficios de esta propuesta
- Mantienes Scrum puro donde tiene sentido (claridad y predictibilidad).
- En la incertidumbre, no abandonas la disciplina de estimar, medir rollovers y calidad —simplemente planificas cuando aparece el trabajo.
- Visibilidad explícita de los sprints con incertidumbre (nomenclatura + justificación previa).
- Trazabilidad total del Bloque B gracias a fechas, estimaciones y métricas equivalentes a las historias planificadas.
9) Resumen
Con esta actualización, Brace garantiza:
- Historias bien definidas antes del sprint cuando hay certeza, y capacidad explícita para gestionar incertidumbre bajo Scrumban simple.
- Planeación uniforme mediante la plantilla estandarizada, nomenclatura clara y uso correcto de Sprint ID.
- Control estricto de capacidad y métricas homogéneas (incluyendo Reactivo y Pull) para proteger la responsabilidad en la estimación y el control de rollovers.
- Cierre disciplinado y auditable con dashboards que reflejan tanto el compromiso inicial como el trabajo incorporado sobre la marcha.