En estas últimas semanas he llegado a una convicción: la IA no solo nos ayuda a escribir user stories más rápido. Nos obliga a replantear por completo qué es una user story, para qué existe, quién la escribe y con qué herramientas.

Durante años en Ontruck trabajamos con una forma de colaborar que me parecía muy natural: desde producto nos enfocábamos en definir qué valor queríamos aportar y por qué tenía sentido construirlo, y era el equipo de diseño e ingeniería quien se encargaba de pensar y escribir en la user story cómo hacerlo realidad. Ahora, con herramientas como Cursor o Claude Code, ese modelo no solo tiene más sentido: se vuelve exponencialmente más productivo.

Porque ya prácticamente podemos coger una historia en Linear, conectarla directamente al código, y construir con la IA el plan técnico completo: qué módulos tocar, qué decisiones de arquitectura tomar, qué validaciones son necesarias. Y eso no se hace después de la historia: forma parte de cómo la historia se construye. El ingeniero deja de ser un ejecutor de tickets y pasa a ser un diseñador de soluciones que traduce propósito de producto en software real, asistido por IA.

Por eso creo que debemos dejar de pensar en user stories como simples tareas o “pasos previos al código”. Ese modelo está quedando obsoleto. El verdadero potencial está en que la user story se convierta en un espacio vivo de colaboración entre producto, ingeniería e IA. Un lugar donde se define el valor, se diseña el enfoque y el alcance y se inicia directamente la ejecución.

Y si eso es así, ¿por qué seguimos separando la user story del código? ¿Por qué la user story y la pull request son herramientas distintas, si están resolviendo el mismo problema? Al final, estamos hablando del mismo flujo: una necesidad de producto que se convierte en impacto tangible a través del software.

Esto no va de ahorrar tiempo escribiendo tickets con la IA. Va de replantear el objetivo del trabajo que hacemos. Menos energía en describir para otros. Más energía en entender, pensar y decidir juntos. Mejor alineamiento y más impacto.

Estamos en el inicio de una nueva forma de construir producto. ¿Vosotros también estáis cuestionando cómo escribís y usáis las user stories? ¿Cómo está cambiando vuestra forma de trabajar con la IA dentro del equipo?

·Ver comentarios en LinkedIn

También puede interesarte

40 clics para pagar dos horas de aparcamiento

Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer

La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.

Iterando el prototipo en vivo mientras los usuarios lo prueban

Siempre he hecho tests de usuario para diseñar mejor. Lo que no había vivido antes era poder implementar el feedback en la propia sesión. Lo que antes tardaba semanas, ahora sale en el día.