Spring GDS 25 Aniversario
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Una user story es una descripción breve de una funcionalidad contada desde la perspectiva de quien va a usarla. Responde a quién quiere algo, qué quiere y por qué. El formato habitual dice: "Como [tipo de usuario], quiero [una acción], para [un beneficio]." Esa última cláusula es la que más importa, porque obliga al equipo a nombrar el motivo detrás del trabajo en lugar de solo el mecanismo.
Las stories son deliberadamente pequeñas y deliberadamente incompletas. Son un marcador de posición para una conversación, no una especificación dictada desde arriba. El detalle se añade mediante los criterios de aceptación, las condiciones que definen cuándo la story está terminada. Una story como "Como comprador recurrente, quiero guardar mis datos de pago, para que el checkout sea más rápido la próxima vez" no te dice nada sobre la interfaz, y ese es el objetivo. Mantiene al equipo hablando del resultado antes de que nadie discuta sobre botones.
Las user stories están en el centro de cómo los equipos planifican y priorizan en la entrega ágil. Alimentan el backlog, se estiman y se convierten en las unidades de trabajo que un equipo asume en cada sprint. Las buenas stories siguen centradas en una necesidad real del usuario y no en una tarea interna, que es lo que las separa de una lista de tareas disfrazada con sintaxis de story.
Escribimos las stories con los clientes, no para ellos. Antes de un sprint, nos sentamos y convertimos intenciones vagas en stories con las personas que entienden el negocio y las que van a usar el producto. Esa conversación es donde está la mayor parte del valor. La story es solo lo que escribimos después.
Cada story que entra en un sprint lleva criterios de aceptación, para que "terminado" sea un estándar y no una opinión. Las mantenemos ancladas a una necesidad real del usuario, que es donde empieza nuestro trabajo de diseño de experiencia de usuario y donde se comprueba. Cuando el user research dice algo distinto de la suposición incrustada en una story, reescribimos la story. El backlog se mantiene honesto. El producto sigue apuntando a las personas a las que sirve.
¿Un backlog lleno de funcionalidades pero sin una idea compartida de para quién son? Vamos a arreglarlo.
Una empresa de logística que envía a 190 países construyó algo para enviarse a sí misma.
Convertir una marca en un negocio que funciona.
Medio millón de personas. Una app. Cero caos.















