«Ser más productivo en Linear» rara vez significa «teclear más rápido».
Normalmente significa:
- menos rondas de aclaraciones,
- menos reuniones,
- menos tickets a medio terminar,
- y más issues que se pueden ejecutar de principio a fin.
Es un flujo de trabajo que sobrevive a un proceso desordenado, porque solo te pide cambiar cómo se escribe un único artefacto.
TL;DR
- La productividad en Linear es claridad, no teatro de velocidad.
- La mayor palanca está en escribir issues que reduzcan el seguimiento: contexto → alcance → criterios de aceptación.
- El método propio de Linear apuesta por issues en lugar de historias de usuario y por la planificación continua; esas ideas encajan bien en equipos reales si lo mantienes ligero.
- Si escribir es el cuello de botella, no «trabajes más horas». Reduce la fricción: redacta el texto rápido y luego edítalo con precisión.
1) Haz que cada issue responda 3 preguntas (contexto, alcance, hecho)
Si alguien lee tu issue y aun así pregunta «¿qué es esto?» o «¿cuándo está listo?», no escribiste un issue. Escribiste una invitación a una reunión.
Usa esta estructura:
Contexto (por qué)
Un párrafo corto:
- ¿qué problema estamos resolviendo?
- ¿a quién afecta?
- ¿cuál es la evidencia (enlaces, capturas de pantalla, métricas)?
Alcance (qué)
Viñetas:
- dentro del alcance
- fuera del alcance
Hecho (cómo lo sabemos)
Una lista de comprobación con los criterios de aceptación.
La propia guía de Linear se inclina por escribir issues accionables en lugar de artefactos con forma de historia: “Write issues not user stories” (Linear Method).
2) Usa criterios de aceptación para reducir el ir y venir
Los criterios de aceptación no son «papeleo extra» si evitan dos días de ambigüedad.
Mantenlos ligeros:
- comportamiento visible para el usuario
- casos límite (2 o 3 viñetas)
- restricciones de rendimiento (si son relevantes)
La explicación de Atlassian es una buena referencia básica sobre qué son los criterios de aceptación y por qué importan (aunque no uses Jira): Atlassian: Acceptance criteria.
3) Escribe tickets «ejecutables de forma asíncrona»
Aquí tienes una prueba rápida:
¿Podría un compañero, en otra zona horaria, retomar esto mañana y entregarlo sin llamarte?
Si no, añade:
- enlaces a diseños/registros
- esperado frente a real (en el caso de errores)
- una lista corta de «no objetivos»
4) Usa Linear como un editor, no como un formulario
El editor de Linear está pensado para escribir en lugar de rellenar formularios, y por eso aplicar la estructura anterior sale barato. Dos referencias:
Si quieres moverte más rápido dentro de la app, también vale la pena aprender (o al menos hojear) la ayuda de atajos:
El objetivo no es memorizar todos los atajos. Es eliminar las pequeñas interacciones de interfaz que repites toda la semana.
5) Usa una plantilla reutilizable
Copia y pega esta plantilla en tus issues:
Plantilla: función / mejora
- Contexto: …
- Objetivo: …
- No objetivos: …
- Enfoque (opcional): …
- Criterios de aceptación:
- [ ] …
- [ ] …
- [ ] …
- Enlaces: diseños, documentos, PR
Plantilla: error
- Resumen: …
- Pasos para reproducir:
- …
- …
- Esperado frente a real: …
- Impacto / gravedad: …
- Criterios de aceptación:
- [ ] prueba de regresión añadida
- [ ] corrección verificada en …
- Enlaces: registros, capturas de pantalla
6) Si escribir es tu cuello de botella, redacta rápido y luego edita
Escribir el issue lleva tanto tiempo que la gente lo recorta, y el issue recortado es el que luego cuesta una reunión.
Una solución práctica:
- Redacta rápido (no te autocorrijas a mitad de frase)
- Luego edita el 10 % que importa (nombres, ID, enlaces, formato)
Una forma de reducir la fricción en macOS es usar voz a texto para el primer borrador (sobre todo para el contexto y los criterios de aceptación) y el teclado para las ediciones precisas.
Si quieres la configuración exacta en Linear: /how-to/linear-mac-dictation
7) El «vibe coding» hace los tickets más importantes, no menos
Si tu equipo usa editores con IA como base o flujos de «vibe coding», el cuello de botella se desplaza:
- menos tiempo escribiendo código desde cero
- más tiempo especificando qué debe pasar
- más necesidad de una lista de revisión
Eso hace que los issues claros y los criterios de aceptación valgan aún más.
Guía: /blog/vibe-coding
Sigue leyendo
- Configuración de Linear (Mac): /how-to/linear-mac-dictation
- GitHub Issues (Mac): /how-to/github-issues-mac-dictation
- Jira (Mac): /how-to/jira-mac-dictation
- Trabajo remoto: /solutions/remote-work
Fuentes
- Linear Method: Write issues not user stories
- Linear Docs: Create issues
- Linear Docs: Editor
- Linear: Keyboard shortcuts help
- Resumen de criterios de aceptación: Atlassian
- Charla sobre producto y proceso: Karri Saarinen (CEO of Linear) on product management practices (YouTube)