Trabajando de manera ágil, el equipo del proyecto entrega de forma rutinaria partes del software, que se describen en Historias de usuarios. En cada Sprint se entrega un software funcional, con algunas funciones adicionales agregadas.
La ventaja y el inconveniente de las Historias de usuario es que describe una función completa. El desarrollo de código para User Story tiene varias subtareas, y el problema es que algunas tareas no se pueden entregar dentro de Sprint, a menudo hasta el final del proyecto. Tales tareas son como: integración con API de terceros, dependencia de un sistema externo.
Por ejemplo, proyecto de desarrollo web:
WEB-122: "Como cliente, veo la pantalla de confirmación del pedido, donde puedo revisar los artículos pedidos, el monto total, la información fiscal. Hago clic en el botón Pagar ahora para ser transferido a la página SomeExtravagantPaymentService y finalizar el pago"
Problema: el cliente solo está negociando con SomeExtravagantPaymentService y no puede proporcionar detalles de inicio de sesión. Además, el servicio no proporciona la opción beta o sandbox para enviar mensajes de texto (en Europa es bastante común), depende de una API de terceros.
Por ejemplo, proyecto de construcción de vivienda:
DWELL-234: "Quiero tener electricidad y bombillas en el sótano instaladas, controladas por interruptor".
Problema: incluso si los interruptores y las bombillas se instalaron correctamente, esta historia de usuario no se puede terminar y probar hasta que la compañía eléctrica conecte la casa a la línea eléctrica, lo que puede suceder en etapas posteriores de desarrollo. Dependencia del sistema externo.
El problema con las historias de usuario descritas es que dichas historias no se pueden terminar durante varios sprints y se arrastrarán de un sprint a otro. El cliente no recibirá el producto terminado después del sprint. ¿Cómo podría manejarse esta situación?
El problema con las historias de usuario descritas es que dichas historias no se pueden terminar durante varios sprints y se arrastrarán de un sprint a otro.
Necesita desglosar más sus historias utilizando el modelo INVEST . Escriba sus historias de manera que cada una sea independiente y no haya una dependencia mínima o nula de otros factores.
Así que tu historia se puede reescribir así:
WEB-122a: "Como cliente, quiero realizar mi pedido para poder obtener los artículos que necesito"
WEB-122b: "Como cliente, quiero revisar mi Pedido para poder verificar los artículos pedidos, monto total, información fiscal"
WEB-122: "Como cliente, quiero pagar mi Pedido, para que mi pedido pueda ser procesado (y entregado)"
En casos ideales, una historia de usuario debe entregarse por completo en un sprint, no debe prolongarse.
Creo que el problema es que no has desglosado la historia. Cuando escriba una historia, intente dividir sus requisitos de alto nivel en el nivel más pequeño posible.
Ejemplo en el caso que has mencionado:
Como cliente, veo la pantalla de Confirmación de pedido, donde puedo revisar los artículos pedidos, el monto total, la información fiscal. Hago clic en el botón Pagar ahora para ser transferido a la página SomeExtravagantPaymentService y finalizar el pago
La historia se puede dividir en historias más pequeñas como:
Entonces, en este caso, una vez que haya terminado con la pantalla de Confirmación, puede entregársela a su cliente. Puede retomar la página SomeExtravagantPaymentService después de eso una vez que su cliente lo confirme. Hasta ese momento, estará en la cartera de productos y no se llevará a sprint.
De esta manera, puede realizar un seguimiento de su historia y puede entregar historias de usuario completas a su cliente al final del sprint y puede evitar llevar una tarea al siguiente sprint.