«Permitir que el cliente cambie la dirección de entrega» parece un cambio pequeño en el backlog de Mercato. La cuenta ya contiene direcciones y la página del pedido ya muestra una. Durante el refinamiento, sin embargo, el equipo descubre que el almacén recibe los datos de entrega en cuanto se confirma el pago. Una modificación en la web puede no llegar nunca al paquete que se está preparando.
Este caso hipotético muestra cómo puede ayudar un Product Owner a detectar dependencias antes de seleccionar un elemento para un Sprint. La conversación parte del resultado que espera el cliente y avanza mediante las preguntas que cambian el alcance. Su resultado es una comprensión actualizada del trabajo, incluidas las dudas que todavía necesitan evidencias.
El refinamiento aclara el trabajo próximo
El refinamiento del Product Backlog consiste en descomponer y añadir detalle a sus elementos para que el equipo pueda entenderlos con mayor precisión. Puede ocurrir en una conversación, al revisar la documentación de un proveedor o al examinar un caso de un cliente. Los equipos pueden reservar sesiones para parte de ese trabajo, pero el refinamiento es una actividad continua, no uno de los eventos prescritos por Scrum.
El Product Owner aporta el resultado esperado, las reglas de negocio relevantes y el orden del trabajo. Los Developers aportan conocimiento del sistema y son responsables de dimensionar los elementos. Otras personas participan cuando se necesita su conocimiento: alguien del almacén puede explicar un límite operativo que ni Producto ni Ingeniería han visto en la aplicación. Exigir que todos los detalles de cualquier trabajo futuro estén resueltos consumiría tiempo en decisiones que pueden cambiar antes de implementar.
Empezar por el resultado y el límite del cambio
En Mercato, la petición inicial mezcla dos necesidades: actualizar una dirección guardada en la cuenta y cambiar el destino de un pedido ya pagado. La primera afecta a compras futuras. La segunda puede afectar a la preparación, los gastos de envío y un paquete que ya está en marcha. Separar ambos casos evita confundir una estimación para un formulario de la cuenta con una estimación para todo el proceso de entrega.
El Product Owner puede aclarar qué problema del cliente se quiere abordar primero y qué significaría resolverlo. En este ejemplo, el equipo se centra en corregir el destino de un pedido pagado antes de que empiece su preparación. Es un alcance propuesto para discutir; todavía queda por comprobar si los sistemas actuales lo permiten.
Seguir la información más allá de la pantalla
La dirección que aparece en la web es solo una copia de la información. El servicio de pedidos, el almacén y el transportista pueden conservar versiones propias. El equipo necesita saber qué sistema controla el destino en cada fase y cómo llega una corrección a los demás. Un esquema sencillo del recorrido puede revelar un paso pendiente sin que el Product Owner tenga que elegir la arquitectura técnica.
Si el almacén solo admite cambios antes de un estado concreto, la web necesita conocer ese estado de forma fiable. También puede haber una coincidencia temporal: el cliente envía la corrección justo cuando el almacén empieza a preparar el paquete. El refinamiento debe hacer visible la necesidad de una decisión coherente y de una confirmación veraz al cliente. Ingeniería investiga después cómo conseguirlo con los sistemas reales.
La guía para leer un diagrama de arquitectura ayuda a seguir los componentes y sus dependencias. La guía práctica de APIs explica los intercambios de una integración. Aquí esos conceptos sirven para una tarea más acotada: identificar qué hace falta conocer antes de planificar este cambio de dirección.
Preguntas que cambian el alcance del elemento
Las preguntas siguientes sirven para orientar la conversación, no como cuestionario obligatorio para cada elemento. Su utilidad está en la decisión que revelan. Si un proveedor no puede confirmar el cambio de forma inmediata, por ejemplo, «dirección actualizada» puede tener que convertirse en «cambio solicitado» hasta que llegue la confirmación.
- ¿Qué estados del pedido permiten una corrección y qué sistema decide cuándo termina ese plazo?
- ¿La nueva dirección cambia la cobertura o el precio del envío y quién puede aceptar un cargo adicional?
- ¿Cómo reciben la corrección el almacén y el transportista y qué confirmación puede dar cada uno?
- ¿Qué debe ver el cliente si el cambio se rechaza, se retrasa o solo lo acepta uno de los sistemas?
- ¿Quién puede cambiar la dirección y cómo se impide el acceso a pedidos de otro cliente?
- ¿Qué entorno y pedidos de prueba permiten comprobar el recorrido sin afectar a entregas reales?
Algunas respuestas dependen de una decisión de negocio y otras requieren investigación técnica. Distinguirlas importa al acordar el trabajo posterior. «Que lo revise Ingeniería» resulta demasiado impreciso si lo que falta es decidir si Mercato asumirá un envío más caro. Un registro breve de la pregunta, quién la resolverá y qué bloquea ayuda a mantener visibles ambos tipos de incertidumbre.
Registrar la duda junto con la siguiente acción
| Duda pendiente | Siguiente acción | Decisión afectada |
|---|---|---|
| ¿Puede el almacén rechazar una corrección cuando empieza la preparación? | Ingeniería revisa el contrato del proveedor y un caso de prueba representativo. | Los estados que permiten el cambio y la confirmación que verá el cliente. |
| ¿Quién paga si el nuevo destino cuesta más? | Producto revisa la política con Operaciones. | Si la primera versión permite cambiar de zona de entrega. |
| ¿Se puede probar el recorrido del transportista de forma segura? | QA e Ingeniería confirman los datos de prueba y las restricciones del entorno. | El plan de comprobación y si el elemento se puede completar en un Sprint. |
Una investigación con tiempo limitado puede ser adecuada cuando una incógnita concreta cambia la viabilidad o el tamaño del trabajo. Debe aportar evidencias para decidir, como una limitación confirmada del proveedor o una petición y respuesta demostradas. Si termina únicamente con «hace falta más análisis», puede ser necesario acotar mejor la pregunta antes de dedicar más capacidad.
Dividir el trabajo alrededor de un resultado utilizable
Una vez entendido el comportamiento del almacén, el equipo puede encontrar un alcance menor que resulte útil: permitir correcciones dentro de la misma zona de entrega antes de empezar la preparación y con confirmación del almacén. Modificar la dirección guardada en la cuenta queda separado. La corrección acotada del pedido solo se sostiene por sí misma si funciona a través de los sistemas implicados y cumple la calidad acordada.
Crear un elemento para la pantalla y otro para la integración puede ayudar a organizar tareas, pero una pantalla que anuncia un cambio sin confirmar no ofrecería el resultado previsto al cliente. Los Developers pueden dividir la implementación en tareas mientras el elemento del backlog conserva un resultado verificable. Si todavía no existe una parte segura y utilizable, el equipo debe mantener visible la dependencia en lugar de dar el trabajo por preparado porque su redacción sea breve.
En este momento, los ejemplos de criterios de aceptación pueden ayudar a expresar el comportamiento acordado. Una restricción arquitectónica más amplia puede dar lugar a una intervención separada; el artículo sobre deuda técnica y funcionalidades en el backlog examina cómo comparar ese trabajo con la oportunidad inicial.
Cerrar la conversación con el elemento actualizado
El resultado del refinamiento debe quedar donde el equipo encontrará el trabajo: su propósito, el alcance acordado, los casos relevantes, las dependencias y las dudas abiertas. Una comprobación útil consiste en ver si alguien puede explicar el resultado previsto y qué sigue impidiendo planificarlo. Las decisiones que solo quedan en la grabación de una reunión o en un mensaje privado se pierden con facilidad cuando otra persona retoma el elemento.
Scrum describe como preparados para su selección en Sprint Planning los elementos que se pueden completar dentro de un Sprint. No prescribe una Definition of Ready formal ni exige que desaparezca cualquier incertidumbre. El equipo puede acordar comprobaciones de preparación, siempre que ayuden a conversar y aprender en lugar de convertirse en una cola de aprobaciones. El nivel de detalle debe corresponder a la proximidad del trabajo, su riesgo y las dudas que todavía quedan.
El libro Arquitectura de software para Product Managers desarrolla cómo los componentes y las dependencias condicionan un cambio de producto. APIs para Product Managers amplía el contexto para conversar sobre servicios externos, respuestas y casos de fallo.
Referencias
- La Guía Scrum: refinamiento del Product Backlog, dimensionamiento y Sprint Planning.
- Atlassian: preparación práctica de una conversación de refinamiento.