El marco Scrum — Segunda edición

Este capítulo conserva el contexto histórico y práctico de la segunda edición. El temario de la tercera edición también está disponible en el índice que aparece a continuación.

---

Historias de usuario de Scrum: visión completa para gestionarlas eficazmente

Definición: una historia de usuario es una descripción breve y centrada en el usuario de una funcionalidad deseada en un proyecto ágil. Suele describir elementos del Product Backlog, aunque Scrum no exige este formato. Desde la perspectiva del usuario final, explica quién, qué y por qué de un requisito y destaca la colaboración y comunicación multifuncionales. Su plantilla sencilla incluye un actor, una acción u objetivo y un beneficio o valor. Facilita comprender los requisitos de forma compartida, avanzar incrementalmente y priorizar según las necesidades y comentarios de los usuarios.

Las historias de usuario son como pequeños argumentos de película para cada funcionalidad del producto: más breves y sencillos. Cada una presenta un personaje, el usuario o actor, un objetivo, la funcionalidad necesaria, y el motivo de su importancia, el beneficio.Imagina esas historias formando una red conectada de deseos, expectativas y soluciones: un Product Backlog. Gestionarlo, priorizarlo y refinarlo se parece a dirigir una película en la que cada historia es crucial, pero flexible. International Scrum Institute te guía para dominar estas historias y gestionarlas eficazmente.

Para escribir una historia clara y eficaz, utiliza un formato como «Como [función], quiero [capacidad] para [beneficio]». Por ejemplo: «Como cliente, quiero consultar fácilmente el estado de mi pedido para organizar mi agenda».

Características de las historias de usuario de Scrum

Los elementos del Product Backlog suelen escribirse como historias de usuario. Su característica más importante es relatar brevemente cómo alguien utiliza el producto. Incluyen nombre, narración y criterios y condiciones de aceptación para completarlas. Se centran en lo que el usuario necesita o desea sin detallar cómo conseguirlo.

Hay distintas recomendaciones para definirlas. Una plantilla podría ser:

Como [actor], [quiero|debo] [acción] para [resultado]
O, de forma más breve:
Como [actor], [quiero|debo] [resultado]

Actor: La persona o perfil cuya necesidad describe la historia, no quien es responsable del Product Backlog. Suele ser un usuario, pero conviene concretar. Actores como «administrador», «cliente que ha iniciado sesión» o «visitante sin autenticar» facilitan la comprensión y sitúan la historia en contexto.

Acción: Lo que quiere hacer el actor. Una acción obligatoria puede introducirse con «debo»; en los demás casos se utiliza «quiero».

Resultado: Lo que quiere conseguir al realizar la acción. Es el resultado desde la perspectiva del actor.

Historia de usuario de Scrum: visión general

En la dinámica gestión ágil, las historias son esenciales para comunicar eficazmente los requisitos del cliente. Dan vida a requisitos abstractos al presentarlos desde la perspectiva del usuario final.

Son descripciones breves e informales de funcionalidades que consideran las necesidades del usuario o actor. Suelen seguir «Como [usuario/actor], quiero [funcionalidad] para [beneficio]». Este formato sencillo y potente aclara quién la utilizará, qué quiere y por qué. Así ofrece una visión completa e integral del requisito.

Por ejemplo, los usuarios de un comercio electrónico necesitan buscar productos con mayor eficiencia. La historia podría ser: «Como comprador, quiero una búsqueda más eficiente para encontrar rápidamente los productos que me interesan». Esto resume la funcionalidad desde la perspectiva del usuario y especifica su valor.

Además, las historias representan el punto de partida de conversaciones detalladas entre partes interesadas, Product Owners y equipos de desarrollo. Abren debates significativos sobre necesidades y facilitan la colaboración y comprensión.

También son fundamentales para fijar prioridades en el Product Backlog. Ayudan a determinar qué funcionalidades son esenciales para los usuarios y cuáles desarrollar primero.

La función de las historias en la gestión ágil de proyectos

Comprender las historias es muy beneficioso porque permite a los equipos entender claramente las necesidades del cliente. También ayuda a entregar valor excepcional al centrarse en las funcionalidades que realmente importan al usuario final.

Es como construir una casa: no empezarías sin planos ni sin comprender las necesidades del propietario. Del mismo modo, las historias sientan las bases y orientan al equipo durante el proyecto, alineando los esfuerzos con las expectativas del cliente.

Dada su importancia, las organizaciones deben priorizar que sus equipos aprendan a crear historias eficaces. International Scrum Institute ofrece recursos completos para dominar este aspecto fundamental. Explican cómo elaborar historias refinadas y buenas prácticas para gestionarlas en el Product Backlog.

