Ir al contenido

Propiedades de la tarea

Una tarea necesita un título. Todo lo demás en esta página es opcional, y los equipos que acaban contentos son los que añaden una propiedad cuando responde a una pregunta que alguien hace de verdad.

Propiedad Responde
Estado ¿Dónde está en el flujo?
Responsable ¿Quién lo está haciendo?
Prioridad ¿Qué cojo primero?
Tipo ¿Qué clase de trabajo es?
Etiquetas ¿Cómo vuelvo a encontrar esto?
Estimación ¿Cómo de grande es?
Fecha límite ¿Para cuándo hace falta?
Sprint ¿Qué bloque de tiempo?
Módulo ¿Qué parte del producto?

Todas se pueden fijar sin abrir la tarea. Pon el cursor sobre una tarjeta o una fila y pulsa la letra — S estado, A responsable, P prioridad, L etiquetas, T tipo, E estimación, C sprint, M módulo.

Cinco valores: Ninguna, Urgente, Alta, Media, Baja.

La lista es corta a propósito. Una escala de prioridad con nueve niveles se convierte en una de dos, porque nadie distingue el 6 del 7. Ordena una vista por prioridad y la parte de arriba es la respuesta a “¿y ahora qué?”.

Qué clase de trabajo es la tarea — Error, Funcionalidad, Mantenimiento, lo que diga tu equipo. Los tipos se definen por proyecto, así que un proyecto de soporte y uno de producto no tienen que compartir vocabulario.

Los tipos son cómo divides un tablero sin dividir un proyecto: filtra por Error y el mismo tablero se convierte en un gestor de errores.

Marcadores libres. necesita-spec, diseño, viene-del-cliente.

Las etiquetas son la única propiedad que controla tu equipo en vez de tu admin:

  • Escribe un nombre que aún no existe y el selector ofrece crearlo, con color al momento.
  • ¿Te equivocaste de color? Pasa el cursor por la etiqueta, pulsa el lápiz, renómbrala y recolóreala ahí mismo. Sin página de ajustes, sin salir de la tarea.
  • Los invitados pueden aplicar tus etiquetas, pero nunca inventarlas ni reescribirlas.
  • Solo un admin puede borrar una etiqueta, porque borrarla la quita de todas las tareas a la vez.

Usa etiquetas para cosas que cruzan a través de estados y proyectos. Si el marcador es en realidad una etapa del trabajo, quiere ser un estado. Si es en realidad una línea de trabajo, quiere ser un módulo.

Cada proyecto elige una escala de estimación, y todas sus tareas usan esa escala.

Escala Se ve así Buena para
Puntos 1, 2, 3, 5, 8 Equipos que ya hacen story points.
Camiseta XS, S, M, L, XL Equipos que quieren tamaño sin cuentas.
Tiempo 2w, 3d, 4h, 30m Equipos que facturan o planifican en horas.

En la escala de tiempo escribes como hablas. 2w son dos semanas, 4h 30m son cuatro horas y media. No hay desplegable de unidades.

Las estimaciones alimentan el burn-up del sprint y se sitúan junto al tiempo registrado en la tarea, así que “pensábamos cuatro horas, fueron once” es un hecho que ves en vez de una sensación que tienes. Mira Controla el tiempo.

Una tarea puede llevar una fecha de inicio y una fecha límite. Ambas son opcionales; una tarea sin ninguna de las dos simplemente no aparece como barra en la línea de tiempo.

Las fechas son lo que dibuja la línea de tiempo, lo que empujan las flechas de dependencia, y lo que se convierte en “quedan 6sem” o un “12d tarde” en rojo en la tarjeta del proyecto.

Cuando las propiedades integradas se quedan cortas, define las tuyas. Siete tipos:

Tipo Contiene
Texto Una cadena corta y libre — Cliente, Entorno
Número Una cantidad, con unidad opcional delante o detrás
Fecha Una sola fecha
Casilla Sí o no
Selección Uno o más valores de una lista que defines
Miembro Una o más personas del espacio de trabajo
URL Un enlace, renderizado como clicable

Los campos propios se comportan como los integrados donde importa: puedes filtrar por ellos, mostrarlos como columnas de lista, fijarlos en masa, y leerlos o escribirlos desde la API y desde un agente vía MCP.

Una propiedad vacía no ensucia la tarea. Si no hay nada puesto, la mayoría de propiedades simplemente no se muestran — la excepción es Estado, que toda tarea tiene siempre y siempre enseña.

Por eso una tarea sin rellenar parece tranquila en vez de parecer un formulario a medias.