Grooming de tareas en desarrollo móvil: qué es, objetivos y proceso de realización

¿Qué es el grooming de tareas?

Backlog Grooming (refinement) es el proceso de preparar las tareas del Product Backlog para futuros sprints. Es una reunión en la que el Product Owner y el equipo de desarrollo revisan las tareas: aclaran requisitos, añaden Acceptance Criteria, estiman complejidad, identifican dependencias y riesgos. No hay un evento obligatorio llamado “grooming” en la Scrum Guide — es una práctica adicional que los equipos Scrum adoptan para reducir la incertidumbre en Sprint Planning. La frecuencia recomendada es una vez por sprint, con una duración máxima de 60 minutos.

El término “grooming” (refinamiento) refleja la esencia: el equipo “peina” el backlog, eliminando tareas obsoletas, aclarando las dudosas y dividiendo las demasiado grandes. En el desarrollo móvil, el grooming es especialmente importante debido a las particularidades de la plataforma: una tarea para Android puede diferir en complejidad de su versión para iOS, y hay que considerar targetSdk, compileSdk y la compatibilidad con niveles de API. Sin grooming, Sprint Planning se convierte en un caos: el equipo ve las tareas por primera vez y no puede estimarlas, lo que genera imprevisibilidad y retrasos.

El resultado del grooming son varias tareas listas para Sprint Planning: tienen descripción, Acceptance Criteria, estimación y cumplen con Definition of Ready. El Product Owner debe refinar las tareas por orden de prioridad: las más cercanas al sprint actual deben ser las más detalladas. Las tareas para 3–4 sprints adelante deben estar solo a nivel de épica. Técnica de Progressive Refinement: cuanto más cerca esté una tarea del sprint, más detallada debe ser su descripción. Para tareas del sprint actual — refinamiento completo (AC, diseño, especificación API). Para tareas a 2 sprints — nivel de historia (user story sin detalles de implementación). Para tareas a 3+ sprints — nivel de épica (solo nombre y valor de negocio).

Definition of Ready: cuándo una tarea está lista para el sprint

Definition of Ready (DoR) es una lista de verificación de criterios que debe cumplir una tarea antes de incluirse en el Sprint Backlog. DoR es un contrato entre el Product Owner y el equipo: el PO garantiza que toda la información necesaria para el desarrollo está disponible, y el equipo garantiza que puede estimar y completar la tarea. DoR no es universal — cada equipo define su propio conjunto de criterios. Sin DoR, una tarea puede entrar en un sprint con requisitos poco claros, lo que generará retrabajo y retrasos.

DoR típico para desarrollo móvil: 1) Los Acceptance Criteria están descritos (formato Given-When-Then). 2) El diseño está listo en Figma (para tareas UI) con todos los estados: default, loading, error, empty state. 3) La especificación API está aprobada (OpenAPI/Swagger, ejemplos de solicitudes y respuestas). 4) Hay estimación en story points. 5) Se identificaron dependencias de otras tareas. 6) La tarea no depende de componentes externos no finalizados. 7) Especificidad móvil: versiones objetivo de SO definidas, necesidad de feature flag, soporte para niveles de API antiguos.

Técnicas de estimación de tareas

Planning Poker es la técnica de estimación más popular en el grooming. Cada desarrollador recibe un mazo de cartas con números de Fibonacci (1, 2, 3, 5, 8, 13, 21). El PO presenta una tarea y la explica. Tras la discusión, todos muestran su carta simultáneamente. Si las estimaciones difieren significativamente (por ejemplo, 3 y 13), los desarrolladores explican su razonamiento y votan de nuevo. Las iteraciones se repiten hasta alcanzar el consenso. El objetivo de Planning Poker no es la estimación precisa, sino descubrir diferencias en la comprensión de la tarea.

T-Shirt Sizing es una técnica simplificada para estimaciones rápidas: XS (1 SP), S (2), M (3), L (5), XL (8), XXL (13). Es adecuada para la clasificación inicial del backlog cuando hay muchas tareas y se necesita un orden de magnitud aproximado. Después de T-Shirt Sizing, se realiza una estimación más precisa mediante Planning Poker para las tareas del próximo sprint. Affinity Estimation es una técnica de clasificación grupal donde las tareas se ordenan en una mesa de la más simple a la más compleja sin usar números, luego se agrupan en clústeres y cada clúster recibe una estimación.

