3 Story Mapping y Backlog - Davidcuama/via-coinogas GitHub Wiki
Sección 3 · Story Mapping y Backlog del Producto
3.1 Story Mapping
El mapa organiza el trabajo en dos dimensiones. En horizontal, la columna vertebral del proceso: la secuencia de actividades que un usuario recorre de principio a fin. En vertical, la prioridad de entrega.
La primera banda es el esqueleto ambulante: la ruta más corta que ya entrega valor, y que corresponde al alcance comprometido para el Sprint 1.
Se presenta en dos partes por legibilidad.
Parte 1 — Flujo del solicitante
Parte 2 — Flujo del área de compras
Tabla equivalente
| Actividad del usuario | Sprint 1 (comprometido) | Sprint 2 (siguiente) | Posterior (backlog) |
|---|---|---|---|
| Iniciar el requerimiento | HU-01, HU-02, HU-03 | — | HU-18 |
| Detallar lo que se necesita | HU-06, HU-07 | HU-08 | HU-10 |
| Especificar y evidenciar | — | HU-09, HU-11 | HU-12, HU-14 |
| Sugerir proveedores | — | HU-13 | — |
| Planear la recepción | HU-04, HU-05 | — | — |
| Enviar y validar | HU-15, HU-16, HU-17 | HU-19 | — |
| Recibir y gestionar | — | HU-20, HU-21, HU-22 | HU-23, HU-24 |
| Analizar y decidir | HU-29, HU-30 | HU-31, HU-32 | HU-33 |
| Consultar y reportar | — | HU-25 | HU-26, HU-28 |
| Administrar | — | HU-27 | — |
Los huecos en la banda del Sprint 1 son intencionales. Se prioriza que el flujo llegue completo de punta a punta antes que llenar cada actividad.
3.2 Backlog del Producto
33 historias de usuario agrupadas en 7 épicas, con una estimación acumulada de 119 story points.
El backlog vive en las Issues de este repositorio, etiquetadas por épica, prioridad y estimación, y organizadas en milestones por sprint.
- Backlog completo: Issues del repositorio
- Tablero: pegar aquí el enlace al proyecto de GitHub Projects
Épicas
| Épica | Historias | Puntos |
|---|---|---|
| 1 · Radicación del requerimiento | HU-01 a HU-05 | 12 |
| 2 · Detalle de ítems y especificaciones | HU-06 a HU-10 | 18 |
| 3 · Evidencias y proveedores sugeridos | HU-11 a HU-14 | 13 |
| 4 · Validación, envío y trazabilidad | HU-15 a HU-19 | 18 |
| 5 · Gestión del área de compras | HU-20 a HU-24 | 21 |
| 6 · Consulta, reportes y administración | HU-25 a HU-28 | 16 |
| 7 · Analítica e indicadores | HU-29 a HU-33 | 21 |
Listado de historias
| ID | Historia de usuario | Prior. | Est. |
|---|---|---|---|
| HU-01 | Como solicitante quiero abrir un formulario de requerimiento completamente en blanco para no arrastrar información de solicitudes anteriores. | Alta | 3 |
| HU-02 | Como solicitante quiero registrar mi nombre, mi área o proyecto y el centro de costo para que compras sepa de dónde viene la solicitud y a qué se imputa el gasto. | Alta | 3 |
| HU-03 | Como solicitante quiero redactar la justificación del requerimiento para explicar por qué la compra es necesaria. | Alta | 2 |
| HU-04 | Como solicitante quiero seleccionar la prioridad de la compra para que compras sepa cuáles atender primero. | Alta | 2 |
| HU-05 | Como solicitante quiero indicar la fecha en que necesito recibir la compra para que se planee la entrega a tiempo. | Alta | 2 |
| HU-06 | Como solicitante quiero agregar y eliminar varios ítems dentro de un mismo requerimiento para no tener que radicar una solicitud por cada artículo. | Alta | 5 |
| HU-07 | Como solicitante quiero registrar la cantidad y la descripción de cada ítem para que compras sepa exactamente qué y cuánto se necesita. | Alta | 3 |
| HU-08 | Como solicitante quiero marcar si un ítem requiere calibración y si es reembolsable para que compras aplique el tratamiento correspondiente. | Alta | 2 |
| HU-09 | Como solicitante quiero registrar las especificaciones técnicas de cada ítem para que no haya ambigüedad sobre el artículo solicitado. | Alta | 5 |
| HU-10 | Como solicitante quiero que el sistema calcule el total del ítem y del requerimiento a partir del precio de referencia para no hacer cuentas a mano. | Media | 3 |
| HU-11 | Como solicitante quiero adjuntar fotografías del artículo para evitar confusiones sobre lo que estoy pidiendo. | Alta | 5 |
| HU-12 | Como solicitante quiero tomar la fotografía directamente con la cámara de mi celular para no depender de un computador cuando estoy en campo. | Media | 3 |
| HU-13 | Como solicitante quiero sugerir hasta tres proveedores con su teléfono para agilizar la búsqueda de cotizaciones. | Alta | 3 |
| HU-14 | Como solicitante quiero indicar si existen productos sustitutos para dar alternativas al área de compras. | Media | 2 |
| HU-15 | Como solicitante quiero que el sistema me impida enviar el formulario incompleto y me diga qué falta, para no retrasar el proceso de cotización. | Alta | 5 |
| HU-16 | Como solicitante quiero recibir un número consecutivo al radicar para poder referirme a mi solicitud sin ambigüedad. | Alta | 3 |
| HU-17 | Como solicitante quiero ver una confirmación en pantalla al enviar para saber con certeza que la solicitud quedó registrada. | Alta | 2 |
| HU-18 | Como solicitante quiero guardar un borrador y retomarlo después para no perder lo diligenciado si me interrumpen. | Baja | 5 |
| HU-19 | Como analista de compras quiero recibir un correo cuando se radique un requerimiento para enterarme sin tener que revisar el sistema constantemente. | Media | 3 |
| HU-20 | Como analista de compras quiero ver todos los requerimientos radicados en una sola bandeja para dejar de rastrearlos en el correo. | Alta | 5 |
| HU-21 | Como analista de compras quiero filtrar y ordenar la bandeja por área, prioridad, estado y fecha para decidir qué atender primero. | Alta | 5 |
| HU-22 | Como analista de compras quiero abrir la ficha completa de un requerimiento con sus fotografías para evaluarlo sin pedir información adicional. | Alta | 3 |
| HU-23 | Como analista de compras quiero cambiar el estado de un requerimiento para que el solicitante y yo sepamos en qué punto va. | Media | 3 |
| HU-24 | Como analista de compras quiero devolver un requerimiento con observaciones para que el solicitante corrija lo que falta sin recurrir al correo. | Media | 5 |
| HU-25 | Como solicitante quiero consultar el listado de mis requerimientos y su estado para hacer seguimiento sin llamar a compras. | Media | 3 |
| HU-26 | Como analista de compras quiero exportar los requerimientos a Excel para alimentar los informes del área sin transcribir a mano. | Media | 5 |
| HU-27 | Como administrador quiero parametrizar las áreas, los centros de costo y las prioridades para que el formulario refleje la estructura real de la empresa. | Media | 3 |
| HU-28 | Como administrador quiero consultar la bitácora de cambios de un requerimiento para saber quién modificó qué y cuándo. | Baja | 5 |
| HU-29 | Como analista de compras quiero disponer de vistas de datos ya organizadas para conectar Power BI sin depender del equipo de desarrollo cada vez que cambie un reporte. | Alta | 5 |
| HU-30 | Como analista de compras quiero un tablero con el volumen de requerimientos por periodo, área y prioridad para entender la carga de trabajo del área. | Alta | 5 |
| HU-31 | Como jefe del área quiero ver el tiempo promedio entre la radicación y el cierre de un requerimiento para identificar dónde se están demorando los procesos. | Media | 5 |
| HU-32 | Como jefe del área quiero ver la tasa de requerimientos devueltos por información incompleta para medir si la digitalización redujo los errores de diligenciamiento. | Media | 3 |
| HU-33 | Como analista de compras quiero que el tablero se actualice solo todos los días para no tener que refrescarlo a mano. | Baja | 3 |
3.3 Sprint 1 Planning
Duración: 3 semanas Capacidad comprometida: 40 story points Historias: HU-01, HU-02, HU-03, HU-04, HU-05, HU-06, HU-07, HU-15, HU-16, HU-17, HU-29, HU-30
Objetivo del Sprint 1 Entregar el formulario digital de radicación con validación de campos obligatorios, soporte para múltiples ítems y persistencia en base de datos —sustituyendo el diligenciamiento del archivo Excel para el flujo básico del solicitante— y exponer sobre esa información las vistas de solo lectura y el tablero inicial de indicadores en Power BI.
El orden no es arbitrario. Un tablero de indicadores no puede construirse antes de que existan datos reales que mostrar, de modo que la analítica depende de que el flujo de radicación funcione primero. Por eso las historias del tablero se ubican al final del sprint y se designan como el margen de maniobra del alcance: si el desarrollo del formulario consume más tiempo del previsto, HU-30 se traslada al Sprint 2 sin poner en riesgo el objetivo principal.
Reparto por integrante
| Integrante | Historias asignadas | Carga |
|---|---|---|
| Juan Esteban Villada | HU-01, HU-06, HU-15 | 13 |
| Juan Camilo Gómez | HU-02, HU-07, HU-29 | 11 |
| Juan Pablo Posso | HU-03, HU-04, HU-05, HU-16, HU-17 | 11 |
| David Cuadros | HU-30, más la interlocución con el cliente y la documentación del sprint | 5 |
El Product Owner asume menos puntos de desarrollo porque concentra la interlocución con el cliente, la documentación del entregable y la validación del tablero.
Detalle de las historias
El detalle completo de cada historia —tareas, criterios de aceptación, estimación y responsable— está en la issue correspondiente del repositorio. Filtrar por el milestone «Sprint 1 - Radicación y analítica base».