Unidad de trabajo
La unidad de trabajo es el elemento que el equipo utiliza para gestionar y medir el trabajo dentro de un sprint. Las unidades más habituales son la historia de usuario, la historia técnica y la tarea, y su uso depende del nivel de madurez del equipo y del tipo de trabajo que se gestiona.
Unidades principales
Historia de usuario
Descripción corta, simple y específica del valor que un producto o servicio debe proporcionar al usuario final, escrita desde su perspectiva. Se generan durante las conversaciones entre el equipo y el propietario del producto para lograr una visión alineada, y sirven para recordar lo acordado (véase Historia de usuario).
Historia técnica
Similar a la historia de usuario pero para funcionalidades no visibles directamente por el usuario final: refactorizaciones, implementación de medidas de seguridad, mejoras de rendimiento o de infraestructura. La historia técnica sigue siendo una unidad de trabajo válida en la pila del sprint aunque no genere valor perceptible directamente para el cliente.
Tarea
Unidades de trabajo más pequeñas que las historias. Son actividades concretas que deben completarse para cumplir con una historia: escribir código, diseñar una interfaz, realizar pruebas, documentar. No se estiman en puntos de historia sino en tiempo, y no aparecen en la pila del producto sino en la pila del sprint (véase Tarea).
Épicas: cuándo una historia es demasiado grande
Cuando una historia es demasiado grande y está muy poco definida, se denomina épica (epic). Las épicas son requisitos ágiles pero no sirven como unidades de trabajo: su tamaño e indefinición las hacen inestimables e indescomponibles de forma fiable. Deben dividirse en historias más pequeñas antes de incorporarse a un sprint.
- Ejemplo: "Desarrollar el nuevo sistema de gestión de clientes".
- Ejemplo de historia derivada: "Como agente de soporte, quiero buscar un cliente por NIF para acceder a su historial en menos de 3 segundos".
Cuándo descomponer historias en tareas
Al iniciarse en Scrum es habitual descomponer las historias en tareas para ver el avance día a día. Es especialmente útil en equipos con miembros menos experimentados, porque ayuda a detectar bloqueos antes de que afecten al sprint.
Sin embargo, a medida que el equipo gana experiencia, descomponer cada historia en tareas puede resultar tedioso o generar parálisis de planificación. Si los desarrolladores son capaces de gestionar su trabajo directamente a nivel de historia, exigir la descomposición se convierte en microgestión innecesaria. El nivel de granularidad correcto depende del contexto y de la madurez del equipo.
Error frecuente
Confundir la historia técnica con una tarea. Una historia técnica describe un resultado de valor para el sistema (aunque no sea visible para el usuario): "El sistema de autenticación soporta autenticación en dos pasos". Una tarea es un paso dentro de la implementación de una historia: "Configurar la librería de TOTP". La distinción importa porque las historias técnicas se priorizan en la pila del producto junto a las de usuario; las tareas son internas al sprint y no compiten por la priorización del negocio.
Recursos
📄 Scrum Master v.4.0 — Apartado: medición y estimación ágilDescarga gratuita · Scrum Manager
🎙️ Podcast Ep. 3: Cómo se crea una historia de usuarioScrum Manager Podcast · Spotify
🎙️ Podcast T2 Ep. 7: 5 características de una buena historia de usuarioScrum Manager Podcast · Spotify
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.