La Importancia de las Historias de Usuario

La Historias de Usuario son utilizadas en la gestión de proyectos ágil para la representación de requisitos, y estas son una breve descripción muy valiosa de una funcionalidad de software tal y como la percibe el usuario.


Las Historias de Usuario nos ayudan a comprender la proposición de valor del producto desde sus inicios. Por lo que, son un medio poderoso que permite la comunicación tanto escrita como verbal, y fomenta la colaboración y el aprendizaje para los equipos e interesados del proyecto.


Su origen viene de la metodología eXtreme Programming (XP) creada por Kent Beck en el año 1999, donde los clientes debían escribir las Historias de Usuario con la intención de "forzar" la brevedad y crear ambigüedad intencional, con la idea de que esta ambigüedad resultaría en más comunicación cara a cara.


Las Historias de Usuario son parte de un enfoque ágil que permiten administrar los requisitos de los usuarios, sin tener que elaborar una gran cantidad de documentos formales y sin requerir de mucho tiempo para su administración.


Para comenzar a escribir Historias de Usuario es de bastante utilidad usar la fórmula de captura de funcionalidades conocida como las tres C's definida en 2001 por Ron Jeffries. Esto nos indica que las Historias de Usuarios deben ser descritas brevemente y memorizables fácilmente, las cuales podamos escribirlas en una tarjeta (CARD). Por otra lado, las historias de usuarios generan una conversación (CONVERSATION) muy valiosa entre los Desarrolladores y Product Owner en base a su contenido, y a la interacción que se produce sobre su llenado. Por último, el Product Owner se debe asegurar mediante la revisión de los criterios de validación/aceptación que existe una confirmación (CONFIRMATION) por parte de los Desarrolladores en que se comprendió los requisitos de manera correcta.


Las Historias de Usuario son descripciones breves, de fácil entendimiento y aceptación y que sean fáciles de recordar. Estas tienen el objetivo de representar las necesidades, problemas y expectativas de un usuario. Es por ello, que para describir Historias de Usuario se recomienda seguir un formato popular y muy simple utilizado por primera vez por Connextra y popularizado por Mike Cohn.


  • Como “Rol del usuario”: Los equipos necesitan saber ¿Para quién están construyendo? No se trata sobre un rol o un cargo, es sobre una persona que tiene una necesidad o problemas detrás con la cual se debe empatizar. Nos permite ponernos en su lugar, es decir, saber cómo piensa y siente.

  • Quiero “Objetivo”: En esta parte estamos describiendo la intención de la persona, no la funcionalidad que usará. ¿Qué es lo realmente está tratando de lograr?

  • Para poder “Beneficio”: Por último, debemos saber ¿Cuál será el beneficio general que está tratando de lograr? Es un beneficio que está relacionado con la Visión del Producto.

Cómo “Rol de Usuario”

quiero “Objetivo”

para poder “Beneficio”


El factor fundamental de una Historia de Usuario es que sea un formato flexible que se adapte principalmente a la características de la empresa y del proyecto. Es por ello, que se consideran tres campos necesarios en una Historia de Usuario, aunque se puede incluir cualquier campo que aporte información útil para el proyecto.


Los campos que se consideran necesarios para completar con información las Historias de Usuarios son:


  • Descripción: Breve síntesis que represente la necesidad o problema y expectativas sobre la solución que se va a construir. Es por ello, que se recomienda el formato popularizado por Mike Cohn.

  • Estimación: Estimación del esfuerzo que se requiere para implementar una Historia de Usuario. Por lo general, en Scrum se mide el esfuerzo a través de los Puntos de Historia.

  • Prioridad: Este campo permite determinar el orden en que las Historias de Usuarios serán implementadas.

Otro campo que no se considera necesario, pero si es bastante útil, son los Criterios de Validación/Aceptación. Estos criterios permiten especificar las salidas que se obtendrán cuando se implemente la funcionalidad construida. Por lo general, se realiza a través de pruebas que validen que la Historia de Usuario se ha cumplido de forma exitosa.


Cabe destacar que se puede incluir cualquier campo que aporte información útil al proyecto. Algunos de los campos recomendados son: ID, Título, Valor de Negocio, Definición de Terminado (DoD), Responsable, N° Sprint, Riesgo, Módulo, observaciones y entre otros.

Descargar ejemplo: Historia de Usuario

Blog 7 Activando Agilidad - Historias d
.
Download • 77KB

A modo de resumen, se mencionan las principales características de las Historias de Usuario:

  • Describen las funcionalidades que dan solución a necesidades, problemas y expectativas del usuario

  • Son breves y fáciles de leer a través de un lenguaje común para que sea comprendida por los Desarrolladores, interesados y usuarios

  • Cada historia debe ser pequeña, memorizable fácilmente y poder ser escrita en una tarjeta (CARD)

  • Cada historia genera una conversación (Conversation) valiosa entre los Desarrolladores y Product Owner para incorporar detalles en su creación

  • Cada historia genera una confirmación (Confirmation) por parte de los Desarrolladores con relación a su correcta comprensión

  • Las historias no se detallan al principio de proyecto, sino que se elaboran sobre una base JIT (Just in Time)

  • Permiten estimar fácilmente el esfuerzo sobre lo que se va a desarrollar

  • Al ser muy cortas, estas representan pequeños incrementos de una funcionalidad valorada que puede ser construida en días o semanas (Sprint)

  • Permiten dividir los proyectos en pequeñas entregas

  • Cada historia es independiente para que puedan ser planificadas y desarrolladas en cualquier orden. La idea de fondo es evitar los desperdicios a través de los tiempos muertos que se pueden producir con historias dependientes

  • Necesitan poco mantenimiento y se pueden desechar con seguridad después de la implementación, ya que son únicas en el proyecto

  • Son ideales para proyectos en entornos VUCA, ya que no requieren de demasiado detalle de forma temprana para requisitos que no son muy claros.

Historia de Usuario

Referencias:

#Agilidad #Scrum #Scrummaster #Productowner #Lean #Kanban

51 vistas0 comentarios

Entradas Recientes

Ver todo

© 2020 Creado por Activando Agilidad