Concéntrese en el qué y el por qué y evite el cómo al escribir las historias de los usuarios.
Lo que enfrenta es en realidad un ejercicio muy bueno para todos los desarrolladores. Poder expresar el requisito en términos simples y comerciales es una habilidad importante.
Debe centrarse en el requisito general, como "la necesidad de poder hacer una única selección de una lista desplegable de objetos para que el usuario pueda habilitar la acción Foo" en lugar de especificar el uso de un cuadro combinado o cuadro de lista o lo que sea que desencadene una rutina específica .
Otra forma de abordar esto es fingir que la base / marco de código subyacente es un cuadro negro casi completo. Cada vez que te encuentres diciendo "usar objeto XYZ", puedes autoverificarte preguntando si lo sabrías en un sistema de caja negra.
Actualización:
OMI, está bien poner detalles en un caso de uso que indique el nivel de detalle requerido para la información. Por ejemplo, con un sistema de inscripción es un juego justo para especificar
: apellido; campo obligatorio
: nombre; campo obligatorio
: ID de cuenta; el sistema no generó ninguna entrada necesaria
: signo astrológico; campo opcional: (sugerencia) ¿proporciona una búsqueda al ingresar la fecha de nacimiento?
- etc.
La clave es que no está especificando el cómo técnico para esa información. Si te encuentras diciendo "usa una clase de cadena / matriz de caracteres / o campo varchar" para el apellido, entonces sabes que estás sobreespecificando.
Si es multilingüe, use dos idiomas diferentes como prueba de fuego. Por ejemplo, las cadenas en C son generalmente matrices de caracteres (acter), mientras que C ++, Java y C # (está bien, y casi todos los demás ...) tienen un objeto similar a una cadena real. Si descubre que su especificación se invalida al usar uno de esos idiomas, sabrá que ha especificado en exceso.
Vale la pena señalar que estoy usando específicamente el término Caso de uso en lugar de Historia de usuario , aunque la variante que termino usando es un híbrido de ambos. Mi objetivo de un caso de uso es dar una visión general de lo que está sucediendo (una historia de usuario en el sentido más estricto) pero luego trabajar a través de los actores, los sistemas y la funcionalidad general que se requiere. Mi enfoque está más cerca de lo que Fowler sugiere en ese artículo de Wikipedia en lugar del enfoque de Cockburn.
Así que tendré un caso de uso único (más o menos) para el escenario de inscripción o el elemento de trabajo. Si es realmente complejo, lo dividiría en múltiplos, pero eso no es gran cosa. El caso de uso se puede dividir en tareas individuales según sea necesario. Lo que se arroja a un scrum particular depende de muchas variables, pero no hay nada dentro de este enfoque que le impida tener un componente demostrable al final del scrum.
