Scrum Planning
Vista activa de tareas y tickets agrupados por sprint.
Sprint: Actual
Sprint: Futuro
missing acceptance criteria
Política de trabajo:
el equipo de Desarrollo solo trabaja tareas y tickets que estén en
Sprint: Actual o
Sprint: Futuro y que
no tengan
missing acceptance criteria.
Tareas
project.task| ID | Tarea | Proyecto | Etapa | Asignados | Etiqueta | Horas | Fecha límite | Acción |
|---|---|---|---|---|---|---|---|---|
| #1536 | Mejoras en acción planificada de integración aremipa con amorus | AMORUS | Entregada | Christian Muro | Sprint: Actual | 3.00 | 2026-05-26 23:00:00 | Abrir |
| #1124 | ** Validador de RFC-UUID-XML en Audit (Evitar duplicados Audit) | Osel (Fase 1) | Nueva | Christian Muro | Sprint: Actual | 5.00 | 2026-02-26 03:00:00 | Abrir |
| #1537 | S06044 -Errores en nuestros inventarios | PLATA Y ORO CITLALI | Lista Para Entregar | Saul Castellanos | Sprint: Actual | 3.00 | — | Abrir |
| #1128 | ** Revisión del total de la orden de compra que no cuadra con el total la entrada de almacén (custom) | Osel (Fase 1) | Backlog | David Flores | missing acceptance criteria | 4.00 | 2026-03-06 19:00:00 | Abrir |
| #1253 | ** modificacion Wizard configuracion de entintados | Osel (Fase 1) | Backlog | David Flores | missing acceptance criteria | 0.00 | — | Abrir |
| No hay tareas con esta etiqueta. | ||||||||
Tickets
helpdesk.ticket| ID | Ticket | Cliente | Etapa | Asignado | Etiqueta | Prioridad | Acción |
|---|---|---|---|---|---|---|---|
| No hay tickets activos con las etiquetas configuradas. | |||||||
| No hay tickets con esta etiqueta. | |||||||
Guía de Criterios de Aceptación
Área de Desarrollo holosERP · Hum&Net
¿Por qué mi tarea/ticket tiene esta etiqueta?
Porque le falta información mínima para ser desarrollada. El equipo de Desarrollo no la tomará hasta que se complete. El objetivo es evitar retrabajo, devoluciones del cliente y trabajo fuera de alcance.
Pasos para sacar tu tarea de "missing acceptance criteria"
- Abre la tarea o ticket desde el botón "Abrir".
- Completa la información obligatoria del checklist de abajo (R01–R09).
- Agrega los escenarios DADO / CUANDO / ENTONCES.
- Avisa al líder técnico o PM para que revise y reasigne al sprint.
- Quita la etiqueta missing acceptance criteria y agrega Sprint: Actual o Sprint: Futuro.
Checklist obligatorio (Definition of Ready)
Redacta desde la perspectiva del usuario, indicando QUÉ necesita y POR QUÉ.
Como gerente de almacén, necesito un reporte de caducidades por lote para evitar mermas.
Indica la versión donde aplica el desarrollo. Ej:
holosERP 18.0.
Describe cómo funciona el proceso hoy. Incluye screenshots, diagrama BPMN
o descripción paso a paso.
Describe cómo debe funcionar después del desarrollo. Incluye mockups,
wireframes o descripción detallada del comportamiento.
Lista todas las condiciones, validaciones, restricciones y cálculos.
"El descuento máximo sin autorización es 15%. Si supera, pasa a Pendiente de aprobación."
Proporciona datos representativos para validar el desarrollo. Ej: CSV con
50 productos, 10 órdenes de venta con distintos escenarios.
Lista verificable de condiciones. Usa la plantilla
DADO / CUANDO / ENTONCES que se muestra más abajo.
Prioridad acordada (Crítica / Alta / Media / Baja) y fecha esperada de entrega.
Persona del lado del cliente o área de negocio que puede resolver dudas
durante el desarrollo. Incluye nombre, rol y horario disponible.
Plantilla DADO / CUANDO / ENTONCES
### Escenario: [Nombre del flujo]
DADO [contexto / precondición]
CUANDO [acción del usuario]
ENTONCES [resultado esperado observable]Ejemplo real:
### Escenario: Consulta estándar con filtro de fecha
DADO que el usuario tiene rol 'Contador' y existen facturas vencidas
CUANDO selecciona fecha de corte y presiona 'Generar Reporte'
ENTONCES muestra antigüedad en buckets: Corriente, 1-30, 31-60, 61-90, +90 días con totalesAntes de escalar un ticket de soporte
Responde tres preguntas antes de etiquetar un ticket como Sprint: Actual:
✓ Bug — La funcionalidad existe pero no funciona como debería.
→ Procede a desarrollo, documenta pasos para reproducir.
⚠ Solicitud de cambio — La funcionalidad existe, pero piden ampliarla o modificarla.
→ Requiere DoR completo. NO es soporte: es nuevo desarrollo.
✗ Upselling / Fuera de alcance — La funcionalidad nunca existió o está fuera del contrato.
→ Escala a Ventas/Implementación. NO va a Desarrollo.
Definition of Done (DoD)
- D01 — Todos los criterios de aceptación verificados, con evidencia (screenshot, video o log).
- D02 — Documentación funcional para el usuario final (README o documento separado).
Recuerda: documentar bien al inicio ahorra semanas de fricción al final.
Si tienes dudas, contacta al líder técnico del área antes de cambiar la etiqueta.