Mi equipo y yo estamos luchando para desglosar una historia de usuario que hemos estimado en 8 puntos.
La historia de usuario es:
"Un usuario puede registrarse en la aplicación mediante un formulario de registro para que se le conceda acceso"
La razón por la que estimamos 8 puntos es que hay muchas pruebas de aceptación involucradas.
Estoy tratando de seguir el modelo INVEST que sugiere que las historias deben ser pequeñas para que quepan en un Sprint. No sé cómo dividir esta historia de "registro" en historias más pequeñas que tengan valor para los usuarios. ¿Alguna sugerencia?
Guiaría al equipo a través del diagrama de flujo de división de la historia . A menudo, alguien tiene una idea de cómo dividirlo, utilizar todo el equipo para dividirlo suele ser mejor que tratar de dividirlo usted mismo. Dividir durante las sesiones de planificación o refinamiento.
Una división aquí podría ser algo como:
La idea es obtener comentarios de los usuarios, pero también aprendizajes de factibilidad, por ejemplo, si el equipo lo construyó. Creo que las divisiones sugeridas aquí seguramente obtendrán comentarios o aprendizajes de los usuarios.
Si un 8 es menos del 33% de tu sprint, tal vez no te preocupes demasiado por eso. Seguro que 1/6 o historias más pequeñas son ideales, pero una historia de 1/3 de vez en cuando no está mal. Solo asegúrate de que sea tu primera historia del sprint, para que no te quedes con una historia a medio terminar al final del sprint.
Una última nota, no intentes dividir prematuramente, espera el mayor tiempo posible. Dividir historias que tal vez nunca vas a recoger es un gran desperdicio.
En general, tratamos de evitar los detalles de implementación en una historia de usuario, por lo que en lugar de
Un usuario puede registrarse en la aplicación mediante un formulario de registro para que se le conceda acceso
Yo sugeriría que su historia original es:
Como usuario me gustaría darme de alta en la aplicación para poder acceder
Con algo como el registro, a menudo lo dividiría en función de lo esencial y lo agradable.
Por ejemplo:
Como usuario quiero darme de alta en la aplicación para poder acceder
La historia básica, que es un registro esencial básico, tal vez solo capturando su nombre.
Como usuario quiero que el sistema guarde mis datos para no tener que volver a introducirlos
Una historia de bloques de construcción que significa que capturamos más detalles del usuario durante el registro.
Como usuario, quiero que se valide mi entrada de datos para no usar valores incorrectos accidentalmente
Use este para agregar validación, como verificar códigos postales, etc.
Como usuario, quiero estar seguro de que mi contraseña es difícil de descifrar para que mi cuenta esté segura
Use este para agregar comprobaciones de dificultad de contraseña.
...y así.
A menudo encontrará que los criterios de aceptación se pueden convertir en historias más pequeñas si piensa en el valor que brindan desde el punto de vista del usuario.
Hay muchas formas de desglosar las historias de los usuarios, pero dado que mencionó muchas pruebas de aceptación, mi primera suposición sería desglosar los criterios de aceptación en segmentos entregables por separado. Por ejemplo, ¿tiene validación de dirección en sus criterios de aceptación? Esa puede ser su propia historia:
Como admite una aplicación, quiero que el proceso de registro valide las direcciones para reducir la cantidad de solicitudes de cuentas fraudulentas.
También miraría para ver cuál es la información mínima del formulario necesaria para registrarse. Siempre me levanta un poco de una bandera roja cuando se proporciona un formulario o una pantalla con anticipación. Por lo general, esto significa que estamos agrupando una gran cantidad de funciones relacionadas en un elemento de trabajo pendiente porque nos hemos anclado en ese artefacto. Es posible que puedas empezar con:
"Como nuevo cliente, puedo registrarme para usar la aplicación y poder acceder a las funciones bloqueadas"
Y esto podría solicitar un nombre de usuario, contraseña y correo electrónico. Después:
"Como nuevo cliente, puedo incluir mi nombre completo en el proceso de registro para no tener que ir a otra pantalla y agregarlo más tarde".
Además de desglosar aún más la historia, obligará al PO y al equipo a comprender realmente por qué un usuario querría tener esa función. Reescribí el de modo que para el último 3 veces tratando de averiguar por qué el usuario realmente querría proporcionar esa información en el registro.
Como se mencionó en un comentario, necesitaría más detalles sobre qué hace que esto sea tan difícil; esto nos daría ideas sobre dónde dividir. Pero aparte de eso, hay una forma: separar la presentación de la operación de backend. Es decir, si no puede completar esta tarea en un sprint, primero implemente el backend, de modo que un usuario pueda, en teoría, iniciar sesión mediante una simple solicitud POST; no implemente ninguna GUI, ni mensajes de error detallados, etc.
Concéntrese en hacer que esa llamada a la API sea segura como debe ser, con funciones como reforzar HTTPS, almacenar/verificar contraseñas de manera segura (es decir, usando un buen hash, no texto sin formato), entregando sus cookies de una buena manera, y así sucesivamente. Decida qué tipo de administración de sesión desea realizar (del lado del servidor en una base de datos o simplemente del lado del cliente en una cookie suficientemente cifrada). Si no puede administrar la versión más complicada en su sprint, entonces decida hacer la más fácil en su lugar y vuelva a ella más tarde.
No envíe una versión que pierda características de seguridad esenciales. Si ni siquiera puedes hacer eso en un sprint, entonces será difícil encontrar algo para mejorar, y tendrás que analizar detenidamente la duración de tu sprint...
En el próximo sprint, agregue la parte GUI; a partir de ese momento, puede entregar más fácilmente solo pequeños incrementos. Por ejemplo, en la primera versión de la GUI de inicio de sesión, solo puede implementar la ruta "positiva" y omitir todas las pelusas relacionadas con los comentarios de error. Es posible que solo haya mensajes de error genéricos en caso de problemas (o, incluso, no hay mensajes de error, solo una redirección al formulario vacío si así lo desea).
AnoE