sinra¿Qué es una Capability?
Una capability es una funcionalidad de producto concreta: algo que tu producto será capaz de hacer una vez entregado. Se sitúa en el nivel de abstracción que product managers, desarrolladores y stakeholders pueden entender.
“Exportación CSV de informes” es una capability. O está entregada o no lo está. No existe un estado ambiguo de “parcialmente terminado”.
Capabilities vs Epics
La diferencia clave está en los criterios de finalización:
| Epic | Capability | |
|---|---|---|
| Definido por | User stories agrupadas | Una funcionalidad de producto concreta |
| Terminado cuando | Todos los tickets hijos están cerrados | La funcionalidad funciona como se definió |
| Estado | A menudo permanece abierto indefinidamente | Binario: entregado o no |
| Comunicable a stakeholders | Raramente | Sí, directamente |
Un epic puede permanecer abierto meses a medida que se añaden nuevos tickets. Una capability tiene una decisión de alcance al inicio: cuando esta funcionalidad se entrega, la capability se cierra.
Las Capabilities en la Planificación
Las capabilities son la unidad de planificación a nivel de release. Cuando defines una release, le asignas capabilities. Esto responde a “¿qué incluirá la versión 2.4?” a nivel de funcionalidades, no a nivel de tickets.
Esto hace que la planificación de releases sea comunicable:
“La versión 2.4 incluye: exportación CSV, notificaciones por email y gestión de roles.”
Esa frase funciona en una reunión diaria, en una reunión con stakeholders y en un changelog de producto.
Vincular Capabilities
Cada capability se conecta a:
- Proyecto: la iniciativa de alto nivel a la que pertenece
- Release: qué versión entregará esta funcionalidad
- Issues: las especificaciones, planes, tareas y bugs que la describen y la construyen
- Testings: los casos de prueba QA que la validan, opcionalmente especificación por especificación
Esta cadena proporciona trazabilidad completa desde el objetivo estratégico (proyecto) hasta las tareas individuales (issues) y la validación (testings). Consulta Trazabilidad.
Las Issues por Especificación
La página de una capability no muestra una lista plana de issues. Cada especificación forma un grupo que contiene sus planes y sus tareas, en el orden de la cadena, dibujado como un árbol con una línea por issue. Cada línea lleva sus propios indicadores a la derecha:
- el estado de la issue y, para una especificación o un plan, su realización (Not started, In progress, Done) con las tareas terminadas sobre el total
- el número de pruebas que verifican una especificación, o No test yet
- el tiempo estimado de una especificación, cuando no es cero
Una especificación sin ninguna tarea lo indica claramente. Las issues sin padre (bugs, tareas aisladas, planes huérfanos) se agrupan aparte, después de las especificaciones (“Without parent”). Las issues de otras capabilities que Concern a esta se listan por separado en Concerned issues y nunca cuentan en su progreso.
La Release de una Capability
Una capability pertenece como máximo a una release, y decide la release de todas sus issues. Mueve la capability a otra release, o quítala de toda release, y cada issue la sigue en la misma operación, terminada o no. Una capability nunca queda a caballo entre dos releases. Cuando colocas una capability en una release por primera vez y aún no tiene release deseada, Sinra también copia esa release en la release deseada. Consulta Releases.
Cuerpo de la Capability
El cuerpo de la capability utiliza un editor enriquecido. Los equipos suelen escribir:
- Descripción de la funcionalidad orientada al usuario
- Criterios de aceptación
- Notas técnicas y restricciones
- Enlaces a recursos de diseño
Dado que las capabilities son compartidas entre producto e ingeniería, este cuerpo se convierte en la especificación viva de la funcionalidad.
Seguimiento del Progreso
El progreso de una capability es visible a través de:
- Tareas y bugs terminados sobre el total. Las especificaciones y los planes no cuentan aquí: su propio avance es la realización que se muestra en cada línea.
- Tiempo estimado vs. tiempo empleado
- Estado de aceptación de los testings
La fase de una capability en el panel de producto sigue la misma lógica. Especificaciones y planes son trabajo de redacción, tareas y bugs son trabajo de desarrollo. Una capability cuyas especificaciones están escritas pero cuyo plan aún se redacta está en fase de especificación. Pasa a desarrollo en cuanto una tarea o un bug está en curso.
Esto proporciona una lectura rápida y honesta sobre si la capability está realmente cerca de completarse o si simplemente tiene la mayoría de tickets cerrados.
La entrega junto al estado de escritura
El estado de escritura de una capability solo dice si su spec está escrita. A su lado, Entrega 2/5 issues cuenta las issues de desarrollo terminadas sobre el total, para que una capability con la spec hecha no se confunda con una entregada.