¿Hay alguna forma estándar de saber cuándo dejar de escribir historias de usuarios y, de ser así, cuál es la base de esto y cómo se aplica a los sprints futuros?
No conozco personalmente un método estándar per se. Realmente se reduce a una combinación de su metodología y las expectativas de sus clientes.
He descubierto que es mejor comenzar a codificar tan pronto como tenga "suficientes" historias de su cliente para comenzar. Como han dicho otros, esto podría ser para una sola iteración, sin embargo, podría ser para más. Su medida suficiente debe guiarse por la frecuencia con la que tiene la intención de liberar el código de trabajo a su cliente, y en lugar de que su cliente le brinde una lista interminable de historias (muchas de las cuales probablemente nunca se realizarán, o podrían cambiar o no) haga su fecha límite de lanzamiento principal), es mejor pedirle a su cliente las primeras 3-5 funciones más importantes y de mayor prioridad. Cuando los haya completado y entregado a su cliente, usted recopilará las siguientes características 3-5 más importantes, etc. Pida más o menos dependiendo de la duración de sus iteraciones.
Su cliente o contrato o fecha límite tal vez lo guíen en cuanto a cuándo dejar de pedir historias, pero mientras tanto, ha estado pidiendo historias y deteniéndose tan a menudo como ha tenido iteraciones. Cuando, de común acuerdo, usted y el cliente sientan que el producto es lo suficientemente completo, puede decidir qué hacer con las historias sobrantes que el cliente aún no le haya dado.
La principal ventaja de este enfoque es que terminas entregando el mayor valor al cliente por adelantado, y a medida que el proyecto crece y pasa el tiempo, la cantidad de valor que estás entregando al cliente disminuye hasta el punto en que el cliente puede hacer un decisión sobre el "último 20% de las características" que podrían haber deseado y que en realidad nunca se utilizarían. También reduce el tiempo perdido en elementos triviales y de baja prioridad, poniendo la responsabilidad (y el estrés) de priorizar y programar las iteraciones de nuevo en el cliente, y todo basado únicamente en las necesidades del cliente. Sin embargo, eso no significa que no deba brindar orientación al cliente para evitar cuellos de botella de programación difíciles que pueden ser evidentes a medida que habla de los requisitos con el cliente.
Lea el Desarrollo de software Lean de Poppendeicks si desea una descripción más detallada de este enfoque en un contexto más amplio.