El tema central de esta publicación girará entorno a estos dos elementos, las historias de usuario o user stories (US), y los criterios de aceptación, y los errores más comúnmente extendidos sobre ambos.
De dónde viene el término Historias de Usuario y los Criterios de Aceptación.
Las Historias de Usuario son una práctica originaria de XP (eXtreme Programming), definido por primera vez por Kent Beck (su creador).
Con respecto de las Historias de Usuario existen muchas fuentes a las que acudir para obtener información, Jeff Patton habla sobre ellas en el siguiente documento y Martin Fowler lo hace en este enlace.
El termino Criterios de Aceptación es algo que ya se trataba en el PMBOK (validación) antes de la existencia de XP y Agile, aunque si nos ceñimos al mundo Agile, la «primera» referencia se encuentra también en XP, donde se habla de Test de Aceptación (diferentes a criterios).
Algunos de los erróres más comunes entorno a las Historias de Usuario y los Criterios de Aceptación.
Veamos ahora cuales son los errores más extendidos con respecto de estos dos términos:
- Si tenemos en cuenta lo anterior, y nos llevamos esto a un marco como Scrum, ni las Historias ni los Criterios de Aceptación son parte del framework, ni parte imprescindible del mismo, aunque pueden usarse en el.
- En el caso de Scrum, el Product Backlog lo forman los PBIs (Product Backlog Items) y un tipo de estos son las US, en ningún caso el Product Backlog lo forman únicamente las US.
- Las historias buscan promover una conversación (y reflejarla – CCC Card, Conversation, Confirmation – ). En XP las historias las escribe el usuario, pero en un ámbito Scrum pueden ser escritas por «cualquiera» (en Scrum el accountability del PO permanecerá).
- Si decidimos añadir los Criterios de Aceptación a las Historias, el PO tiene su accountability pero no tiene por qué escribirlos o definirlos el/ella.
- Lo anterior no implica que porque el Equipo de Desarrollo pueda escribir las Historias, estas estén escritas en un lenguaje técnico, al contrario, deben ser entendibles por todos (lenguaje de negocio).
- No existe un número máximo-mínimo de Criterios de Aceptación por Historia, aunque un número elevado de Criterios puede ser indicador de que esa Historia pueda ser dividida en partes más pequeñas.
- Los Criterios de Aceptación y los Test de Aceptación no son lo mismo:
- Criterio de aceptación: Qué espero conseguir con algo. Indican qué hará el sistema y para qué vale. Se trata de una definición alto nivel escrito en lenguaje de negocio.
- Test de aceptación: Cómo voy a demostrar que se cumplen los Criterios. Se establecen los pasos a seguir y sus resultados esperados. Son de ámbito técnico.
Espero que os haya resultado de interés.
5 comments On Historias de Usuario y Criterios de Aceptación: Errores comunes.
Si cada uno de los PBIs tienen que aportar valor a negocio teniendo como objetivo cumplir con una espectativa de negocio ¿qué otros PBIs existen en Scrum que no son Historia de Usuario?. Si además tienen que estar escritas en lenguaje natural entendible por negocio siendo un recordatorio de la funcionalidad requerida, ¿por qué no escribirla el PO para el cuál será más fácil que para otro que tenga que ponerse en su lugar?
Buenas Eva.
Gracias por tu comentario.
El incremento es lo que tiene que aportar valor, valor al usuario (no a negocio), es para/por eso por lo que construimos el producto.
Los PBIs pueden ser historias de usuario, historias técnicas, tareas de documentación, bugs… Las historias de usuario (como habrás leído) no son un elemento del marco.
Las historias (e insisto que no pertenecen a Scrum) deben estar escritas en lenguaje de negocio (entendible por todos) y deben reflejar una conversación, nadie dice que el PO no pueda escribirlas solo que puede “delegar” la tarea (no el accountability). Después el equipo de desarrollo será quien las descomponga en tareas.
Para el/la PO puede ser igual de difícil o fácil escribirlas que para cualquier otro miembro del equipo. Y sobre todo y ante todo “conversaciones cara a cara”. Si el equipo participa de la creación/definición, el entendimiento del producto, será mucho más profundo y la responsabilidad compartida.
Espero haberte respondido.
Hola,
Implícitamente asumí que los Criterios de Acep´tación deben establecerse con el fin de que luego se utilicen en los Test de Aceptación con el fin validar o probar que se logró el objetivo o requisito planteado en un PBI (y así con cada PBI). Lo más cercano que encontré en la guía Scrum 2020 de forma explícita es la Aceptación de Hecho (DoD), que es transversal a todos los PBI y que efectivamente no son los Criterios de Aceptación.
Entonces, sino se tienen Criterios de Aceptación que opinas de ¿cómo verificar o probar el logro de un PBI?.
Saludos,
Buenas Erick, gracias por tu comentario.
Lo que la guía define es la Definición de Hecho (DoD) no la aceptación de hecho, que busca un entendimiento compartido de lo que es hecho; esto puede incluir que se cumplan los criterios de aceptación o no.
Teniendo en cuenta que los PBIs pueden ser de distinta naturaleza (Bugs, Historias de Usuario…) no todos incluirán Criterios de Aceptación; si tenemos en cuenta que «algunos» de los PBIs buscan resolver un problema al usuario, estos deben incluir los criterios que nos permitan validarlo (cómo -expresado en lenguaje de negocio-).
Importante, los test de aceptación no son lo mismo que los criterios.
Espero haber respondido a tu pregunta.
Saludos.
Hola, si muy valiosos tus comentarios. Gracias