En el desarrollo móvil, la estimación debe considerar la complejidad de la plataforma. Una tarea de Android puede estimarse en 5 SP mientras que la misma tarea para iOS puede ser de 3 SP (o viceversa). Esto es normal: diferentes plataformas tienen diferente complejidad de implementación. Consejo: estime cada plataforma por separado si el equipo es multiplataforma. Use una escala relativa: una tarea base (por ejemplo, una pantalla con texto y un botón) = 1 SP. Todo lo demás es relativo a ella. Según Scrum.org (2025), después de 3–4 sprints, la precisión de estimación del equipo alcanza el ±20% de la complejidad real.

Descomposición: cómo dividir tareas grandes

Las tareas de más de 8 SP deben descomponerse en otras más pequeñas. Las tareas grandes no se pueden completar en un solo sprint, son difíciles de estimar y no brindan sensación de progreso. Técnicas de descomposición: dividir la tarea por capas horizontales (UI → ViewModel → Repository → Network/DB) o por cortes verticales (funcionalidad: una pantalla completa). La descomposición horizontal funciona mejor para el desarrollo móvil: Sub-tarea 1 — maquetación UI (XML/Jetpack Compose/SwiftUI), Sub-tarea 2 — ViewModel + State, Sub-tarea 3 — Repository + Network, Sub-tarea 4 — Pruebas unitarias.

Descomposición vertical: dividir las historias de usuario en historias más pequeñas con valor independiente. Ejemplo: Épica “Carrito de compras” → Historia 1 “Agregar producto al carrito”, Historia 2 “Mostrar carrito”, Historia 3 “Eliminar producto del carrito”, Historia 4 “Finalizar compra”. Cada historia tiene su propio valor de negocio y puede lanzarse de forma independiente. SPoK (Story Points on Kano): clasifique las historias por valor de negocio (Must-have, Should-have, Could-have) e impleméntelas en orden de valor.

Lista de verificación de descomposición en el grooming: 1) ¿La tarea es mayor de 8 SP? → Descomponer. 2) ¿Hay Acceptance Criteria definidos? → Si no, añadirlos. 3) ¿Depende de otras tareas? → Identificar y documentar dependencias. 4) ¿Contiene incertidumbre? → Añadir un Spike (investigación) antes de la tarea principal. 5) ¿Se necesita diseño? → Verificar la disponibilidad de los mockups. Regla INVEST: Independent (independiente de otras), Negotiable (se puede discutir), Valuable (valiosa para el negocio), Estimable (se puede estimar), Small (pequeña), Testable (comprobable). Si una tarea no cumple INVEST, no está lista para el sprint.

Proceso de grooming: paso a paso

Paso 1: Calentamiento (5 minutos). El Scrum Master recuerda el objetivo del grooming y el DoR. El equipo mira el tablero y el PO muestra qué tareas se discutirán. Paso 2: Revisión de tareas (30 minutos). El PO presenta secuencialmente las tareas del final del sprint actual y el comienzo del siguiente. Para cada tarea: nombre, descripción, Acceptance Criteria (si existen), enlace al diseño, especificación API. El equipo hace preguntas aclaratorias: “¿Hay un mockup para el estado vacío?”, “¿Qué método HTTP?”, “¿Cuál es el minimum deployment target de iOS?”.

Paso 3: Estimación (15 minutos). El equipo estima la tarea mediante Planning Poker o T-Shirt Sizing. Si la discrepancia es mayor de 2 SP, discuten las razones y votan de nuevo. Regla: si una tarea no puede estimarse (requisitos poco claros, sin diseño) — se devuelve al PO para refinamiento y volverá al siguiente grooming con aclaraciones. No estime tareas con incógnitas — esto garantiza errores en el sprint. Paso 4: Registro de resultados (10 minutos). El PO registra las estimaciones en Jira/Linear, actualiza la descripción de la tarea y establece prioridades.

