---
title: "Validar un epic de Jira con usuarios sintéticos | Minds"
description: "Importa un epic de Jira a Minds, ponlo frente a una audiencia sintética y detecta requisitos malinterpretados o pruebas faltantes antes de iniciar el sprint."
canonical_url: "https://getminds.ai/use-cases/es/validate-a-jira-epic-with-synthetic-users"
last_updated: "2026-10-01T08:08:36.927Z"
---

# Validar un epic de Jira con usuarios sintéticos

Un epic es una apuesta redactada en el propio lenguaje del equipo. Pasa el refinamiento porque todos en la sala comparten el contexto que le da sentido, que es exactamente el contexto que el cliente no tiene. El requisito que parecía evidente un martes se convierte en el ticket de soporte la semana del lanzamiento.

Minds importa el epic directamente desde Jira y lo presenta ante una audiencia sintética creada a partir del segmento al que realmente te diriges. Así detectas la frase malinterpretada mientras todavía es solo una frase.

## Cuándo conviene hacerlo

Ponlo en marcha cuando el epic comprometa tiempo real de ingeniería y el equipo se base en suposiciones en lugar de evidencias:

- el epic introduce un concepto nuevo que el usuario debe aprender
- los criterios de aceptación describen comportamientos sobre los que nadie fuera del equipo ha opinado
- dos partes interesadas discrepan sobre lo que quiere el usuario y ninguna tiene datos
- la funcionalidad tiene implicaciones de precios, permisos o privacidad
- estás a punto de redactar los textos que formarán parte de la funcionalidad

No vale la pena hacerlo para un refactor, una actualización de dependencias o un epic cuyo resultado sea invisible para quien usa el producto.

## Qué importar

Usa el botón de Jira en el editor de Minds. Puedes elegir un issue reciente en el selector o pegar el enlace del issue: tanto las URL del tipo `browse/ABC-123` como los enlaces de tableros con un issue seleccionado se resuelven en la misma importación.

Minds transforma el issue en un documento legible: el resumen como título, seguido del proyecto, tipo, estado, prioridad, persona asignada, etiquetas y epic superior como contexto; luego la descripción completa conservando encabezados, listas, tablas y paneles; y finalmente el hilo de comentarios. La discusión en los comentarios suele ser donde reside el requisito real, por lo que se transfiere el hilo completo y no solo la descripción.

## El flujo de trabajo

1. Conecta Jira en Configuración → Integraciones. Aprueba la pantalla de consentimiento de Atlassian para tu sitio.
2. Importa el epic a un nuevo estudio.
3. Define la audiencia a la que va dirigido este epic: no "usuarios" en general, sino el rol, contexto y limitaciones que hacen relevante este comportamiento.
4. Pide a la audiencia que te explique la funcionalidad con sus propias palabras antes de preguntarles si les gusta.
5. Pregunta qué esperarían que ocurra a continuación y qué les haría abandonar el proceso.
6. Reescribe los criterios de aceptación en función de las respuestas y toma nota de qué discrepancias justifican una sesión con usuarios reales.

El cuarto paso hace la mayor parte del trabajo. Una audiencia sintética que no puede reformular la funcionalidad te está indicando que la descripción es ambigua, y esa ambigüedad está a punto de convertirse en código.

## Cómo es un buen resultado

Debes buscar tres aspectos, en este orden:

**Una mala interpretación.** Alguien describe que la funcionalidad hace algo que en realidad no hace. Eso es un problema de redacción en el epic y corregirlo ahora no cuesta nada.

**Una objeción no prevista.** Un motivo para dudar que nunca surgió en el refinamiento: una preocupación sobre privacidad, un coste asumido o el temor a perder datos existentes.

**Una suposición silenciosa.** La audiencia espera un paso que el epic nunca menciona, lo que significa que a los criterios de aceptación les falta algo.

Una puntuación direccional es el resultado menos interesante aquí. Un "siete de diez" no aporta nada que puedas incluir en un ticket; que "tres de ellos creyeron que esto borraría su informe actual" te dice con exactitud qué debes modificar.

## Ejemplo de prompt

Lee este epic como la persona para la que fue redactado. Con tus propias palabras, ¿qué te permite hacer esta funcionalidad? ¿Qué esperas que ocurra después de usarla, qué te haría dudar y qué te falta para poder confiar en ella?

## Dónde encaja esto

Esta es la capa rápida previa a la investigación real, no un sustituto de ella. Utilízala para llegar a una versión más depurada y a una lista más corta de preguntas abiertas, y luego dedica las sesiones en vivo y los experimentos medidos a las dudas que sigan en pie.

La misma importación funciona para historias y bugs, y el [conector de Linear](/guide/integrations) funciona de manera idéntica si tu equipo gestiona el trabajo allí. Si tus requisitos están en un documento en lugar de un ticket, el [flujo de validación de PRD](/blog/prd-validation-ai-personas-before-engineering) general cubre el mismo proceso desde la perspectiva del documento.