• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

user story

Los elementos de una buena historia de usuario

La historia de usuario no es el santo grial que muchos creen, sino un contenedor que sirve como recordatorio de una conversación entre el Product Owner y el Development TeamUna historia de usuario es una promesa para mantener una conversación. Contrariamente a lo que mucha gente cree, el Product Backlog en Scrum está poblado por muchos tipos de requerimiento y solamente uno de ellos son las historias de usuario.

Es más acerca de la conversación que de la historia de usuario en sí misma. La conversación es lo que da las razones inherentes en la historia de usuario a lo que hay que hacer en el producto. La historia de usuario es únicamente un recordatorio de esa conversación.


3 Cs User Story

Las 3 C’s de la historia de usuario

Los elementos fundamentales de una historia de usuario son la Tarjeta (Card), la Conversación (Conversation) y Confirmación (Confirmation). Estos tres elementos son más importantes que cualquier detalle que pongamos en la historia de usuario en sí misma, y componen los elementos fundamentales de la historia de usuario. Sin ellos, la historia de usuario no está completa.

Tarjeta (Card): La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. Expresar un historia de usuario desde el punto de vista del desarrollador (As a developer I want…) o desde la organización (As the organisation I want to…) es una mala práctica que refleja la incapacidad de pensar en el valor para el usuario final.

Conversación (Conversation): Después de escribir la historia de usuario en la tarjeta, es necesario tener una conversación al respecto de su contenido. Hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación. Esta conversación puede suceder en cualquier momento; es habitual que se produzca durante el refinamiento del Backlog o el Sprint Planning.

Confirmación (Confirmation): La confirmación es un acuerdo que refleja que todas las personas implicadas, Product Owner y Development Team, entienden cuales son los elementos, valor y resultado esperado de la historia de usuario. Muchos equipos cometen el error de no tener esta confirmación, lo cual lleva a fricciones y problemas durante el Sprint Planning.


modelo de historia de usuario

Modelo de historia de usuario

Una historia de usuario generalmente sigue un patrón definido

As a... Persona para la que se cubre una necesidad
I want... lo que queremos que ocurra, por ejemplo una características o una funcionalidad
So that... el valor que obtiene la persona de la implementación de la característica o funcionalidad.

En la primera parte de la historia de usuario, es muy útil hacer referencia a usuarios de nuestro producto, usuarios que estén descritos y estudiados usando el modelo de User Personas, que toman una serie de rasgos de múltiples usuarios y construyen una persona ficticia que haga uso de la aplicación.

En la segunda parte de la historia de usuario, se explica lo que desde el punto de vista de la persona debería de suceder, sin entrar en descripciones técnicas. Una buena historia de usuario no tiene en cuenta lo que el sistema puede hacer, sino lo que el usuario quiere obtener.

Una historia de usuario está totalmente centrada en el usuario, y no en el producto o la organización.En la tercera parte, se expresa el valor que la persona quiere obtener, lo cual ayuda a entender y refinar, o incluso cambiar la forma en la que usuario obtiene el valor esperado.

Como se puede comprobar, las historias de usuario están totalmente alineadas con la expectativa del usuario, sin tener en cuenta capacidades o restricciones de nuestro producto. Una buena historia de usuario es aquella que está construida sobre datos reales, obtenidos de los propios usuarios.

Vanesa Tejada tiene una gran presentación sobre como escribir historias de usuario


acceptance criteria

Criterios de Aceptación

Los criterios de aceptación son los detalles de una historia de usuario, y ayudan a completar el patrón de valor expresado por la misma. Los criterios de aceptación incluyen los detalles que ayudan a visualizar la película completa y mejoran el entendimiento que el Product Owner, los Stakeholders y el Development Team tienen sobre lo que se va a realizar.

Los criterios de aceptación cumplen dos funciones: Clarificar el contexto en el que ocurre la historia de usuario y facilitar saber cuando están realmente terminadas.Los criterios de aceptación también son el medio por el cual el Development Team es capaz de saber cuando un ítem del Product Backlog está terminado, y ser capaces de testar los elementos de la historia de usuario en conjunto.

Unos buenos criterios de aceptación son claros, concisos, expresan una sola cualidad del ítem del Product Backlog y en la mayoría de ocasiones son redundantes, explicando desde múltiples puntos de vista cual es la imagen finalizada de la historia de usuario.

Además, pueden contener requerimientos no funcionales, si estos no están recogidos en la Definition of Done del equipo, como velocidad de la aplicación, concurrencia o elementos de seguridad que deben ser implantados para considerar la historia de usuario terminada.


