Job stories: el formato de JTBD para escribir el backlog
Una job story describe situación, motivación y resultado de una persona. Cómo escribirla, en qué se diferencia de una historia de usuario y cuándo usarla.
¿Qué es una job story?
Es una historia de producto que nace del marco de Jobs to be Done. Tiene tres partes:
- Situación: el disparador, el momento o contexto en el que aparece la necesidad.
- Motivación: lo que la persona quiere conseguir.
- Resultado: el progreso que busca, no la funcionalidad que usará.
El formato viene de Intercom. Su equipo de producto lo creó hacia 2013 para entender las motivaciones detrás de lo que hace la gente, sin apoyarse en personas ni roles. Paul Adams lo contó en 2016 y explicó que el nombre lo puso Alan Klement más tarde (Intercom, “How we accidentally invented Job Stories”).
¿En qué se diferencia de una historia de usuario?
La diferencia es el punto de partida. Una historia de usuario empieza por quién actúa. Una job story empieza por cuándo ocurre.
| Elemento | Historia de usuario | Job story |
|---|---|---|
| Punto de partida | «Como [rol]…» | «Cuando [situación]…» |
| Foco | Una funcionalidad | El trabajo que la persona quiere hacer |
| Origen típico | Lista de requisitos | Observación de situaciones reales |
| Pregunta que responde | ¿Qué debe hacer el sistema? | ¿Por qué y cuándo lo necesita alguien? |
Mountain Goat Software lo resume así: la historia de usuario depende de quién hace la función, mientras que la job story se centra en el trabajo que debe cumplir. Su ejemplo compara «Cuando se envía un pedido…» con «Como cliente…». La primera versión vale para cualquiera que compre y dice cuándo aparece el aviso; la segunda no precisa el momento, y el equipo podría cumplirla con una entrada de preguntas frecuentes (Mountain Goat Software).
¿Por qué le importa a un diseñador?
Porque la situación te obliga a diseñar para un momento concreto. Una misma funcionalidad puede responder a varias situaciones, y cada una pide una solución distinta. La guía de JTBDUX Protocol insiste en que la situación es la parte más importante del formato, y recomienda escribir una por historia para no mezclar escenarios (JTBDUX Protocol, “The Job Story”).
Esto te sirve para tres cosas:
- Detectar que dos historias de usuario distintas son en realidad la misma situación.
- Ver qué pasa antes y después de la pantalla que estás diseñando.
- Discutir con producto el problema antes de discutir el botón.
Además, la job story deja fuera a propósito la solución. Eso te da libertad para proponer dos o tres caminos distintos y comparar cuál resuelve mejor la situación, en lugar de llegar con una pantalla ya decidida.
¿Cómo se escribe una buena job story?
- Observa una situación real. Una entrevista o una sesión de observación te da el disparador. Si la situación sale de tu imaginación, la historia será genérica.
- Escribe la situación con detalle. «Cuando estoy en el móvil y tengo que pagar una factura» dice más que «Cuando el usuario quiere pagar».
- Describe la motivación como un motivo. Tiene que ser algo que la persona quiere, no una funcionalidad. «Quiero confirmar que el pago salió» es una motivación; «quiero ver un botón de confirmar» no lo es.
- Define un resultado con progreso. «Para poder seguir con mi día sin preocuparme» describe progreso. «Para poder pagar» repite la función.
- Divide las historias grandes. Si una situación cubre varios escenarios, sepáralas.
Ejemplo
Ejemplo ilustrativo: un equipo de una app bancaria tiene en el backlog la historia «Como usuario, quiero ver mis movimientos». Al reescribirla como job story, queda: «Cuando recibo un cargo que no reconozco en el móvil, quiero entender de dónde viene, para poder decidir si lo reclamo antes de que se cobre otro igual». Con esa frase el equipo ya no discute una lista de movimientos. Discute cómo mostrar el cargo, qué datos son suficientes y qué acción debe aparecer al lado.
¿Cuándo NO conviene usarlas?
- Cuando el equipo solo necesita una tarea técnica. Un refactor o una migración no tiene situación de usuario que describir.
- Cuando importa quién actúa. Si los usuarios son muy distintos entre sí, entender quién es cada uno sigue siendo necesario. Las job stories encajan mejor en productos cuyos usuarios tienen necesidades parecidas.
- Cuando tu equipo ya trabaja con historias de usuario. No hace falta cambiar todo. Mountain Goat Software sugiere mezclar ambos formatos en el mismo backlog y escribir una job story cuando te descubras redactando varias historias seguidas que empiezan con «Como usuario».
- Cuando la situación no está validada. Una job story escrita sin investigación se parece a una historia de usuario con mejor redacción.
Errores comunes
- Escribir la motivación como funcionalidad: «quiero un filtro por fecha».
- Usar el resultado para repetir la acción: «para poder buscar».
- Escribir situaciones genéricas como «cuando uso la app».
- Tener una historia que mezcla dos situaciones distintas.
- Usar el formato como sustituto de entrevistas de usuario.
Cómo empezar mañana
Abre tu backlog y elige tres historias de usuario que tengan la palabra «usuario» y un verbo genérico. Para cada una, pregúntate: ¿cuándo pasa esto?, ¿qué estaba haciendo la persona antes?, ¿qué quería lograr? Reescríbelas con la plantilla. Si no puedes contestar alguna de esas preguntas, tienes un hueco de investigación y no de diseño. Si quieres ver cómo se relaciona con otros artefactos, mira los casos de uso y los flujos de usuario que ya existen en la wiki.