ARTEFACTOS SCRUM - PBI VS HISTORIA DE USUARIO

Vamos a ver qué tipo de elementos son los que pueden incluirse dentro de la Pila de Producto. La guía de Scrum nos habla que dentro de esta Pila de producto lo que hay son Elementos de la pila del Producto, PBI de sus siglas en inglés Product Backlog Item. Parece lógico, ¿verdad? 

Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor. La guía de Scrum no habla de ningún atributo más relacionado con los PBIs. Además, estos pueden contener cualquier información adicional adjunta que pueda ser relevante para la terminación de ese elemento como por ejemplo diagramas de uso, borradores de pantallas, datos de encuestas, gráficas o cualquier otro elemento.

Por otro lado, es habitual hablar del concepto de Historias de Usuario. Incluso oirás hablar a algún que otro “experto” de que la Pila de Producto está formado Historias de Usuario. Espero que te haya quedado claro que esto no tiene porqué ser así. En una Pila de producto hay PBIs y estos, pueden tener un formato concreto de Historia de Usuario, o no. Pero es erróneo decir que dentro de una Pila de Producto siempre hay Historias de usuario.

HISTORIAS DE USUARIO

 Vamos a hablar un poco más a fondo de lo que son ya que, como decíamos antes, son uno de los formatos más utilizados por equipos ágiles. 

Lo primero que debemos saber es su origen. Este concepto fue acuñado por Kent Beck en su libro Extreme Programming (1999). Se define como una descripción simple y corta de una funcionalidad, expresada desde la perspectiva de la persona que desea cubrir esa necesidad, generalmente el usuario de nuestro sistema.

Ron Jeffries explica que una Historia de Usuario debe cumplir con la regla de las 3Cs. Esto es: 

• Card (Tarjeta): Las historias de usuario tradicionalmente se escriben en tarjetas de papel o post-its ya que recordemos que la principal intención de una historia de usuario es que sea corta, tratando de captar la esencia de la necesidad.
• Conversation: Una historia de usuario debe ser el resultado final de una conversación. Esta conversación es realmente lo importante. Idealmente debería producirse entre las personas que van a construir la funcionalidad (equipo de construcción) y las personas que tienen esa necesidad (usuarios y clientes). 
• Confirmación: Es una parte importante de la historia de usuario ya que nos permite definir los criterios por los cuales sabremos si la historia resuelve el problema o no. Esta confirmación suele expresarse la mayoría de veces como Criterios de Aceptación y ya veremos que también se pueden escribir en un formato concreto.

Siguiendo con el formato de la descripción, existe una plantilla ampliamente utilizada:

• Como <Tipo de usuario>
• Quiero <Necesidad a implementar>
• Para <Beneficio u objetivo que esperamos conseguir>

Un ejemplo aplicado podría ser:

• Como <usuario registrado en la web> 
• Quiero <poder cambiar mi dirección de correo electrónico>
• Para <facilitarme que en caso de que quiera introducir otra dirección pueda hacerlo>

 En este caso estamos utilizando dentro de la sección “Cómo” un tipo de usuario que puede acceder a la web (el registrado) ya que puede haber muchos otros (el no registrado, por ejemplo). Una evolución de esto sería construir arquetipos de tipología de clientes de tal manera que personificamos aún más la Historia de Usuario. A estos arquetipos también se les conoce como User Personas y no dejan de ser una representación de nuestros usuarios. Los User Personas son personificaciones ficticias que representan a un cliente. Un ejemplo suponiendo un contexto de una tienda on line de alimentación:

Además, a este arquetipo podríamos añadirle fotos de cómo podría ser físicamente esta persona o como nos la imaginamos. También podríamos hablar de aficiones, hobbies, etc.

El objetivo no es otro que tratar de empatizar aún más con los usuarios para los que estamos construyendo funcionalidad. 

De esta manera la anterior Historia de Usuario podría quedar utilizando el arquetipo de Luis Pérez: 

• Como <Luis Pérez >
• Quiero <poder cambiar mi dirección de correo electrónico>
•  Para <facilitarme que en caso de que quiera introducir otra dirección pueda hacerlo>

La confirmación que necesita la Historia de usuario suele plasmarse a modo de Criterios de Aceptación. Existe también una plantilla ampliamente utilizada para escribir estos Criterios de Aceptación: 

• Dado <contexto>
•  Cuando <acción>
•  Entonces <resultado>

Un ejemplo siguiendo con la Historia de Usuario anterior: 

Historia de Usuario

•  Como <Luis Pérez>
• Quiero <poder cambiar mi dirección de correo electrónico>
• Para <facilitarme que en caso de que quiera introducir otra dirección pueda hacerlo>

CRITERIOS DE ACEPTACIÓN

 1. Cambio correcto 

• Dado el email “luis@yo.com” 
• Cuando modifico el email por “luisPerez@yo.com” 
• Entonces el nuevo email es “luisPerez@yo.com” 

2. Existencia de @ 

• Dado el email “luis@yo.com”
•  Cuando modifico el email por “luisPerezyo.com”
•  Entonces se muestra el error “Tu email deben contener una @”

3. Existencia de dominio 

• Dado el email “luis@yo.com” 
• Cuando modifico el email por “luisPerezyo.c” 
• Entonces se muestra el error “Tu email no pertenece a un dominio válido”

Hemos elegido un caso muy sencillo con poco margen para la duda, pero según se vaya complicando. Podemos ver como los criterios de aceptación representan escenarios posibles dentro del cambio de email que le servirá a los desarrolladores para implementar estas funcionalidades. El criterio de aceptación nos debe servir como guía para revisar la Historia de Usuario en la Reunión de revisión o demo al final del Sprint.

En resumen, las Historias de usuario son uno de los formatos más utilizados como PBI dentro de una Pila de producto, pero no es lo único que puede haber dentro de esta pila. La Historia de usuario es una Tarjeta (Card) donde se refleja una Conversación entre nuestros usuarios y el equipo de construcción idealmente. Además, deberá tener unos criterios Confirmación para asegurarnos que se construye lo adecuado.