Pilares del Empirismo y Valores Fundamentales para equipos de alto rendimiento
El norte a seguir: fundamentos que deben establecerse antes del primer Sprint
Antes de iniciar el primer Sprint, el equipo debe establecer bases sólidas que guiarán todo el proyecto. Estas pautas no son opcionales — son el cimiento sobre el cual se construye un Scrum exitoso.
El equipo debe estar completo y correctamente constituido antes de iniciar. No hay Scrum sin los tres roles definidos.
Todo el equipo debe entender claramente qué se está construyendo y por qué. La visión es la estrella polar del proyecto.
El Product Backlog es el corazón de Scrum. Debe existir un backlog inicial suficiente para comenzar el primer Sprint.
El DoD es el estándar de calidad compartido. Sin él, no hay forma de saber cuándo el trabajo está realmente terminado.
La duración del Sprint debe ser consistente y apropiada para el contexto. Una vez definida, no debe cambiar durante el proyecto.
El equipo necesita las herramientas y el ambiente adecuado para ser productivo desde el día uno.
Los acuerdos de trabajo definen cómo el equipo colaborará. Son el contrato social que rige la convivencia.
Los stakeholders deben conocer Scrum, entender su rol, y comprometerse a participar en los eventos apropiados.
Aunque controversial, un período de preparación puede ser valioso para proyectos complejos. No es un Sprint de Scrum formal.
El flujo iterativo e incremental para entregar valor de forma continua
El Product Owner prioriza el Product Backlog. El equipo selecciona elementos para crear el Sprint Backlog. Durante el Sprint, el equipo se sincroniza diariamente en la Daily Scrum. Al final, se entrega un Incremento potencialmente liberable.
Cada artefacto representa trabajo o valor y está diseñado para maximizar la transparencia.
Lista emergente y ordenada de todo lo necesario para mejorar el producto. Es la única fuente de trabajo para el Scrum Team.
Product Goal: El objetivo a largo plazo del producto. Describe el estado futuro que sirve como meta para el equipo.
Compuesto por el Sprint Goal, los elementos seleccionados del Product Backlog, y el plan para entregar el Incremento.
Sprint Goal: El único objetivo del Sprint. Proporciona flexibilidad sobre el trabajo exacto mientras mantiene coherencia y foco.
Un paso concreto hacia el Product Goal. Cada Incremento es aditivo a los anteriores y debe ser utilizable.
Definition of Done: Descripción formal del estado requerido para que el Incremento cumpla las medidas de calidad.
Eventos formales para inspeccionar y adaptar. Todos tienen un timebox máximo que no puede excederse.
Contenedor de todos los demás eventos. Un Sprint comienza inmediatamente después del anterior. Todo el trabajo necesario para alcanzar el Product Goal ocurre dentro de los Sprints.
Inicia el Sprint definiendo el trabajo a realizar. Se responden tres preguntas: ¿Por qué es valioso este Sprint? ¿Qué se puede hacer? ¿Cómo se hará el trabajo?
Evento diario para inspeccionar el progreso hacia el Sprint Goal y adaptar el Sprint Backlog según sea necesario. Mismo lugar, misma hora, todos los días.
Inspeccionar el resultado del Sprint y determinar futuras adaptaciones. El equipo presenta el Incremento a los stakeholders y se discute el progreso hacia el Product Goal.
Planificar formas de aumentar la calidad y efectividad. El equipo inspecciona cómo fue el último Sprint en cuanto a personas, interacciones, procesos y herramientas.
El fundamento sobre el cual construimos la gestión de lo complejo
El proceso y el trabajo emergente deben ser visibles tanto para quienes realizan el trabajo como para quienes lo reciben.
Los artefactos y el progreso hacia las metas deben inspeccionarse con frecuencia para detectar variaciones o problemas.
Si algún aspecto del proceso se desvía fuera de los límites aceptables, el proceso debe ajustarse lo antes posible.
El alma del equipo que da vida al framework y sostiene la colaboración
El equipo se compromete a lograr sus metas y a apoyarse mutuamente. Es dedicación genuina, no promesa de resultados imposibles.
Los miembros del equipo tienen el coraje de hacer lo correcto y trabajar en problemas difíciles aunque sea incómodo.
Todos se enfocan en el trabajo del Sprint y en las metas del equipo. La concentración es un superpoder.
El equipo y sus stakeholders son abiertos sobre el trabajo y los desafíos. No hay agendas ocultas.
Los miembros se respetan mutuamente como personas capaces e independientes.
Los actores que intervienen en un desarrollo profesional con Scrum (Guía Scrum 2020)
El Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum. Lo logra ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Scrum Team como en la organización. Es un líder servidor del Scrum Team y de la organización en general.
El Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Scrum Team. Es la única persona responsable de gestionar el Product Backlog. Representa las necesidades de los stakeholders y es el responsable de la visión del producto.
Los Developers son las personas del Scrum Team que se comprometen a crear cualquier aspecto de un Incremento utilizable en cada Sprint. Son profesionales autoorganizados y multifuncionales que poseen todas las habilidades necesarias para crear valor en cada Sprint.
Cómo identificar y evitar el "Waterfall disfrazado de Ágil" — Referencia: SAFe 4.0
Uno de los errores más comunes al implementar Scrum es mantener la mentalidad de fases secuenciales aunque se trabaje en Sprints. Tener iteraciones no garantiza agilidad — lo que importa es cómo trabaja el equipo dentro de ellas.
Cada iteración se dedica a una sola fase del desarrollo. La Iteración 1 es solo análisis, la 2 solo desarrollo, la 3 solo pruebas, etc.
Dentro de cada Sprint, el trabajo fluye en fases secuenciales: primero los analistas definen todo, luego los desarrolladores construyen, y al final los testers prueban.
Definir, Construir y Probar ocurren simultáneamente para cada funcionalidad. El equipo trabaja junto en pequeños incrementos: se toma una historia, se define, se construye, se prueba y se completa antes de pasar a la siguiente.
| Aspecto | ❌ Waterfall Disfrazado | ✅ Verdadero Ágil |
|---|---|---|
| Flujo de trabajo | Secuencial por fases | Paralelo por funcionalidad |
| Entrega de valor | Al final del proyecto | Continua, cada Sprint |
| Descubrimiento de problemas | Tarde (fase de pruebas) | Temprano (mismo día) |
| Colaboración | Mínima (silos por rol) | Constante (equipo integrado) |
| Estructura del equipo | Especialistas aislados | Multifuncional integrado |
| Respuesta al cambio | Costosa y resistida | Natural y bienvenida |
| Burndown chart | Baja solo al final | Descenso gradual y constante |
Sabiduría práctica que solo se aprende en el campo de batalla
La Guía Scrum tiene solo 13 páginas. Pero dominar Scrum toma años de práctica. Estas son las lecciones que no están en los libros — verdades que se aprenden cuando el framework se encuentra con la realidad.
Las reglas son pocas y claras. Lo difícil es cambiar hábitos, mentalidades y culturas organizacionales. La simplicidad del framework expone las disfunciones que antes se ocultaban.
Cuando el equipo correcto está reunido y preparado, el valor es enorme. El problema no son los eventos — es cuando falta gente, no se preparan, o se extienden innecesariamente.
Scrum funciona a nivel de un equipo (máximo 10 personas). Para coordinar múltiples equipos existen frameworks de escalado como SAFe, LeSS o Nexus. No intentes forzar Scrum a nivel empresa.
No existen dos historias con la misma prioridad. El Product Backlog es una lista ordenada, no agrupada. Si todo es prioridad 1, nada es prioridad 1. El PO debe tomar decisiones difíciles.
"Si terminamos el Sprint, es porque estamos en producción"
"Terminado" no significa "listo para probar" o "casi listo". Significa que el incremento cumple con todos los criterios de calidad y podría liberarse a producción hoy mismo si el PO lo decide.
Pregunta clave: ¿Qué significa haber terminado una historia de usuario en TU equipo? Si cada persona tiene una respuesta diferente, no tienen un Definition of Done real.
"SIEMPRE ES PRIORITARIO CERRAR QUE ABRIR"
Este principio de Lean Manufacturing es oro puro para Scrum: termina lo que empezaste antes de empezar algo nuevo. Limitar el Work in Progress (WIP) es clave para el flujo.
"Es mejor iterativo que cascada" — pero ágil es aún mejor. Entender esta evolución ayuda a apreciar por qué Scrum funciona como funciona.
Waterfall
RUP, Espiral
Scrum, XP, Kanban
"No es posible hacer Scrum solo con los programadores. Se deben incluir soportes y stakeholders"
Un Scrum Team debe tener todas las habilidades necesarias para crear valor en cada Sprint. Si dependes de equipos externos para terminar, no eres realmente autónomo.
Si el equipo de desarrollo "termina" pero luego QA encuentra bugs, o Soporte no sabe usar la funcionalidad, o los manuales no existen — no está realmente terminado.
Las métricas en Scrum no son para castigar — son para inspeccionar y adaptar. Medimos para saber dónde estamos y qué nos falta para llegar a la meta.
Muestra el trabajo restante vs. tiempo. Si la línea no baja, algo está mal.
¿Vamos a cumplir el objetivo? Es la pregunta diaria en la Daily.
Puntos completados por Sprint. Sirve para planificar, no para comparar equipos.
Tiempo desde que se empieza una historia hasta que está Done. Menor = mejor flujo.
Diccionario completo de términos y conceptos con ejemplos prácticos
Referencia completa de términos de Scrum y metodologías ágiles. Cada concepto incluye definición, ejemplos y consejos de uso.
Líder servidor responsable de establecer Scrum. Ayuda al equipo y organización a comprender la teoría y práctica.
Facilita la Daily, protege al equipo de interrupciones y remueve impedimentos con gerencia.
Tratarlo como jefe del equipo
Empoderarlo para cambiar procesos
Responsable de maximizar el valor del producto. Única persona que gestiona el Product Backlog.
Decide que renovación tiene más valor que reportes basado en feedback de clientes.
PO sin autoridad real para priorizar
PO disponible y con poder de decisión
Profesionales que crean el Incremento. Autoorganizados y multifuncionales. Tamaño: 3-9 personas.
Incluye programadores, QA, DBA y UX. Juntos deciden cómo implementar cada historia.
Pensar que solo son programadores
Todas las habilidades necesarias
Contenedor de tiempo fijo (máx 4 semanas) donde se crea un Incremento. Corazón de Scrum.
Sprints de 2 semanas. Inicia lunes con Planning, termina viernes con Review y Retro.
Cambiar duración frecuentemente
Duración fija para ritmo predecible
Inicia el Sprint definiendo qué y cómo. Timebox: 8h (4 sem) / 4h (2 sem).
Sprint Goal: "Renovación online". Seleccionan 5 historias y desglosan las tareas técnicas.
PO impone historias sin negociar
Developers eligen cuánto comprometer
Evento diario de 15 minutos para sincronizar y adaptar. Mismo lugar, misma hora.
9:00 AM. Juan está bloqueado esperando acceso a la API. María ofrece ayudar.
Reporte de estado al SM
Conversación entre Developers
Inspeccionar Incremento con stakeholders y obtener feedback. Timebox: 4h (4 sem) / 2h (2 sem).
Demo de renovación al gerente. Sugiere agregar descuento — se agrega al backlog.
Presentar PowerPoints
Demo en vivo del software
Planificar mejoras de calidad y efectividad. Timebox: 3h (4 sem) / 1.5h (2 sem).
Identifican que pruebas manuales causan retrasos. Acuerdan implementar automatización.
Identificar mejoras pero no implementar
Al menos una mejora por Sprint
Lista ordenada de todo lo necesario para el producto. Única fuente de trabajo. Compromiso: Product Goal.
87 historias ordenadas por valor. Las primeras 10 refinadas; las del fondo sin detallar.
Múltiples backlogs o empates
Un solo backlog ordenado
Sprint Goal + elementos seleccionados + plan de entrega. Propiedad de Developers. Compromiso: Sprint Goal.
5 historias que suman 21 puntos, desglosadas en tareas en nuestro tablero Kanban.
PO modifica sin consultar
Solo Developers modifican
Paso concreto hacia el Product Goal. Cumple DoD, utilizable y potencialmente liberable.
Módulo de renovación completo: código revisado, pruebas pasando, desplegado en staging.
Entregar código "casi listo"
Podría ir a producción hoy
Objetivo a largo plazo del producto. Describe el estado futuro que sirve como meta para planificar.
"Ser la plataforma líder de seguros online en RD para Q4 2026, 100% digital."
No tener Product Goal o tener varios
Un solo Product Goal claro
Único objetivo del Sprint. Proporciona flexibilidad mientras crea coherencia y foco.
"Permitir renovación de póliza completamente online sin necesidad de llamar."
Goal genérico: "completar historias"
Goal que expresa el valor
Descripción formal del estado de calidad que debe alcanzar el Incremento para considerarse terminado.
Código revisado, unit tests >80%, integración pasando, desplegado en staging, docs actualizados.
Cada persona define "terminado"
DoD escrito, visible y respetado
Metodología secuencial tradicional: requisitos → diseño → desarrollo → pruebas → despliegue.
6 meses análisis, 4 diseño, 8 desarrollo, 3 pruebas. Usuario ve el producto tras 21 meses.
Feedback tardío, alto riesgo
Requisitos muy estables
Valores y principios del Manifiesto Ágil (2001): individuos, software funcionando, colaboración, respuesta al cambio.
Scrum, Kanban y XP implementan valores ágiles. Son formas de practicar Agile, no sinónimos.
Agile = no documentar ni planificar
Documentación suficiente, plan adaptativo
Filosofía de eliminar desperdicios y maximizar valor al cliente. Origen: Toyota. Principio clave: flujo continuo.
"Cerrar antes que abrir": terminar trabajo en curso antes de empezar nuevo. Reduce el WIP.
Código no desplegado, features no usados
Incrementos pequeños frecuentes
Método visual para gestionar flujo: visualizar trabajo, limitar WIP, optimizar flujo. Sin roles ni eventos prescritos.
Tablero: To Do | In Progress (máx 3) | Review | Done. Si hay 3 en progreso, no se empieza otro.
Tablero Kanban sin límites de WIP
Definir y respetar límites por columna
Metodología ágil enfocada en prácticas técnicas: TDD, pair programming, integración continua, refactoring.
Equipos Scrum adoptan prácticas XP: TDD para calidad, pair programming para compartir conocimiento.
Scrum sin prácticas técnicas sólidas
Combinar Scrum (gestión) + XP (técnicas)
Framework para escalar Agile a nivel empresarial. Coordina múltiples equipos mediante ARTs y PI Planning.
Empresa con 15 equipos Scrum usa SAFe. Cada 10 semanas hacen PI Planning para alinear objetivos.
SAFe sin dominar Scrum básico primero
Dominar Scrum antes de escalar
Lista de criterios que debe cumplir un elemento para considerarse "terminado". Si no cumple, no puede liberarse.
DoD: ✓ Code review ✓ Tests >80% ✓ Sin bugs críticos ✓ Docs ✓ Staging
"Done" significa diferente para cada uno
DoD visible y acordado por todos
Criterios para que un elemento esté listo para el Sprint. No es oficial de Scrum pero es práctica común.
DoR: ✓ Criterios de aceptación ✓ Estimada ✓ Sin dependencias ✓ Cabe en Sprint
DoR como excusa para no refinar
DoR ligero que facilita, no bloquea
Trabajo en curso: elementos empezados pero no terminados. Limitarlo es clave para el flujo.
Límite WIP = 3. Si tienes 3 tareas en progreso, debes terminar una antes de empezar otra.
Muchas tareas "en progreso"
"Stop starting, start finishing"
Producto Mínimo Viable: versión con características mínimas para validar hipótesis con usuarios reales.
MVP de cotizador: solo un tipo de vehículo, sin pasarela de pago. Suficiente para validar demanda.
MVP = producto de mala calidad
Mínimo en scope, máximo en calidad
CI: integrar código frecuentemente con tests automáticos. CD: automatizar despliegue a producción.
Push a Git → Jenkins ejecuta tests → Si pasan, despliega a staging → Click para producción.
CI sin tests automatizados
Pipeline: build, test, deploy
Elemento del Product Backlog: puede ser User Story, bug, spike o cualquier trabajo que aporte valor.
"Ver historial de pólizas" (story), "Error en cálculo de prima" (bug), "Investigar API" (spike).
Solo User Stories, ignorando bugs
Todo el trabajo en un solo backlog
Retorno de Inversión: relación entre valor obtenido y costo invertido. PO prioriza maximizando ROI.
Historia A: alto valor, bajo esfuerzo = alto ROI → priorizar. Historia B: bajo valor, alto esfuerzo → postergar.
Priorizar solo por valor
Balancear valor, esfuerzo, riesgo
Conocimiento viene de la experiencia. Decisiones basadas en lo observado. Pilares: Transparencia, Inspección, Adaptación.
En lugar de planificar 12 meses, planifica 2 semanas, inspecciona resultado, adapta.
Seguir plan aunque realidad cambió
Adaptar basado en evidencia
Formato: "Como [rol], quiero [acción], para [beneficio]". No es oficial de Scrum pero es práctica común.
"Como cliente, quiero renovar mi póliza online, para no tener que llamar a la oficina."
"Como sistema, quiero una BD..."
Perspectiva del usuario real
Desglosar, detallar y estimar elementos del backlog. No es evento formal. Máximo 10% del Sprint.
Cada miércoles refinan historias de los próximos 2 Sprints: agregan criterios y estiman.
Refinar todo con igual detalle
Más detalle = más cerca del tope
Duración máxima fija para un evento. No puede excederse. Crea urgencia y foco.
Daily tiene timebox de 15 min. Si no terminaron, se corta y continúan offline.
Extender "solo 5 minutos más"
Respetar timebox siempre
Cantidad de trabajo (Story Points) completado por Sprint. Sirve para planificar, NO para comparar equipos.
Promedio últimos 3 Sprints: 21 puntos. Para el próximo, planificamos entre 19-23.
Comparar velocidad entre equipos
Solo para planificación interna
Obstáculo que bloquea o ralentiza el progreso del equipo. El SM ayuda a removerlos.
"No tenemos acceso a la BD de producción" es impedimento. SM trabaja con IT para resolverlo.
Esperar que SM resuelva todo
Equipo resuelve lo que puede
Persona interesada en el producto que no es parte del Scrum Team. Clientes, usuarios, gerentes.
Gerente de ventas, equipo de soporte, clientes beta, departamento legal, marketing.
Stakeholders dan órdenes directas
Todo pasa por el PO al backlog
Trabajo pendiente por atajos tomados. Como deuda financiera: crece con intereses si no se paga.
"Hardcodeamos esto para cumplir, después lo arreglamos." Ese "después" es deuda que se acumula.
Ignorar hasta que paraliza
Pagar un poco cada Sprint
Estimación colaborativa: cada persona muestra su estimación simultáneamente con cartas. Fomenta discusión.
Juan muestra 3, María 8. Discuten: María ve complejidad oculta. Convergen en 5.
El senior habla primero e influye
Todos muestran cartas al mismo tiempo
Gráfico: trabajo restante vs. tiempo. La línea debe bajar hacia cero al final del Sprint.
Día 1: 21 pts. Día 5: 15 pts. Día 10: 0 pts. Si línea es plana, algo está bloqueado.
Burndown sube (agregan trabajo)
Scope fijo durante el Sprint
Investigación técnica timeboxeada para reducir incertidumbre. Resultado: conocimiento, no código.
Spike 2 días: "¿La API soporta renovaciones?" Resultado: documento con hallazgos y recomendación.
Spikes sin timebox, nunca terminan
Timebox estricto, entregable claro
Dos developers en el mismo código. Uno escribe (driver), otro revisa (navigator). Rotan frecuentemente.
Juan (junior) y María (senior) trabajan juntos. Juan escribe, María guía. Aprende patrones en vivo.
Uno trabaja mientras otro ve celular
Ambos activamente involucrados
Test primero: escribes test que falla → código mínimo para pasar → refactorizar. Red-Green-Refactor.
1) Test: calcularPrima(auto)=5000 (falla). 2) Código mínimo. 3) Refactor sin romper test.
Escribir tests después del código
Test primero, siempre
Unidad relativa para estimar complejidad. No son horas. Escala Fibonacci: 1,2,3,5,8,13,21.
Historia referencia = 3 puntos. Nueva historia "el doble de compleja" = 5 u 8 (no 6).
1 punto = 1 hora
Puntos son relativos entre historias
Historia grande que no cabe en un Sprint. Debe dividirse en historias más pequeñas.
Épica: "Gestión de pólizas". Se divide: cotizar, comprar, renovar, cancelar, historial.
Meter épica completa en un Sprint
Dividir hasta que cada parte quepa
Cantidad de trabajo que el equipo puede asumir, considerando vacaciones, feriados, reuniones.
Normal: 21 pts. Este Sprint: Juan de vacaciones + feriado. Capacidad reducida: ~16 pts.
Asumir 100% disponibilidad siempre
Calcular capacidad real cada Sprint
Plan de alto nivel a largo plazo. Muestra qué funcionalidades y cuándo. Es adaptativo, no contrato fijo.
Q1: Cotización online. Q2: Compra y pago. Q3: Renovación. Q4: App móvil.
Roadmap como fechas comprometidas
Roadmap como visión, no contrato
Liberación de versión a usuarios. En Scrum, cada Sprint produce Incremento potencialmente liberable.
Releases cada 2 Sprints (mensual). Cada release incluye incrementos de los últimos 2 Sprints.
Acumular para "big bang" release
Releases frecuentes y pequeños
Condiciones específicas para que una historia esté completa. Escritos antes del desarrollo, verificables.
Renovar póliza: ✓ Muestra descuento ✓ Acepta tarjeta ✓ Envía email de confirmación.
Criterios vagos: "debe funcionar"
Específicos y verificables
Tiempo desde que se empieza una historia hasta Done. Menor cycle time = mejor flujo y predictibilidad.
Historia empezó lunes, terminó jueves = 4 días. Si promedio es 6 días, esta fue más rápida.
Historias "en progreso" por semanas
Historias pequeñas = cycle time bajo
Guía paso a paso para iniciar un proyecto Scrum desde cero
La teoría cobra vida cuando la aplicamos. En esta sección, planificaremos un proyecto real paso a paso: identificaremos los actores, definiremos el Product Backlog, planificaremos el primer Sprint y estableceremos el Definition of Done.
Producción del audiolibro "Historias del Caribe" - 10 capítulos
Una editorial quiere producir su primer audiolibro. Tienen el libro físico ya publicado, y necesitan convertirlo en formato de audio profesional para plataformas como Audible, Spotify y Apple Books. El proyecto incluye narración, edición, música y distribución.
¿Quiénes conforman el Scrum Team y quiénes son los Stakeholders?
Antes de escribir una sola línea en el backlog, debemos definir claramente quién es quién. Cada rol tiene responsabilidades específicas que no deben mezclarse.
¿Cuál es la visión a largo plazo del producto?
El Product Goal es el norte que guía todas las decisiones. Debe ser ambicioso pero alcanzable, y todos deben entenderlo.
¿Qué trabajo necesitamos hacer para alcanzar el Product Goal?
El PO crea y ordena el backlog basándose en el valor para el usuario. Las historias del tope están más detalladas; las del fondo son ideas generales.
¿Cuándo consideramos un capítulo realmente "terminado"?
El DoD es el estándar de calidad que todo el equipo respeta. Si no cumple todos estos criterios, no está "Done".
¿Qué podemos entregar en las próximas 2 semanas?
En el Sprint Planning, el equipo selecciona las historias que puede completar y define el Sprint Goal.
¿Cómo se ven los eventos Scrum en este proyecto?
Cada evento tiene un propósito específico. Veamos cómo se aplicarían en nuestro proyecto de audiolibro.
Ejercicio guiado completo - Sistema de Inventario "StockMaster"
Acompáñanos en esta simulación completa donde verás cómo un equipo implementa Scrum desde el día cero hasta poner un producto en producción. Observarás cada rol en acción, cada evento ejecutándose, y cada artefacto evolucionando a lo largo de 4 Sprints.
RetailMax es una cadena de tiendas de electrodomésticos con 5 sucursales en el país. Actualmente manejan el inventario en hojas de Excel, lo que causa:
| # | Historia de Usuario | Puntos | Prioridad |
|---|---|---|---|
| 1 | Login de usuarios Como usuario, quiero iniciar sesión para acceder al sistema de forma segura. |
5 | ALTA |
| 2 | Registrar entrada de productos Como almacenista, quiero registrar productos que llegan para actualizar el inventario. |
8 | ALTA |
| 3 | Registrar salida de productos Como vendedor, quiero registrar ventas para descontar del inventario automáticamente. |
8 | ALTA |
| 4 | Consultar stock en tiempo real Como gerente, quiero ver el stock actual de cualquier sucursal para tomar decisiones. |
5 | ALTA |
| 5 | Alertas de stock bajo Como gerente, quiero recibir alertas cuando un producto esté por agotarse. |
5 | MEDIA |
| 6 | Transferencias entre sucursales Como gerente, quiero transferir productos entre tiendas para balancear inventario. |
13 | MEDIA |
| 7 | Reportes de movimientos Como contador, quiero ver reportes de entradas y salidas para auditoría. |
8 | MEDIA |
| 8 | Escaneo de código de barras Como almacenista, quiero escanear productos para agilizar el registro. |
8 | BAJA |
| 9 | Dashboard ejecutivo Como gerente general, quiero un dashboard con KPIs de inventario. |
13 | BAJA |
| Total del Backlog | 73 pts | 9 historias | |
Asisten: Scrum Team + Roberto (Gerente General) + 2 Gerentes de tienda
Solo Scrum Team (sin stakeholders)
Fernando coordinó con IT antes del Sprint.
Diana entregó mockups 2 días antes del Planning.
API documentada automáticamente.
Fernando coordinó con IT para instalar Chrome en todas las tiendas. El equipo pudo continuar sin retrasos.
De 73 puntos iniciales, quedaron 4 puntos (escaneo de código de barras) para un futuro release.
"La priorización constante fue clave. Pudimos entregar el 95% del valor en la mitad del tiempo que hubiéramos tardado con el método anterior."
"Las retrospectivas realmente funcionan. Cada Sprint mejoramos algo concreto. El equipo se autoorganizó mejor de lo que esperaba."
"El Definition of Done nos salvó de entregar código a medias. Al principio parecía estricto, pero evitó muchos problemas."
"Estar involucrada desde el inicio fue diferente. No esperaba al final para probar, sino que participaba en todo el proceso."
StockMaster está en producción. El Product Goal se cumplió: las 5 sucursales ahora tienen visibilidad en tiempo real de su inventario.
Scrum es un proceso continuo. El Product Backlog sigue evolucionando con nuevas necesidades: