Historias de usuario en Scrum: Todo lo que necesitas saber

El objetivo está claro: quieres desarrollar un producto que aporte un alto valor añadido a los clientes. Quieres conseguir un resultado con el que los miembros del equipo y las partes interesadas estén satisfechos. Pero, ¿cómo se consigue este objetivo? ¿Cómo puedes cumplir todos los requisitos de un producto en pequeños y minuciosos pasos? 

En Agile, las historias de usuario han demostrado ser una herramienta eficaz para ello. Te llevan paso a paso desde la primera idea hasta un producto listo para la venta. Te mostraré qué son las historias de usuario, cómo crearlas y cómo puedes beneficiarte de ellas.

La definición de historias de usuario en Agile describe los requisitos de un producto desde el punto de vista del usuario. En otras palabras, las historias de usuario te dicen qué características y funciones debe tener un producto. Esto las convierte en una herramienta central para debatir y validar las necesidades de los usuarios y trabajar en su aplicación con un entendimiento común. 

Las historias de usuario proporcionan un lenguaje universal que los miembros del equipo, las partes interesadas y los clientes entienden y hablan. En la práctica, esto significa que puedes utilizar las historias de usuario para desarrollar una comprensión del producto deseado por el cliente que deje poco margen a los malentendidos. 

Varias historias de usuario juntas forman un caso de uso. Las historias de usuario tienen su origen en el Desarrollo Ágil de Software.

Las historias de usuario describen los requisitos y deseos para que el resultado de un proyecto se cree desde la perspectiva del cliente o usuario. Las historias de usuario ágiles tienen esta estructura elemental:

OMS (papel), quiere QUÉ (objetivo/deseo) POR QUÉ (valor añadido)?

Echemos un vistazo más de cerca a los componentes individuales de las historias de usuario:

QUIÉN (USUARIO)

Rellena el marcador de posición del WER con tu cliente o un representante típico de tu grupo objetivo. El grado de detalle con el que describas la OMS en la Historia Ágil de Usuario depende de la propia historia de usuario y del progreso del proyecto. Por tanto, sé lo suficientemente detallado como para crear una historia de usuario significativa.

QUÉ (FUNCIÓN)

Aquí es donde colocas los deseos del usuario. Puedes preguntarte qué espera o necesita el usuario. Si tu producto está aún en una fase temprana de desarrollo, puedes formular suposiciones basadas en tu experiencia sobre qué funciones espera el usuario. Si ya tienes un producto similar en el mercado, también puedes derivar las funciones deseadas de los comentarios sobre este producto.

POR QUÉ (VALOR AÑADIDO)

Solo el valor añadido muestra por qué una función es importante para el usuario. El PORQUÉ te permite, por tanto, una reflexión honesta sobre lo bien que conoces las necesidades de un cliente. Porque: Incluir un requisito en una historia de usuario es fácil, por ejemplo, porque el cliente expresa ese deseo. Pero solo cuando comprendes por qué el cliente necesita esto, tienes el contexto para implementar el requisito. Solo entonces puedes cuestionar si la sugerencia/deseo del cliente satisface eficientemente su necesidad real, o si posiblemente haya una forma más inteligente. Veamos un ejemplo: 

El cliente quiere un chubasquero para ir en bicicleta. Por tanto, ahora podrías incluir el requisito “capa de lluvia”. O podrías preguntar al cliente por qué necesita una capa de lluvia. Supongamos que el cliente responde “Porque no quiero mojarme”. 

Eso significa que no necesariamente tienes que entregar un impermeable. También podrías entregar una bicicleta con techo integrado. Lo decisivo es que la necesidad o el problema del cliente se resuelva con ello, es decir, no mojarse. Cuanto mejor entiendas el “porqué”, mejor podrás diseñar tu historia de usuario.

¿Qué son las Historias de Usuario en Agile (ejemplo)?

Ahora ya conoces los componentes individuales de las Historias de usuario ágiles. Un ejemplo de Historia de Usuario Ágil podría tener este aspecto: 

En CLIENTE Me gustaría UNA CONTRASEÑA SEGURA***,*** PARA QUE LOS DATOS DE MIS CLIENTES ESTÉN PROTEGIDOS.

Aquí tienes el “CLIENTE” al usuario, “UNA CONTRASEÑA SEGURA” la función y “PARA QUE LOS DATOS DE MIS CLIENTES ESTÉN PROTEGIDOS” el valor añadido. 

Cuando trabajas con historias de usuario en Scrum, les añades criterios de aceptación. Los criterios de aceptación describen los requisitos técnicos que deben cumplir las historias de usuario en el momento de la aceptación. En otras palabras: Los criterios de aceptación son los requisitos que necesitas para que una historia de usuario cree valor.

La importancia de las historias de usuario Ágiles en el backlog puede ser más diferenciada. Porque: En los backlogs, las historias de usuario no sólo pueden describir requisitos, sino que también representan un tipo de jerarquía especial. Existen estos 3 tipos de jerarquía:

