Historias de usuario listas para estimar
Tres ejemplos trabajados para descubrir alcance, pruebas y dependencias antes de elegir una carta.
Preparar no significa conocer todos los detalles
Una historia lista para conversar tiene un resultado comprensible, límites y preguntas visibles. No necesita una especificación exhaustiva. El refinamiento ayuda precisamente a descomponer y aclarar el trabajo conforme aprendéis sobre él.
Los siguientes ejemplos son ficticios y están creados para practicar. No les asignamos puntos predeterminados: el tamaño depende del producto, las dependencias, las prácticas de calidad y las referencias del equipo. Empezad por preguntar qué entendéis que hay que entregar.
Esta lista es una ayuda de preparación, no una regla oficial de Scrum ni una barrera para conversar sobre trabajo todavía incierto. Cuando una historia no se puede estimar, también es útil salir con una pregunta mejor formulada.
Ejemplo 1: buscar pedidos por referencia
Resultado: una persona de soporte encuentra un pedido introduciendo su referencia completa. La API ya admite esa búsqueda y existe un campo de búsqueda reutilizable. Quedan fuera las coincidencias parciales y los nuevos filtros.
Criterios de aceptación: una referencia válida muestra el pedido autorizado; una referencia inexistente muestra un estado vacío; un fallo de red ofrece reintentar sin perder el texto. La búsqueda debe poder utilizarse con teclado y mostrar una etiqueta comprensible.
Antes de votar, preguntad cómo se comprueban los permisos, qué ocurre con espacios al pegar una referencia y si las pruebas de la API cubren el contrato que necesita la pantalla. Si la API no existe, ya no estáis estimando el alcance descrito al principio.
Comparad con una búsqueda similar terminada. Si esta incorpora un nuevo modelo de permisos, explicitad la diferencia. El parecido visual entre dos pantallas no basta para afirmar que tienen el mismo tamaño.
Ejemplo 2: desactivar un correo de resumen
Resultado: una persona con cuenta puede desactivar el resumen semanal desde sus preferencias. Se mantienen los correos necesarios para recuperar el acceso. Queda fuera elegir una frecuencia personalizada.
Criterios de aceptación: la preferencia se conserva al volver a entrar; el proceso de envío respeta el cambio; un error al guardar permite recuperar el estado anterior. El equipo debe decidir qué ocurre si el resumen ya está en la cola de envío.
La incertidumbre principal puede estar en el proceso que envía correos, no en el interruptor de la interfaz. Invitad a quien conozca ese proceso a aclararlo antes de estimar. Si falta información sobre las colas, definid una investigación sobre ese comportamiento.
Para dividir, podéis empezar por una preferencia binaria y dejar frecuencias adicionales para otra historia. Cada parte debería poder comprobarse de principio a fin. Separar la interfaz del proceso de envío dejaría una preferencia que aparenta funcionar sin modificar los correos.
Ejemplo 3: exportar los resultados de un informe
Resultado: una persona autorizada descarga en CSV los resultados filtrados de un informe. Esta es una historia de un producto ficticio, no una funcionalidad anunciada de StoryFlop. El archivo contiene las columnas acordadas y una cabecera legible.
Antes de votar, concretad el volumen esperado, el formato de fechas, los caracteres especiales y los permisos. ¿Se exporta la página visible o todo el resultado filtrado? ¿Qué ve la persona mientras espera? Dos respuestas distintas pueden implicar soluciones muy diferentes.
Criterios de aceptación: el archivo corresponde a los filtros aplicados; conserva acentos; se abre correctamente en la herramienta objetivo; y no expone filas que la persona no puede consultar. Incluid las comprobaciones de seguridad y el tratamiento seguro de valores interpretables como fórmulas.
Si el volumen hace incierto el enfoque, investigad con un conjunto de datos representativo y autorizado. Una posible división es entregar primero un alcance de exportación explícitamente limitado que siga resolviendo una necesidad real, en lugar de prometer una exportación completa sin conocer su coste.
La comprobación común antes de votar
Pedid a dos participantes que expliquen la historia con sus palabras. Si describen resultados distintos, aclaradlos antes de comparar cartas. Después revisad pruebas, revisión, permisos y dependencias: forman parte del trabajo que el equipo necesita terminar.
Registrad lo que queda fuera para evitar que reaparezca como un supuesto durante la ronda. Si una pregunta puede cambiar mucho la solución, acordad quién la resolverá y cuándo volveréis a revisar la historia.
Usad la plantilla de refinamiento para conservar esas respuestas. Una vez definido el alcance, podéis llevar el título y la descripción a una sala de StoryFlop. Tras la conversación, trasladad el acuerdo a vuestro backlog para mantener el contexto cuando empiece el trabajo.
- Podemos explicar el resultado esperado
- Sabemos cómo comprobarlo
- Hemos hecho visibles dependencias, límites y preguntas
Pásalo a la práctica
Fuentes y lecturas
Los ejemplos y las instrucciones de uso de StoryFlop son propios de esta sección. Estas fuentes permiten consultar el contexto del método y del refinamiento: