Historias de usuario "de sistema" - Una propuesta de escritura

Hola a todos

Cuando comenzamos a introducirnos en el mundo de las historias de usuario y de Scrum, queremos poner todo en este formato, no digo que no se pueda, pero scrum en ninguna parte dice que debamos usar historias de usuario, o casos de uso, o requerimientos en prosa, solo dice es necesario ítemes de backlog para priorizar en el Product Backlog y para trabajar en el Sprint Backlog -y nada más-.

Entonces bajo esa premisa, que es decisión nuestra escribir requerimientos del sistema como historias de usuario, quiero compartir con ustedes una propuesta de como escribirlas y algunas reglas (heurística) que me han resultado útiles

La primera idea es usar el formato propuesto por Mike Cohn, para escribir historias de usuario

YO COMO______ usuario_______________
DESEO _________funcionalidad__________
PARA _______beneficio de negocio________

Por lo tanto supongamos que existe la siguiente necesidad en nuestro sistema

 "a las 12:10 AM se corra un job que determine que clientes son morosos (con moras iguales o superiores de 30 días ), les envíe un email a quienes tiene moras superiores a 30 días y múltiplos de 15 (ejemplo: 45, 60, 75, etc) sobre el estado de la deuda, y a luego envíe al callcenter un listado con las personas a llamar, y notifique si el proceso fue exitoso o fallido."

¿wow, mucho no cierto?

como muchos venimos con el paradigma de los casos de uso (y vemos el sistema como un actor, cosa correcta), nos vemos tentados a escribir la siguiente historia de usuario

---

HU30:  Notificaciones Email y CallCenter para Morosos
YO COMO sistema
DESEO generar el listado de morosos
PARA notificarles su estado crediticio y activar la llamada del callcenter

---

Esta aproximación yo no la veo correcta, pues el beneficio de negocio no le importa al sistema, le importa a alguien que tal vez sea el Gerente de Créditos, además en esta primera versión observamos el beneficio de negocio son más funcionalidades, en vez de algo como "mejorar la gestión de cartera a través del callcenter y notificación electrónica", reescribiendo sería:

---

HU30:  Notificaciones Email y CallCenter para Morosos
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a través del callcenter y notificación electrónica

---

Perfecto, pero donde nos quedaría el resto del problema: las notificaciones, el callcenter y la notificación, pues quedaría en los criterios de aceptación,  veamos:

---

HU30:  Notificaciones Email y CallCenter para Morosos
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a través del callcenter y notificación electrónica

Criterios de Aceptación

1. Enviar un email a quienes tiene moras superiores a 30 días y a  múltiplos de 15 (ejemplo: 45, 60, 75, etc) sobre el estado de la deuda
2. Enviar al callcenter un listado con las personas en mora a llamar, 
3. Notificar si el proceso fue exitoso o fallido

---

Esta versión me gustó más,  pero comenzaría preguntas como:

respecto al criterio de aceptación 1:

• ¿Cuál sería el formato del mensaje?
• ¿Qué diria el subject?
• ¿Qué contendría el cuerpo del email (montos, fechas, intereses, saludo, logo, etc)?
• ¿y si el email rebota?

respecto al criterio de aceptación 2:

• ¿qué información enviaríamos al callcenter
• ¿qué formato sería: csv, pipes, xml?

respecto al criterio de aceptación 3:

• ¿a quién notificaríamos?
• ¿que tipo de mensaje: texto, mail, whatsapp?
• ¿contenido del mensaje?

Repito: 

"mucho ¿no cierto?¿no creen que es mucha funcionalidad, partiendo de la premisa que las historias de usuario son pequeñas y a lo sumo debe costarnos 3 días para lograr el DONE?"

Además si aplicamos INVEST (ver más aquí), toda esta cantidad de funcionalidad no sea estimable fácilmente por el equipo y tal vez su tamaño implique que requiera construirse en varios Sprints.

Por lo tanto, tal vez sea necesario partir la historia de usuario en dos:

---

HU30:  Notificaciones Email para Morosos -
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a notificación electrónica

Criterios de Aceptación

1. Enviar un email a quienes tiene moras superiores a 30 días y a  múltiplos de 15 (ejemplo: 45, 60, 75, etc) sobre el estado de la deuda
2. Notificar si el proceso fue exitoso o fallido

---

***

***

---

HU35:  Notificaciones  CallCenter para Morosos
YO COMO Gerente de Créditos
DESEO generar el listado de morosos,
PARA mejorar la gestión de cartera a través del callcenter y notificación electrónica

Criterios de Aceptación

1. Enviar al callcenter un listado con las personas en mora a llamar. Mora mayor o igual a 30 días. 
2. Notificar si el proceso fue exitoso o fallido

---

***

Ahora, la pregunta es ¿entramos al detalle de especificar los puntos 1 y 2 de los criterios de aceptación de cada HU?
Y la respuesta es: depende del Product Owner y del equipo

Tal vez así sea suficiente para el equipo y con las preguntas que se hacen en el planning queden todos tranquilos.

O, tal vez requieran que las preguntas sobre los criterios de aceptación 1 y 2 se especifiquen en formato BDD (clic acá para ver).

La respuesta, no la tengo yo, la tiene cada equipo en su inspección y adaptación del proceso.

Espero les haya servido

Saludos ágiles


Jorge Abad

Post complementarios y relacionados

• Tres ideas cortas sobre las historias de usuario - Clic aquí.
• Cómo luce (se ve) una historia de usuario - un pequeño ejemplo  - Clic aquí.
• Características de una buena historia de usuario   - Clic aquí.