En marcos agile, cada uno de los elementos del product backlog y que consisten en descripciones de necesidades a las que debe responder el producto o servicio que se va a desarrollar.
Descripción
Las historias de usuario deben poner en práctica el enfoque INVEST y estar formuladas en un lenguaje comprensible por cualquier persona.
Sistema de priorización
La priorización de las user stories en el product backlog es responsabilidad del product owner. A la hora de asignar valores a las stories, el Product Owner deberá considerar las siguientes 5 variables:
- Beneficios: ¿Qué beneficios reportará la implementación de esa funcionalidad?
- Costes: ¿Qué pérdidas se derivarían de posponer su implementación?
- Riesgos: ¿Qué riesgos puede comportar el implementar la funcionalidad?
- Coherencia: ¿La funcionalidad guarda coherencia con respecto a los intereses del negocio?
- Valor diferencial: ¿Cuál es el valor diferencial de la funcionalidad con respecto a lo que hace la competencia?
Técnicas
3C
Las C corresponden a las iniciales de los 3 requisitos que debe cumplir toda historia de usuario:
- Card (tarjeta): Debe ser concisa como para que se pueda escribir en una tarjeta y se pueda memorizar.
- Conversation (conversación): Debe propiciar la conversación y la negociación entre cliente y equipo de desarrollo hasta acordar unos criterios de aceptación la respectiva historia.
- Confirmation (confirmación): Debe expresar los criterios de validación del trabajo realizado, que serán confirmados por el productor owner.
Las 3C se pueden combinar con enfoques como INVEST o SMART.
DEEP
INVEST
Acrónimo que en los marcos agile hace referencia al conjunto de criterios para evaluar la calidad de las user stories de un product backlog.
- Independent (independiente): Una vez el product owner ha priorizado las historias dentro del product backlog, son los miembros del equipo los que definen qué entra en cada sprint. Por lo tanto, las historias deberán ser independientes entre sí, ya que sólo así el equipo tendrá la capacidad de organizar el sprint backlog, decidiendo incluso en qué orden se llevarán a cabo las tareas. Si una historia fuera dependiente de otra, la libertad de trabajo del equipo estaría limitada y es posible que también se viera afectado el éxito del sprint.
- Negotiable (negociable): Las historias de usuario no deberían incluir detalles ni largas redacciones, deberían explicar de manera escueta y precisa una necesidad; de lo contrario la negociación de los detalles se vería condicionada. Los detalles se negociarán más tarde con el cliente.
- Valuable (valiosa): Cada historia de usuario es la expresión de una necesidad que tiene el cliente (o los clientes del cliente). Por lo tanto, la solución a dicha necesidad debe aportar valor. El BOK de Scrum Manager recomienda que «una manera de hacer una historia valiosa es que la escriba el mismo» cliente.3
- Estimable (estimable): La estimación de la historia de usuario la hará el equipo de trabajo; por lo tanto, que resulte estimable dependerá de su claridad y su tamaño y también del conocimiento que tenga el equipo.
- Small (pequeña): Hay que recordar que todas las historias de usuario que se incluyan en el sprint backlog deberán completarse en la timebox de dicho sprint. Por ello es fundamental que las tareas necesarias para desarrollar la historia se puedan completar en unas pocas semanas de trabajo y que no entorpezcan el desarrollo del sprint.
- Testable (evaluable): Cuando el product owner elabora una historia de usuario debe pensar en cómo la evaluará: con qué procedimientos y criterios. Si esto no está claro desde el primer momento, el equipo no tendrá información suficiente para definir las tareas necesarias para desarrollar dicha historia. Además, tampoco el propio cliente tendrá claridad sobre cómo validar el entregable que resulte de ese sprint.
Historias de usuario y marcos Agile
Extreme Programming (XP)
Las historias de usuario fueron creadas por Kent Beck a finales de los 90 como parte de la metodología XP. El objetivo original no era escribir documentos técnicos, sino facilitar que el equipo «hablara» con el cliente. XP las utilizaba en tarjetas físicas para planificar las entregas basándose en conversaciones directas.
Scrum
En el marco Scrum se suele identificar las historias de usuario con los elementos del backlog (producto bacilo ítems) e incluso es habitual pensar que su origen se halla en este marco Agile (lo cual no es exacto).
Los equipos Scrum usan historias de usuario porque son la forma más eficaz y popular de redactar esos elementos, pero un equipo Scrum podría emplear casos de uso o requerimientos tradicionales y seguiría haciendo Scrum.
Kanban
En Kanban se utilizan constantemente para representar el trabajo que fluye por el tablero. Ayudan a que el equipo entienda el valor de cada «tarjeta» que se mueve de una columna a otra.
Lean Software Development
En Lean Software Development se usan para identificar el valor desde la perspectiva del cliente y eliminar el «desperdicio» (funcionalidades que el usuario no necesita).
Scrumban
Al ser Scrumban un híbrido, hereda el uso de historias para estimar y priorizar el flujo de trabajo.