Ahora que comprendemos su importancia, exploremos cómo elaborar historias eficaces y de impacto.

Crear historias de usuario de Scrum eficazmente

Las historias están en el centro del desarrollo ágil y elaborarlas bien es clave para el éxito. Estos son algunos principios esenciales.

Comprender las necesidades del usuario

Comprender las dificultades y necesidades de los usuarios es el primer paso crucial. Dedicar tiempo a empatizar y conocer profundamente sus experiencias, deseos y retos garantiza historias que respondan a necesidades reales y aporten valor tangible. Las encuestas, entrevistas y estudios de observación permiten obtener información directamente de ellos.

Estructurar las historias

SMART es una perspectiva útil para debatir el resultado previsto, no una plantilla obligatoria de Scrum:

• Específico: Define qué debe hacerse
• Medible: Identifica cómo se medirá el éxito
• Alcanzable: Garantiza la viabilidad dentro de las restricciones
• Relevante: Alinea con los objetivos empresariales y las necesidades del usuario
• Limitado en el tiempo: Establece un calendario claro de entrega

Esto ofrece un marco claro al equipo y garantiza que cada historia contribuya directamente a los objetivos y aporte valor real al usuario final.

Implicar al equipo

Implicar a todo el equipo al crear historias fomenta la colaboración y la comprensión compartida de requisitos y objetivos. Las perspectivas de desarrolladores, diseñadores, especialistas en pruebas y Product Owners ofrecen una visión integral. Este enfoque descubre pronto información valiosa y retos potenciales y permite historias más refinadas que representan mejor la visión colectiva.

Comprender la importancia de empatizar con los usuarios, estructurar bien las historias e implicar a todo el equipo nos proporciona los principios básicos para crear historias atractivas y de impacto.

Con esta base sólida, exploremos técnicas para priorizar las historias y maximizar su impacto en proyectos ágiles.

Técnicas para priorizar historias de usuario

A medida que crece el Product Backlog, es esencial priorizar eficazmente. No todas las funcionalidades tienen la misma importancia ni el mismo impacto en la satisfacción o el desarrollo. Estas dos técnicas ayudan a decidir con información y maximizar el valor que entrega el equipo.

Método MoSCoW

MoSCoW clasifica las historias en cuatro categorías: imprescindibles, importantes, deseables y excluidas por ahora. Es un enfoque sencillo y eficaz para identificar las funcionalidades cruciales según su urgencia e importancia.

• Imprescindibles (Must Have): Funciones no negociables e indispensables para el funcionamiento básico o las necesidades fundamentales. Sin ellas, se comprometería el propósito principal del producto.
• Importantes (Should Have): Funcionalidades importantes, pero no cruciales para el lanzamiento inicial. Completan el producto y pueden aplazarse si es necesario.
• Deseables (Could Have): Funcionalidades deseables pero opcionales que mejoran la experiencia o añaden valor, y pueden aplazarse sin afectar a la funcionalidad principal.
• Excluidas por ahora (Won't Have): Funcionalidades consideradas innecesarias en el momento actual que se dejan deliberadamente fuera del alcance.

Esta clasificación clara permite alinear expectativas con el equipo y alcanzar consenso sobre qué desarrollar primero.

Modelo de Kano

Además de MoSCoW, el modelo de Kano clasifica las historias según su impacto en la satisfacción del cliente. Distingue tres tipos de atributos: básicos, de rendimiento y de entusiasmo.

• Atributos básicos: Son requisitos fundamentales que los clientes esperan y suelen dar por supuestos. Cumplirlos no aumenta necesariamente la satisfacción, pero su ausencia provoca insatisfacción.
• Atributos de rendimiento: Se relacionan directamente con la satisfacción: cuanto mejores, mayor satisfacción. Sin embargo, existen rendimientos decrecientes, porque las mejoras excesivas no siempre aumentan el entusiasmo del cliente.
• Atributos de entusiasmo: Pueden sorprender y encantar cuando existen, pero su ausencia no afecta mucho a la satisfacción.

Identificar la categoría de cada historia permite a la Product Owner comprender las prioridades y decidir sobre funcionalidades alineadas con las necesidades y deseos del cliente.

Estas técnicas centran al equipo en funcionalidades que realmente importan, evitan esfuerzos en elementos no esenciales y aumentan la satisfacción general.

Tras comprender la priorización, veamos la función crucial de las partes interesadas al definir y refinar las historias.

Las partes interesadas y las historias de usuario

En Scrum, las partes interesadas orientan el rumbo: conocen lo que quieren los usuarios y necesita el negocio. Sus aportaciones son esenciales para historias que reflejen ambos requisitos y expectativas. Sin ellas, es como conducir sin mapa, sin dirección y con riesgo de perderse.

Imagina una aplicación bancaria móvil. Las partes interesadas representan marketing, atención al cliente, seguridad informática y distintos departamentos tecnológicos. Cada una aporta una perspectiva que forma una visión completa. Marketing puede destacar una interfaz intuitiva y atractiva; atención al cliente, interacciones fluidas; y seguridad, protocolos sólidos.

Igual que criar a un niño requiere una comunidad, dar vida a una historia necesita las aportaciones de todas estas perspectivas.

Implicarlas en el refinamiento ayuda de varias formas:

• Relevancia real: Aportan escenarios y necesidades reales para alinear las historias con los requisitos prácticos del negocio.
• Ciclo de retroalimentación: Su participación activa permite recoger comentarios en cada fase y mejorar iterativamente.
• Alineación con objetivos empresariales: Ayudan a vincular las historias con objetivos más amplios y favorecen decisiones estratégicas.

Si no participan en las historias de la aplicación bancaria, se corre el riesgo de crear funcionalidades ajenas a las expectativas o que incumplan normas regulatorias. Esto puede causar retrasos o costosas reelaboraciones.

Implicarlas desde el principio genera sentido de pertenencia y responsabilidad y favorece un entorno de colaboración y comunicación.

Ya resulta claro que su participación es decisiva. Sus conocimientos y orientación dirigen las historias hacia los objetivos empresariales y las necesidades del usuario.

Ahora que comprendemos su función indispensable, pasemos a la estimación de complejidad para gestionar Scrum eficazmente. (Consulta más información sobre la estimación del esfuerzo en Scrum)

Estimar la complejidad para una gestión eficaz de Scrum

Estimar el tamaño de una historia ayuda a comprender su esfuerzo y complejidad. Las estimaciones apoyan decisiones, no son garantías, y Scrum no prescribe una técnica concreta. Una de las más populares es Planning Poker, que utiliza tarjetas con números para representar distintos niveles de esfuerzo o complejidad.

Los miembros debaten una historia y eligen individualmente una tarjeta. Las revelan a la vez y comentan las diferencias importantes. El proceso continúa hasta consensuar su complejidad.

Así se consideran todas las opiniones y se fomenta la participación activa. Las estimaciones compartidas ayudan a comprender las perspectivas de los demás y pueden descubrir complejidades o retos antes inadvertidos.

En una historia sobre crear una página de inicio de sesión, alguien puede considerarla sencilla y proponer un 3, mientras otra persona contempla las validaciones necesarias y propone un 8. Debatirlo abiertamente permite comprender mejor la tarea e identificar componentes no considerados.

Las estimaciones son valiosas para la Sprint Planning, la asignación de recursos y la comprensión de la capacidad. Durante la planificación, la Product Owner las utiliza para priorizar historias según su complejidad y valor potencial.

Estas estimaciones ayudan a determinar cuánto trabajo puede asumirse realmente en un Sprint para evitar compromisos excesivos, agotamiento o problemas de calidad. También identifican dependencias y permiten ordenar y gestionar mejor las historias.

Estimar eficazmente con técnicas como Planning Poker es fundamental para mantener la transparencia, fomentar la colaboración y decidir con información en la gestión de proyectos Scrum.

Con esta comprensión de la complejidad, veamos cómo se utilizan las historias para gestionar eficazmente el Product Backlog.

Utilizar historias para gestionar el Product Backlog

Las historias son la voz del cliente y guían al equipo hacia productos alineados con las necesidades del usuario. Aportan contexto para comprender qué se espera y qué valor añadirá. Bien utilizadas, aclaran la comunicación y agilizan decisiones mediante una comprensión completa de los requisitos, esencial para un Product Backlog organizado y refinado.

Conviene implicar a clientes, usuarios finales, Product Owners y desarrolladores. Sus perspectivas diversas permiten recoger requisitos y casos de uso variados y ofrecer una visión más completa de las funcionalidades.

En una aplicación bancaria, una historia podría describir la necesidad de transferir fondos entre cuentas con fluidez. Esto ayuda a comprender las funciones necesarias y su impacto en la experiencia.

Las historias son dinámicas y pueden refinarse y volver a priorizarse continuamente según las necesidades y tendencias. Actualizarlas y reevaluarlas mantiene un Product Backlog ágil y adaptable al negocio.

Es crucial que cada historia describa con claridad y precisión su funcionalidad. Una estructura habitual es: «Como (función), quiero (funcionalidad) para (beneficio)».

Incluir criterios de aceptación añade detalle y define condiciones claras para considerar completada una funcionalidad. Son medidas objetivas de cuándo cumple su propósito y alinean al equipo y las partes interesadas sobre los resultados esperados.

En la aplicación bancaria, un criterio puede especificar que al transferir fondos se validen las credenciales y se generen recibos rápidamente. Así todos comparten una comprensión de lo que constituye una implementación satisfactoria.

Aprovechar eficazmente las historias permite concretar requisitos y crear soluciones que respondan a los usuarios. Refinarlas continuamente conforme cambia el negocio permite mantener un Product Backlog adaptable a las demandas del mercado.

Su versatilidad permite responder a las necesidades cambiantes de los clientes y la dinámica del mercado. Esa adaptabilidad es clave para productos que realmente conecten con los usuarios finales.

¿Cuáles son los componentes clave de una historia de usuario de Scrum?

Respuesta: La función o perfil, una breve descripción de la funcionalidad deseada y los criterios de aceptación. Ayudan a comprender la perspectiva del usuario y dan pautas claras para desarrollar. Según una encuesta de Stack Overflow de 2023, el 87% de los equipos ágiles destacó la importancia de historias bien definidas para gestionar eficazmente el Product Backlog.

¿Cómo contribuye una historia a la Sprint Planning y la priorización en Scrum?

Respuesta: Las historias aclaran la perspectiva, las necesidades y los resultados deseados por el usuario. Permiten alinear el esfuerzo con sus objetivos y determinar cuáles abordar primero según valor y complejidad. Según una encuesta de VersionOne de 2022, los equipos que las priorizan eficazmente durante la Sprint Planning logran mayor productividad y satisfacción del cliente.

¿Cuál es el propósito de una historia de usuario en Scrum?

Respuesta: Recoger los requisitos y necesidades de los usuarios o clientes. Sirve de herramienta de comunicación para mejorar la comprensión y colaboración entre el equipo y las partes interesadas. Se centra en entregar valor y ayuda a priorizar el Product Backlog según comentarios y valor empresarial. Según Scrum Alliance, el 76% consideró que mejoraban la capacidad del equipo para aportar valor al cliente.

¿Cómo se escriben historias eficaces para el desarrollo ágil?

Respuesta: Céntrate en las «tres C»: tarjeta, una descripción breve; conversación sobre los detalles; y confirmación mediante criterios de aceptación. Escribe historias concisas y concretas y priorízalas por su valor. Según VersionOne, el 65% consideró que mantenerlas pequeñas y bien definidas contribuía al éxito. La colaboración frecuente entre desarrolladores, Product Owners y clientes es crucial para comprender y alinear los requisitos.

¿Existen buenas prácticas o errores habituales al utilizar historias en Scrum?

Respuesta: Sí. Conviene definir claramente actor, objetivo y beneficio, priorizar por valor y complejidad, implicar a todo el equipo al escribir y estimar y refinar y actualizar regularmente el Product Backlog. Los errores habituales incluyen historias demasiado detalladas o técnicas, excluir a las partes interesadas, no dividir historias grandes y no actualizar o refinar periódicamente. Según Scrum Alliance, quienes siguen estas prácticas comunicaron mejor comunicación (74%), mayor alineación empresarial (68%) y mayor satisfacción del cliente (62%).

Resumen de historias de usuario de Scrum

Un aspecto crucial es representar cuidadosamente los requisitos: cada historia es una parte valiosa del desarrollo iterativo. A menudo son componentes de épicas y contribuyen al éxito al describir claramente trabajo significativo. Identificar épicas formadas por varias historias permite planificar y ejecutar de forma completa. Hemos explorado cómo las historias mejoran la comunicación de la empresa y agilizan la entrega de información valiosa.

Comprender su importancia implica reconocer sus beneficios tangibles para el equipo y los usuarios. Los ejemplos muestran cómo facilitan estrategias eficaces de pruebas y entregas que cumplen los criterios. Dividir funcionalidades complejas en partes manejables permite recorrer más fácilmente el desarrollo iterativo. Esto fomenta la colaboración y adaptarse a requisitos que evolucionan en cada iteración.

En conclusión, las historias son esenciales en el marco ágil y ofrecen un enfoque estructurado. Al dividir épicas, facilitar la planificación de iteraciones o mejorar la comunicación empresarial, resultan cruciales para obtener resultados satisfactorios. Los ejemplos y las estrategias de pruebas muestran que aportan valor al garantizar la alineación de las entregas con los objetivos generales. Para profundizar en las metodologías ágiles, International Scrum Institute ofrece la oportunidad de inscribirte en una certificación Scrum y desenvolverte en la gestión de proyectos con conocimientos y confianza.