Epopeyas: Las epopeyas son áreas funcionales ampliamente definidas de un producto cuyo alcance concreto puede estar aún poco claro.

Características: Los rasgos son características específicas de rendimiento dentro de una epopeya.

Historias: Las historias son historias de usuario Agile técnicas e historias de usuario dentro de una característica.

Puedes implementar estos tipos de jerarquía dentro de un sprint. Crean un beneficio concreto para el usuario. 

Para escribir historias de usuario útiles en la gestión ágil de proyectos, es crucial mantener conversaciones detalladas con todas las partes interesadas. Éstas deberían darte una comprensión global del grupo objetivo y del producto que se va a crear. A partir de ahí, puedes derivar personas, por ejemplo. 

Además, la llamada Criterios de INVERSIÓNpara crear una historia de usuario convincente:

Independiente: Una historia de usuario debe ser independiente de otras historias de usuario. Esto significa que la implementación de una historia no debe presuponer que otra historia se haya implementado previamente. Esto tiene la ventaja de que puedes dar prioridad a las historias de usuario o eliminarlas del backlog en cualquier momento. 

Veamos de nuevo el ejemplo de la bicicleta. Supongamos que decides instalar un pequeño techo sobre el sillín de la bicicleta en lugar de una capa impermeable para que el cliente no se moje más. Así que eso sería una historia de usuario. Pero ahora te das cuenta de que para un tejado primero tienes que desarrollar una montura más estable a la que se pueda fijar el tejado. Eso sería una Historia de Usuario diferente. Ambas Historias se apoyan mutuamente. Esto es exactamente lo que debes evitar.

Por supuesto, a veces es inevitable que tengas que hacer una historia de usuario antes que otra. Pero, como norma general, evita las historias de usuario para las que primero tengas que implementar otras 20 historias de usuario.

Negociable: Escribir historias de usuario a veces puede llevar bastante tiempo, por lo que no debería estar escrito en piedra después. Esto significa: Propietario de producto Las partes interesadas y los desarrolladores siempre deben debatir y perfeccionar juntos una historia de usuario. 

Valioso: El resultado de las historias de usuario en la gestión ágil de proyectos debe tener un valor añadido para el cliente.

Estimable: Una historia de usuario convincente permite al equipo de desarrollo estimar cuánto esfuerzo costará ponerla en práctica.

Pequeña: Una historia de usuario debe ser tan “pequeña” que pueda realizarse en un solo sprint.

Comprobable: Las historias de usuario en Scrum deben ser comprobables. Sólo así se puede comprobar si realmente se pueden aplicar en la práctica.

Si no estás familiarizado con la redacción de historias de usuario en Agile, puede parecerte un trabajo extra. Sin embargo, las historias de usuario proporcionan a los equipos un contexto importante para sus tareas, aclarando aún más la importancia de cada una de ellas.

Básicamente, así es como te beneficias de las Historias de Usuario:

Enfoque en el usuario: Las historias de usuario son como una lista de tareas orientada a los problemas. Tu equipo puede utilizarlos para hacer un seguimiento de sus tareas y saber exactamente cómo satisfacer las necesidades de los usuarios.

Cooperación holística: Las historias de usuario muestran a todos los implicados de un vistazo por dónde van las cosas. De este modo, todos pueden colaborar y decidir una y otra vez cómo el usuario recibirá un valor añadido especialmente alto. 

Soluciones creativas: Crear Historias de Usuario en el Desarrollo Ágil de Software resultados creativos . Porque: hacen que los equipos piensen de forma crítica sobre la mejor solución para el producto final.

Éxitos constantes: Cada Historia de Usuario es un pequeño reto. Por tanto, los equipos pueden celebrar un pequeño éxito después de cada historia. Esto motiva a lo largo de todo el proceso de desarrollo.

Las historias de usuario son una herramienta importante en el trabajo de los equipos ágiles. Te muestran una y otra vez con detalle para quién desarrollas qué y por qué. Esto no sólo te ayuda a crear un producto de alta calidad adaptado al grupo objetivo, sino también a mantener motivado al equipo durante todo el proceso. 

Para tener éxito en este nivel macro del trabajo ágil, tu organización en su conjunto tiene que pensar y funcionar de forma ágil. Para apoyarte a ti y a tu organización en esta tarea, hemos colaborado con expertos de renombre para crear Proyecto Scagile diseñado. Esto te muestra en varios seminarios web cómo enfocar correctamente una transformación ágil. La formación es gratuita. ¡No dudes en echar un vistazo!

Si quieres preguntas más variadas para tus retrospectivas, consulta nuestro post sobre 32 nuevos formatos de retrospectivas para principiantes y profesionales (con, entre otros, el Mario Kart Retro, el Marathon Retro y el Elon Musk Retro).

Por cierto, uno de los mejores métodos para desarrollar de forma sostenible la mentalidad ágil de los miembros del equipo es la realización de un chequeo ágil. Nuestra kit gratuito para el Health Check ágil del equipo puede ayudarte a hacer las preguntas correctas; simplemente haz clic.