«Desarrollar el checkout» es demasiado amplio para acordar una entrega concreta. Dividirlo en «crear la base de datos», «crear la pantalla» y «probar el checkout» reduce las tareas, pero ninguna permite comprar por sí sola.
Una división más útil conserva un recorrido de compra reducido que funciona de principio a fin. Use una pizarra compartida para la planificación Scrum para comparar esas partes, sus ejemplos de aceptación y lo que se deja para más adelante. Mantenga visible el resultado del cliente mientras el equipo técnico analiza las tareas necesarias.
¿Es una historia menor o solo una tarea técnica?
La definición de división de historias de Agile Alliance mantiene valor de negocio en cada historia resultante. No exige un lanzamiento comercial completo; pide que cada parte demuestre un cambio de comportamiento útil y no solo una capa técnica terminada.
El usuario puede completar una compra, recuperar un pedido o aplicar un descuento válido. No puede «usar la tabla de base de datos» sin el comportamiento que la rodea. La base de datos, la interfaz y las pruebas siguen siendo necesarias: colóquelas bajo la historia como trabajo de implementación.
La división vertical recorre las partes necesarias del sistema con un alcance reducido. No significa dibujar cada historia como una columna vertical. La guía de Humanizing Work explica la distinción y propone patrones para reducir alcance sin perder comportamiento útil.
Delimite el ejemplo de compra
Imagine una tienda que ya permite consultar productos disponibles y añadirlos al carrito. Falta el checkout. La solicitud inicial incluye varios métodos de pago, regiones de entrega, cupones, direcciones guardadas y compras como invitado. No hace falta resolverlo todo para comprobar un primer recorrido de compra.
En este lanzamiento hipotético, se atenderá a clientes ya registrados que compren productos disponibles para entrega en una región admitida. Habrá un método de pago y la entrega estándar existente. Se dejan fuera los cupones, el guardado de direcciones nuevas y la entrega internacional.
La primera historia dice: «Un cliente registrado puede comprar los productos disponibles de su carrito con el método de pago admitido y recibir una confirmación del pedido». El alcance disminuye, pero el cliente sigue completando una compra.
Compare dos formas de dividir el trabajo
| División por componente | Por qué no basta | Parte orientada al cliente |
|---|---|---|
| Crear la base de datos de pedidos. | El cliente todavía no puede realizar un pedido. | Completar una compra estándar y registrar el pedido. |
| Crear la pantalla de pago. | Sin la transacción y el pedido, la pantalla no confirma una compra. | Pagar con el primer método admitido y recibir un resultado claro de aceptación o rechazo. |
| Añadir el cálculo del descuento. | El cálculo no constituye la experiencia completa. | Aplicar una regla de descuento acordada a un checkout que ya funciona. |
| Crear una tabla de direcciones. | Almacenar no demuestra que se pueda elegir una dirección y completar la entrega. | Seleccionar una dirección guardada durante una compra que ya funciona. |
La columna derecha no promete cuatro lanzamientos separados: presenta alternativas para discutir y ordenar. Las dos primeras filas pueden formar una sola historia inicial porque comprar incluye gestionar el pago. No las separe solo para obtener más tarjetas.
Haga comprobable la primera historia
Escriba ejemplos antes de considerarla suficientemente pequeña. Una frase sobre el caso favorable puede ocultar el trabajo necesario para que la compra sea utilizable.
| Situación | Comportamiento esperado | Decisión de alcance |
|---|---|---|
| Hay productos disponibles y datos válidos del pago admitido. | Se registra el pedido, se muestra confirmación y la referencia identifica esa compra. | Incluido. |
| Se rechaza el pago. | Se indica que la compra no se ha confirmado y se permite corregir el intento. | Incluido: el error forma parte del recorrido. |
| Se repite el envío mientras el resultado anterior no está claro. | La repetición no crea por sí sola una compra duplicada. | Acordar con ingeniería el comportamiento requerido antes de aceptar la historia. |
| Un artículo deja de estar disponible al intentar comprar. | Se identifica el artículo que impide completar la compra, sin mostrar un éxito engañoso. | Incluido: comprobar disponibilidad en el momento adecuado. |
| El cliente quiere un método o una región no admitidos. | Se muestran claramente las opciones disponibles sin presentar las demás como funcionales. | Métodos y regiones adicionales quedan para después. |
Son ejemplos de comportamiento esperado, no una especificación técnica de pagos. Siguen vigentes los requisitos de seguridad, accesibilidad, privacidad y publicación del equipo. Quitar controles necesarios o tratamiento de errores no equivale a reducir el alcance de negocio.
Elija el siguiente paso según la incertidumbre
Con la compra estándar funcionando, otro método amplía quién puede pagar; un descuento cambia el cálculo y su explicación; las direcciones guardadas evitan repetir datos. Resuelven necesidades diferentes y ninguna debe ser automáticamente la siguiente.
Pregunte qué grupo está bloqueado y qué evidencia lo demuestra. Si la región admitida contiene al público piloto, la entrega internacional puede importar menos que aclarar la confirmación. Si el método de pago excluye a ese público, quizá la primera historia estuviera mal elegida.
Separe también descubrimiento y entrega. Investigar un proveedor de pago desconocido reduce incertidumbre técnica, pero no constituye una compra completada. Defina la pregunta y la evidencia esperada; empezar con «Como usuario» no convierte una investigación en valor ya entregado.
Organice la conversación en Boardmix
Coloque la solicitud completa arriba de la pizarra. Debajo, cree áreas para la primera historia utilizable, opciones posteriores y preguntas pendientes. Sitúe las tareas técnicas bajo la historia que permiten realizar, sin presentarlas como resultados independientes para el cliente.
Adjunte los ejemplos de aceptación a la primera tarjeta. Mantenga «comportamiento ante un envío duplicado» como pregunta hasta acordar el resultado esperado y conéctela con la historia afectada.
Un mapa de historias de usuario sitúa el checkout dentro del recorrido completo de compra. Esta pizarra responde a una pregunta más concreta: ¿cuál es el cambio útil más pequeño dentro de esa parte del recorrido?
Antes de trasladar la historia al sistema de entrega del equipo, lea el resultado y los ejemplos en conjunto. Si solo puede demostrar una capa técnica terminada, busque un comportamiento completo más reducido. Abra Boardmix para comparar las alternativas con el equipo.
