¿Dónde poner detalles sobre los criterios de aceptación de una historia de usuario?

En esta publicación de blog sobre los criterios de aceptación, el autor explica que los buenos criterios de aceptación deberían:

• Indique una intención, no una solución (por ejemplo, "El usuario puede elegir una cuenta" en lugar de "El usuario puede seleccionar la cuenta desde un menú desplegable")

• Son independientes de la implementación (idealmente, la redacción sería la misma, independientemente de si esta característica / historia se implementaría en, por ejemplo, un sistema web, móvil o activado por voz)

• Son de un nivel relativamente alto (no todos los detalles deben estar por escrito)

Y más detalles como:

• El encabezado de la columna es "Balance"
• El formato de balance móvil es 99,999,999,999.9 D / CR
• Deberíamos usar un menú desplegable en lugar de casillas de verificación

debe trasladarse a una documentación interna del equipo o a pruebas de aceptación automatizadas

Sin embargo , a menudo escucho a personas fruncir el ceño sobre el uso de Cucumber o marcos similares para hacer pruebas de GUI. Además, el uso de una documentación interna podría generar muchos problemas debido a la falla en actualizar la documentación regularmente.

Todavía estoy luchando por encontrar una manera efectiva de capturar esos detalles durante la conversación con el cliente.

Tengo dos lugares (como propietario del producto)

Los nuevos comentarios de los clientes pueden traducirse en más historias, un cambio en las prioridades de la historia o algunos detalles nuevos sobre una historia. En el registro posterior tomo notas de estos detalles para futuras historias que de lo contrario podría olvidar. Estas son notas para mí.

Poco antes de la reunión de planificación, traduzco lo que tengo en mi cabeza + estas notas en algo que el equipo puede revisar. Este documento (usamos una página wiki por usuario épico) se refina y completa aún más durante la planificación del sprint como parte de la discusión de la historia con el equipo.

Me gusta capturar 'Restricciones' como 'PS' al final de mi historia.

[user] [actions] so that [goal]

Constraints:
- No Touching
- Actions must be gluten free

Esas restricciones son limitaciones que los clientes ponen en mi diseño, que deben tenerse en cuenta al sopesar las diferentes soluciones. Necesito conocerlas por adelantado, así que les doy mucha prioridad.

Me gusta definir pruebas de aceptación para cada estilo Story BDD como parte de la documentación de alto nivel (Características - Historias - Pruebas)

WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]

Detalles específicos como los mencionados anteriormente serían parte de una maqueta de pantalla en la que el cliente firma; Dichos detalles no siempre se conocen de antemano, pero en cualquier caso caen bajo "restricciones de diseño". Sí, cuando las maquetas se conocen de antemano, incluyo las maquetas y las restricciones de diseño acordadas en la documentación de alto nivel, porque el cliente debe firmar antes de que comience el trabajo.

Entonces, si bien conceptualmente está separado, no veo ningún daño en incluirlo en el mismo documento. Incluso si no es necesario para el cierre de sesión del cliente, es conveniente tener todos los requisitos para una característica / historia en un solo lugar.

Tomo un enfoque bastante pragmático: si un detalle técnico es importante para la aceptación de una historia, entonces debe estar en los criterios de aceptación, independientemente de lo que diga alguna publicación de blog. Si es realmente importante que el nombre de la columna sea "balance", eso debe ser parte de los criterios de aceptación.

Esto puede conducir a criterios de aceptación demasiado largos. En tal caso, creo que es necesario tener un criterio de aceptación que sea "debe aprobar el conjunto de pruebas X", y es en el "conjunto de pruebas X" donde se colocan todos los detalles esenciales sobre el producto.