Convertir requisitos en historias para Jira

1. Define la entrega

Para quién: Consultores de operaciones y responsables de producto que necesitan convertir un documento en trabajo revisable con el equipo.

Tarea: Proponer historias para un portal interno, contrastarlas con un inventario aportado y dejar las decisiones pendientes visibles.

Consulta la ficha, el acceso y los requisitos del recurso antes de elegir el entorno. El archivo gratuito no incluye un motor de IA; el servicio elegido puede tener cuotas o coste.

2. Prepara la entrada ficticia

CASO FICTICIO — sin conexión a Jira.
R1: una persona solicitante puede guardar un borrador con título y descripción.
R2: antes de enviar, título y descripción son obligatorios.
R3: la persona solicitante puede consultar el estado de lo enviado.
Inventario ficticio: J-7 «Guardar borrador», incluye título y descripción opcionales. No se aporta detalle del resto del proyecto.
Fuera de alcance: asignación automática y notificaciones. Proyecto, estimaciones y responsables por decidir.

En un caso real, utiliza solo materiales que puedas compartir con el asistente elegido y retira datos confidenciales o personales innecesarios.

3. Prepara el Markdown y el entorno

1. Desde la ficha descarga el paquete y abre source/agents/atlassian-requirements-to-jira.agent.md. Conserva la licencia y revisa el alcance de lectura y escritura.
2. Para el flujo conectado se necesita un anfitrión que interprete el perfil, una conexión Atlassian MCP autenticada, el proyecto elegido y permisos adecuados. Los nombres de herramientas y campos deben contrastarse con la integración real.
3. Para practicar sin conexión, usa únicamente la entrada y la solicitud siguientes en un asistente de texto. Es un ejercicio editorial, no ejecución del agente conectado. El original limita documentos a menos de 1 MB y pide vista previa y aprobación antes de escribir.

4. Pide un borrador en español

Prepara en español una propuesta de backlog a partir del caso ficticio, sin conectarte a Jira. Vincula cada historia a R1, R2 o R3, identifica rol, valor y criterios observables. Contrasta R1 con el inventario J-7 aportado y señala posibles solapamientos, sin porcentajes de similitud ni afirmar una búsqueda completa. Conserva estimaciones, proyecto y responsables por decidir. No añadas notificaciones ni asignación automática. Presenta una vista previa para revisión; no crees ni actualices elementos.

El botón copia la solicitud y la entrada completa del paso 2. Conserva la respuesta íntegra si haces un intento propio.

5. Revisa antes de usar el resultado

• R1 se solapa con J-7: propone revisarlo antes de crear otra historia. El inventario parcial no demuestra ausencia de otros duplicados.
• R2 exige ambos campos al enviar; no al guardar. Conserva esta diferencia y comprueba los casos de falta de título y falta de descripción.
• R3 permite consultar el estado; no implica notificaciones ni asignación automática.
• Cada historia debe citar su requisito. Los campos, enlaces de épica y estimaciones se validan con el equipo y el esquema real antes de aprobar una escritura.

Si falla un criterio, conserva la diferencia y corrige el borrador. Si falta evidencia, déjala pendiente; superar este ejercicio no demuestra eficacia general.

Límites y procedencia

El Markdown describe límites de lote, detección de duplicados y protecciones de consultas; no los implementa como controles técnicos. Esta guía no conecta con Atlassian, no comprueba permisos ni crea tickets. El entorno, el modelo y Jira pueden tener cuotas o costes propios.

Fuente: Atlassian Requirements to Jira, de github / awesome-copilot. Revisión consultada: d85f762d6e521abf5fe16703946e9b38adc42da7. Licencia original: MIT.

Las funciones y requisitos descritos proceden de ese original; el caso, la solicitud y los criterios son aportación editorial de peopleofthe.ai. Consulta la metodología y la distinción entre documentación, ejemplo y ensayo.

Volver a la ficha del recurso · Elegir otro recorrido para consultorías