Historias de Usuario en Scrum. (1era Parte)

Rebeca Ramos
Academia Hack
Published in
4 min readAug 19, 2019

Cuando hablamos de Historias de Usuario nos referimos a la descripción de una necesidad que debe ser comprensible por cualquier persona.

En el siguiente artículo hablaremos de una de tantas formas que podemos implementar para realizar una Historia de Usuario.

Las 3 “C”:

“Card, Conversation, Confirmation” son los principios fundamentales para crear Historias de Usuario:

Card (o Tarjeta): Nos servirá para plasmar el objetivo inicial (como, quiero, para), al redactarlo nos indicará la regla de negocio.

Conversation (Conversación) : Es lo más valioso al redactar una Historia de Usuario, sirve para aclarar los acuerdos con nuestro Product Owner sobre la idea que se quiere plasmar, va a darnos una visión más amplia de lo que desea y nos evitará malos entendidos.

Confirmation (Confirmación) : Se realizaran los criterios de aceptación resaltando los requerimientos de una forma más específica, una vez validados, el Scrum Team entienden perfectamente el contenido de la Historia y ya estaría lista para puntuarse y desarrollarse.

Modelo INVEST:

El modelo INVEST nos indica una serie de pasos que debe cumplir nuestra Historias:

Independent (independiente) Es ventajoso que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello las historias deberían de ser totalmente independientes (lo cual facilita el trabajo posterior del equipo).

Negotiable (negociable) Una historia de usuario es una descripción corta de una necesidad . Las historias deben ser negociables ya que sus detalles serán acordados con el cliente o el usuario durante la fase de conversación.

Valuable (valiosa) Una historia de usuario tiene que ser valiosa para el cliente o el usuario.

Estimable (estimable) Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente, usuario o propietario del producto a priorizar y planificar su implementación. La estimación generalmente la realizará el equipo de trabajo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias mas fases de conversación acerca de la misma).

Small (pequeña) Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario facilitando así su estimación.

Testable (comprobable) La historia de usuario debería ser capaz de ser probada (fase confirmación de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

Estructura de una Historia de Usuario:

Debe aportar valor y la regla de negocio. Esta compuesta por los siguientes elementos:

Título.

Como — -> (Usuario /Rol)

Quiero — -> (Funcionalidad)

Para — ->(Razón/Beneficio)

Criterios de aceptación:

Pueden existir varios criterios de aceptación, son especificaciones de lo que se requiere, debemos cuidar no añadir demasiados y así mantener nuestras historias sencillas.

Dado — -> (Escenario/Condición)

Cuando — -> (Comportamiento/ Acción)

Entonces — -> (Resultado)

Ejemplo:

Sistema SMART:

“Para medir la calidad de un criterio de aceptación se utiliza el método SMART en el que se han de cumplir en lo máximo posible los siguientes criterios:

  • S — Specific (Específicos)
  • M — Measurable (Medibles)
  • A — Achievable (Alcanzables)
  • R — Relevant (Relevantes)
  • T — Time-boxed (Limitados en el tiempo)”
Imagen tomada del blog http://scrum.menzinsky.com

Dato: Hay varias herramientas en línea que pueden utilizar para la gestionar las historias: https://trello.com , https://www.pivotaltracker.com.

Implementar la creación de Historias de Usuario nos puede ayudar a tener orden en los requerimientos que solicite el cliente, tendremos una comunicación constante que nos dará una idea completa sobre el producto y una mejor visión de los pasos a seguir.

Fuentes:

http://scrum.menzinsky.com

https://www.scrummanager.net

--

--