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
- 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
- Enviar al callcenter un listado con las personas en mora a llamar,
- 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?
- ¿qué información enviaríamos al callcenter
- ¿qué formato sería: csv, pipes, xml?
- ¿a quién notificaríamos?
- ¿que tipo de mensaje: texto, mail, whatsapp?
- ¿contenido del mensaje?
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
- 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
- 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
- Enviar al callcenter un listado con las personas en mora a llamar. Mora mayor o igual a 30 días.
- 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í.