Ir al contenido

Scrum Planning

Vista activa de tareas y tickets agrupados por sprint.

Sprint: Actual Sprint: Futuro missing acceptance criteria

Tareas

project.task
Total
5
Sprint Actual
3
Sprint Futuro
0
Missing AC
2
Proyectos
3
Horas asignadas
15.0 h
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
Total
4
Sprint Actual
1
Sprint Futuro
0
Missing AC
3
Clientes
2
Alta prioridad
1
ID Ticket Cliente Etapa Asignado Etiqueta Prioridad Acción
#820 Agregar un concepto- Exportación de nóminas CORPSA, Yamil Araujo Velazquez En revisión por el Cliente Alejandro Ramírez Sprint: Actual Low priority Abrir
#921 Revisar cómo es que se recalculan costos MULTIACABADOS DE MEXICO, Alberto Cruz Backlog Victor Sánchez missing acceptance criteria High priority Abrir
#813 Listas de precios MULTIACABADOS DE MEXICO, Alberto Cruz Wait for Victor Sánchez missing acceptance criteria Medium priority Abrir
#872 Lista de precios descuentos MULTIACABADOS DE MEXICO, Alberto Cruz Backlog Victor Sánchez missing acceptance criteria Low priority Abrir
No hay tickets con esta etiqueta.
Guía de Criterios de Aceptación
Área de Desarrollo holosERP · Hum&Net
Pasos para sacar tu tarea de "missing acceptance criteria"
  1. Abre la tarea o ticket desde el botón "Abrir".
  2. Completa la información obligatoria del checklist de abajo (R01–R09).
  3. Agrega los escenarios DADO / CUANDO / ENTONCES.
  4. Avisa al líder técnico o PM para que revise y reasigne al sprint.
  5. 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 totales
Antes 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.