Lo sé, necesitamos separar esta tarea en varias subtareas. Pero, ¿qué debemos hacer, si una mayor división de esta tarea no tiene sentido? ¿Qué sucede si todas las subtareas resultantes no tendrán valor comercial hasta que todas se realicen e integren juntas?
Tal vez parezca que esta es una situación un poco artificial, pero a veces podría suceder (especialmente, si tienes sprints cortos).
Ejemplo de mi práctica: tenemos User Story para permitir que el usuario realice pagos desde nuestro sistema. Como parte de esta historia, tenemos la tarea de integrar el servicio de pago de terceros a nuestro proyecto. Por lo tanto, todas las subtareas de esta tarea son absolutamente técnicas y no tienen valor comercial.
Entonces, solo veo tres formas de resolver este problema:
Separe la tarea valiosa del negocio de varias tareas técnicas. Pero en este caso no haremos nada útil en el primer sprint y no tendremos nada que mostrar en la revisión.
Haz todos los sprints más grandes. Tal vez nuestros sprints sean demasiado cortos y será mejor hacerlo más grande. En este caso, reduciremos la velocidad de retroalimentación, pero una situación como la que describo a continuación nunca volverá a ocurrir.
Haz que el sprint actual sea más grande. Como sé, esta no es una solución de scrum. Scrum como la constancia (haga Daily Scrum en el mismo lugar y al mismo tiempo, tiempos fijos limitados, etc.). Además, será difícil conciliar el nuevo día de revisión con las partes interesadas. Si tiene otros equipos que trabajan en el mismo proyecto, los problemas con esta solución serán mucho mayores.
¿Qué solución es mejor? O, tal vez, ¿alguien sabe una mejor manera de resolver este problema?
... incluso si no es algo que realmente puedas usar.
Tomando su ejemplo, si va a aceptar Visa, MasterCard y PayPal, primero puede implementar PayPal (o lo que sea más fácil de implementar) y luego tener historias separadas para agregar Visa y Mastercard.
Si va a aceptar pagos recurrentes (por ejemplo, una suscripción mensual), primero puede implementar pagos únicos y luego agregar los pagos recurrentes en otro sprint.
Aquí hay algunos consejos para dividir historias de usuarios más grandes:
Patrones para dividir historias de usuario
8 estrategias útiles para dividir grandes historias de usuarios (y una hoja de trucos)
"Hacer más grande el sprint actual" no es una buena opción. Además de los problemas que enumeraste, no puedes establecer una velocidad de equipo decente si sigues cambiando la duración del sprint.
"Hacer todos los sprints más grandes" es una opción posible, si te sigues encontrando con este tipo de problema a menudo, después de hacer todos los esfuerzos para dividir historias más grandes.
En primer lugar, abordemos el asunto práctico: si está en una planificación y tiene una historia que es la prioridad más alta pero no ve cómo desglosarla y retener el valor comercial, es mejor dividirla técnicamente y moverse adelante que a) hacer girar las ruedas en esa historia o b) hacer cambios disruptivos en la estructura, como cambiar la duración del sprint.
Dicho esto, hay un malentendido común en Scrum de que para que una historia sea valiosa y se pueda enviar, debe ser una característica completa y lista para la producción. Para usar su ejemplo de pago, la forma en que funcionan la mayoría de los sistemas de pago de terceros, requiere algo de trabajo para conectarlo y mucho trabajo para manejar diferentes escenarios posibles que podrían surgir. La funcionalidad de pago definitivamente no está completa hasta que esté completamente integrada, pero aún hay valor en las piezas. Si lo lleva al punto de que una tarjeta de crédito, ingresada correctamente con suficientes fondos disponibles, funciona y todo lo demás se trata como un error general, definitivamente hay valor comercial allí y se puede enviar. Por supuesto, las circunstancias en las que lanzaría esto a la producción son pocas y distantes entre sí, pero podría hacerlo si estuviera justificado.
Lo difícil de estas historias es que requiere algo de tiempo y colaboración para trabajar. Si desea probar una técnica, puede echar un vistazo a mi publicación de blog sobre este tema. Sin embargo, lo que realmente se reduce a esto es que debe colaborar con el equipo para ayudar a mostrar las piezas del proceso de implementación de la historia y luego el PO evalúa dónde ven el valor.
a veces sucede, tendrá funciones que no se pueden entregar por completo durante un sprint. debe considerar dividirlo en subtareas, que no generarán valor comercial por sí mismas, pero pueden demostrarse y verificarse después de cada sprint.
considerando su ejemplo de sistema de pago, podemos tener tres sprints para entregar resultados finales:
el orden de los sprints se puede cambiar para presentar la parte más riesgosa, pero aún así, toda la funcionalidad solo aportará valor comercial si esos escenarios se cubren hasta cierto punto. pero después de cada sprint, tendrás algo para demostrar.