Cada feedback de la app genera un ticket con número. Aquí se decide qué hacemos,
quién lo lleva, y se responde a la usuaria — la respuesta le llega dentro de su app.
Nada se guarda hasta que pulsas un botón de guardar.
Prioridad — la misma que en 🗂 Sprint Planning:
P0 la app se rompe (crash) o algo básico no funciona ·
este sprint ·
P1 funciona mal o da datos incorrectos, pero se puede seguir usando ·
siguiente versión ·
P2 molesta o confunde, no impide usar la app ·
cuando toque ·
P3 detalle menor o estético ·
si sobra tiempo.
¿cómo se rellena? ▾
Cómo se rellena una ficha (2 minutos)
1 · Título breve — cómo la llamamos entre nosotros («crash al abrir Body Insights»).
2 · Categoría — bug (algo falla) · mejora · consulta · datos.
3 · Prioridad — P0-P3 según la tabla de arriba. Si es bug, entra sola en 🗂 con esa prioridad.
4 · Responsable — quién la lleva.
5 · Acción interna — qué vamos a hacer (esto NO lo ve la usuaria).
6 · Mensaje a la usuaria — opcional; se envía cuando quieras, no cambia el estado.
El ciclo de estados
nuevo → nadie la ha mirado todavía.
en curso → alguien la lleva o está en el sprint. Ponlo tú al empezar.
esperando a la usuaria → SOLO cuando le hemos pedido algo (más datos, o confirmar que ya funciona). Hablar con ella no cambia el estado.
resuelto → arreglado y probado, fix enviado en una versión.
cerrado → terminado: técnicamente arreglado y la usuaria informada. Se cierra SOLO: 5 días en resuelto o release nueva en tiendas.
Dos cierres, no uno — el técnico (arreglado y probado → marca «fix enviado: sí») y el de la usuaria (le contamos y lo da por bueno). Cuando hay fix enviado y no contesta en 72 h, sale en ✔ para cerrar del correo diario y se cierra.
Y de aquí al desarrollo: bug → 🗂 Sprint Planning (automático, con su P) → le asignas una release → aparece en 🚢 Release Plan → se construye → vuelve aquí como «fix enviado».
📖 Guía de uso · How to use this page
📱App del pilotoLa tester usa la app y encuentra algo
Pilot app · she hits something
→
💬FeedbackLlega su mensaje (app o TestFlight) y se clasifica: 🐞 🔧 💡
Message arrives · triage
→
🎫IncidenciasAquí: analizar, priorizar P0-P3, asignar y responderle
Analyse · prioritise · reply
→
🗂Sprint PlanningEntra sola con su P · le asignas la release
Lands automatically · pick a release
→
🚢ReleaseSe construye y sale a las tiendas u OTA
Built and shipped
↩
✔Cierre«Fix enviado» → le avisamos → cerrada
Fix sent · user told · closed
Prioridad — la misma escala que en 🗂 Sprint Planning
| P0 | La app se rompe (crash) o algo básico no funciona | este sprint |
| P1 | Funciona mal o da datos incorrectos, pero se puede seguir usando | siguiente versión |
| P2 | Molesta o confunde, no impide usar la app | cuando toque |
| P3 | Detalle menor o estético | si sobra tiempo |
Cómo se rellena una ficha (2 minutos)
- Título breve — cómo la llamamos entre nosotros («crash al abrir Body Insights»).
- Categoría — bug (algo falla) · mejora · consulta · datos.
- Prioridad — P0-P3. Si es bug, entra sola en 🗂 con esa prioridad.
- Responsable — quién la lleva.
- Acción interna — qué vamos a hacer (esto NO lo ve la usuaria).
- Mensaje a la usuaria — opcional; se envía cuando quieras y no cambia el estado.
El ciclo de estados
- nuevo — nadie la ha mirado todavía.
- en curso — alguien la lleva o está en el sprint (ponlo tú al empezar).
- esperando a la usuaria — SOLO cuando le hemos pedido algo. Hablar con ella no cambia el estado.
- resuelto — arreglado y probado, enviado en una versión.
- cerrado — terminado: arreglado y la usuaria informada. Automático: a los 5 días de resuelto, o cuando una release nueva llega a las tiendas.
Dos cierres, no uno
Técnico: arreglado y probado → marca «fix enviado: sí».
Con la usuaria: le contamos y lo da por bueno. Con fix enviado y sin respuesta en 72 h, sale en
✔ para cerrar del correo diario.
Del reporte al código
bug → 🗂
Sprint Planning (automático, con su P) → le asignas una
release → 🚢
Release Plan → se construye → vuelve aquí como «fix enviado» → mensaje a la usuaria → cierre.
Priority — same scale as 🗂 Sprint Planning
| P0 | App crashes or something basic doesn't work | this sprint |
| P1 | Works badly or shows wrong data, but you can carry on | next version |
| P2 | Annoying or confusing, doesn't block usage | when it fits |
| P3 | Minor or cosmetic detail | if there's time |
Filling in a ticket (2 minutes)
- Short title — what we call it internally ("crash opening Body Insights").
- Category — bug · improvement · question · data.
- Priority — P0-P3. If it's a bug, it lands in 🗂 automatically with that priority.
- Owner — who's on it.
- Internal action — what we're going to do (the user never sees this).
- Message to the user — optional; send it whenever, it doesn't change the status.
The status cycle
- new — nobody has looked at it yet.
- in progress — someone owns it or it's in the sprint (you set this when you start).
- waiting on user — ONLY when we've asked her for something. Talking to her doesn't change the status.
- resolved — fixed and tested, shipped in a version.
- closed — done: fixed and the user informed. Automatic: 5 days after resolved, or when a new release hits the stores.
Two closures, not one
Technical: fixed and tested → mark "fix sent: yes".
With the user: we tell her and she's happy. Once a fix is sent and she doesn't reply within 72 h, it appears in
✔ ready to close in the daily email.
From report to code
bug → 🗂
Sprint Planning (automatic, with its P) → you assign a
release → 🚢
Release Plan → gets built → comes back here as "fix sent" → message to the user → closed.