¿Cómo escribes una historia de usuario que los ingenieros encuentren realmente útil?

Las historias útiles llevan el porqué y el límite, no solo el qué. Mantén al usuario y el resultado en la frase, y después dedica casi todo tu esfuerzo a criterios de aceptación que nombren los casos límite: estado vacío, permiso denegado, sin conexión y qué pasa cuando algo falla. Los ingenieros no necesitan poesía, necesitan saber cuándo han terminado y qué casos pueden ignorar sin riesgo.

La parte que los ingenieros usan de verdad son los criterios de aceptación, así que ahí es donde invierto el tiempo. La frase de la historia lleva el porqué en una línea, pero después enumero los casos: qué pasa con un estado vacío, qué ve un usuario sin permisos, qué pasa si la petición falla a mitad, qué hacemos con una conexión lenta. Esas son las preguntas que si no me llegarían por Slack tres días después, y cada una es una decisión que debería tomar yo y no un ingeniero adivinando a las once de la noche. También escribo lo que queda explícitamente fuera, porque eso frena el perfeccionismo bienintencionado. Y repaso los criterios con el ingeniero antes de que se estime el ticket. Cuesta diez minutos y normalmente saca a la luz un requisito técnicamente caro y con casi ningún beneficio para el usuario, que entonces puedo quitar. Una historia que se estima sin esa conversación es básicamente un deseo.