Resultados del grooming: 3–7 tareas completamente preparadas para Sprint Planning (con DoR, estimación, diseño, API). El PO actualiza el backlog: elimina tareas obsoletas, fusiona duplicados y ajusta prioridades. Importante: el grooming no termina el trabajo del PO — entre sesiones de grooming, el PO debe preparar las siguientes tareas. Ritmo recomendado: el PO prepara 3–4 tareas para el grooming y el equipo las trabaja. Si hay más de 50 tareas en el backlog, el PO debe priorizar (MoSCoW o Weighted Shortest Job First) antes del grooming.

Diferencias entre grooming y Sprint Planning

El grooming es preparación. No hay compromisos — la tarea simplemente se aclara y estima. Sprint Planning es un compromiso. El equipo selecciona tareas de las preparadas en el grooming y se compromete a completarlas durante el sprint. Diferencias clave: el grooming no está vinculado a un sprint concreto (refinamiento del backlog en general), no hay Sprint Goal durante el grooming, y el grooming puede realizarse en cualquier momento del sprint. Sprint Planning es estrictamente al inicio del sprint y siempre genera un Sprint Goal.

En el grooming, las tareas solo se estiman, pero no se toman para el sprint. En Planning, las tareas se seleccionan del grupo preparado. Sin grooming, Sprint Planning dura de 6 a 8 horas (en lugar de 4), porque el equipo ve las tareas por primera vez y no puede estimarlas rápidamente. Regla 80/20: el 80% de las tareas en Sprint Planning deben estar completamente preparadas (haber pasado por grooming), el 20% pueden ser nuevas (bugs urgentes, hotfixes). Si en Planning más del 20% de las tareas no están estimadas, el grooming fue insuficiente.

Errores típicos del grooming

Error 1: grooming una vez al mes. El equipo acumula tareas de 3–4 sprints e intenta refinarlo todo en 2 horas. Resultado: la mitad de las tareas quedan sin estimar y Planning ocupa todo el día. Solución: el grooming debe ser regular — una vez por sprint, 60 minutos. Si hay muchas tareas, añada un segundo grooming a mitad del sprint. Es mejor refinar pocas tareas a fondo que muchas superficialmente. Ritmo: 3–5 tareas por sesión de grooming, cada una con discusión y estimación completas.

Error 2: estimación sin contexto. El PO presenta una tarea “Implementar la pantalla de carrito de compras” sin diseño, API ni AC. El equipo estima “a ojo” — 13 SP. En Planning resulta ser 5 SP (porque la pantalla es simple). Solución: no se estima una tarea si no tiene diseño o API. El PO debe preparar los materiales antes del grooming. Regla: “Sin mockup no hay estimación”. Excepción: tareas Spike — investigación de incertidumbre, se estiman por separado sin diseño (2–5 SP según la complejidad de la investigación).

Error 3: el grooming se convierte en Planning. El equipo empieza a asignar tareas a personas y a discutir quién hará qué. Solución: recordar que el grooming es para aclarar, no para asignar. La asignación se hace en el Daily después de que comience el sprint. El grooming responde “¿qué hacer?”, Planning responde “¿cuándo hacerlo?”, Daily responde “¿quién lo hace?”. Mezclar estas preguntas en una reunión reduce la eficacia de cada una. El Scrum Master debe detener las discusiones tipo Planning y redirigir el enfoque hacia la aclaración de la tarea.

Error 4: ignorar la deuda técnica. En el grooming solo se discuten nuevas funcionalidades, las tareas técnicas se ignoran. Después de 3–4 sprints, la deuda técnica se acumula hasta un nivel crítico. Solución: en cada grooming, al menos 1 tarea técnica debe ser estimada. Proporción: por cada 3 funcionalidades → 1 tarea técnica. Use la métrica Tech Debt Ratio: relación entre tareas técnicas y tareas funcionales en un sprint. Valor objetivo: 0.25–0.3 (25–30% del tiempo en deuda técnica). Si el ratio es inferior a 0.2, la velocidad de desarrollo disminuirá en sprints posteriores.