specification by example

Specification by example

Otro elemento que puede resultar de ayuda en una historia de usuario es expresar los resultados deseados mediante un ejemplo, que ayude a entender al Development Team cual es el resultado deseado al implementar una historia de usuario.

No solamente es válido para Algoritmos, sino que también puede ser muy útil en el caso de implementación de diseños en un producto ya existente. Herramientas como InVision ayudan a los especialistas en UX/UI a diseñar flujos en una aplicación que posteriormente pueden ser implementados como especificaciones en el producto final, siendo uno de los criterios de aceptación que la UI del producto sea cómo la del diseño inicial.

También puedes leer más sobre Specification by Example en el blog de Martin Fowler.

Scrum no necesita planing póquer ni historias de usuario

La historia de usuario es uno de esos elementos míticos de Scrum. Todos los Product Backlogs deben de estar poblados de ellas, aunque en ocasiones ni se refieran a un usuario y haya que enrevesadas para que expresen lo que realmente queremos.

El planing póquer es casi sinónimo de planificación en Scrum. Todos aquellos que han utilizado Scrum se han sentado alguna vez en una habitación con las cartas de estimación o una aplicación en el móvil para estimar el tamaño de historias de usuario.

Sin embargo, ninguno de los dos forman parte de Scrum y su uso es a discreción de los equipos Scrum y no de la organización.

El planing póquer

Scrum, en su guía oficial, expresa la necesidad de contar con estimaciones para los Product Backlog Ítems presentes en el Product Backlog, con el objetivo de entender mejor qué es lo que hay que hacer y cual es el valor que aporta a la organización.

Scrum dice claramente que los ítems presentes en el Product Backlog, deben de tener una estimación hecha por el Development Team

El planing póquer es una técnica de estimación que consiste en una sesión colaborativa con el equipo de desarrollo y, mientras el Product Owner lee un ítem, ellos eligen una carta con un número y la muestran a los demás. Las estimaciones usando planing póquer normalmente se hacen siguiendo la secuencia de Fibonacci, para expresar la complejidad (No las horas, como mucha gente cree). En este caso, un ítem con 5 puntos no es equivalente a 5 ítems de un punto, sino que es ocho veces más complejo que cada uno de ellos. En el planing póquer se estima complejidad y no tiempo, ya que si se estima tiempo no se tiene en cuenta la complejidad y si se estima complejidad si.

El planing póquer sirve para fomentar una conversación cuando existe desacuerdo sobre el nivel de complejidad de un elemento. Si dos desarrolladores tienen ideas muy dispares sobre la complejidad de un ítem, es un indicador de que ese tema se debería de tratar en profundidadd.

No sirve para hacer predicciones. Al menos no de manera lineal, que es cómo tienden a hacerlas muchas organizaciones. En otro post veremos como hacer predicciones en entornos complejos usando (aunque no únicamente) la información generada por el equipo.

El valor de las estimaciones está en entender mejor cual es el tamaño de los ítems del backlog porque ello influye en la prioridad final que decida darle el Product Owner; sin embargo, tomarlas como una herramienta de predicción con ajustes es, lamentablemente, perder el tiempo.

Otras formas de estimación alternativa son No Estimates, donde todos los ítems del Product Backlog son del mismo tamaño; T-shirt sizing, donde se estima con tamaños de camiseta; Affinity estimation, donde se estiman los PBIs por comparación continua con otros.

Las historias de usuario

Muchos creen erroneamente que las historias de usuario deben poblar un Product Backlog. Las historias de usuario son elementos expresados en el sentido del valor que dan al usuario final, son independientes entre sí y fomentan una conversación sobre el valor para los usuarios.

As a developer, I want to download the development environment, so I can develop.
Al igual que el planing póquer, se ha convertido en un de esos elementos míticos, donde muchos profesionales dicen que un Product Backlog tiene historias de usuario. Nada más alejado de la realidad. Un product backlog contiene Product Backlog Items, y estos pueden ser cualquier cosa que necesite ser hecha para completar el producto: Casos de uso, historias de usuario, tareas técnica, requerimientos no funcionales, etc… la lista es tan larga como acciones tenga que completar el Equipo de Desarrollo para terminarla.

En lugar de escribir historias de usuario, yo recomiendo a los Product Owners con los que trabajo que intenten entender el valor de negocio de cada uno de los ítems existentes, y realmente ese es un ejercicio productivo, ya que en muchas ocasiones, el 20% o el 30% de los ítems presentes no tienen ninguno.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad