Incidencias

Según la teoría de Atlassian, las incidencias constituyen las tareas que han de finalizarse para poder alcanzar los Epics. Normalmente, un grupo de tareas corresponde a un epic.

¿En qué fase se definen?

Las incidencias tienen diferentes fase de implementación en función del estado del proyecto.

Fase de propuesta (New Business)

En una fase de propuesta, puede ser que por la complejidad del proyecto algunas de las incidencias queden reflejadas. Este caso ser´ía óptimo, si es necesario justificar con actos el servicio.

Ejemplo: Se determina un Epic/ Servicio facturable de Diseño Web. En esta fase, tendría sentido que ya se generasen las incidencias de Diseño Low-fi & Hi-fi, aunque luego pasen por una restructuración una vez se haga el onboarding.

Puede que las incidencias pasen por una fase de revisión en cuanto a la organización del proyecto, pero siempre se deberían de respetar las fechas planteadas en New Business si el cliente así lo valida. (Se sobrentiende que el equipo las ha propuesto o validado antes de la presentación de la propuesta).

Fase de Onboarding (Project Manager)

En una fase de Onboarding, pueden pasar dos cosas:

• Incidencias predefinidas en una fase de propuesta

• Incidencias no predefinidas en una fase de propuesta

Tanto si las incidencias han sido definidas en una fase de propuesta como si no, el Project Manager tendrá la responsabilidad de crearl las principales en una primera instancia con el equipo para el comienzo del proyecto y/o modificar o subdividir las ya generadas.

Fase de "In process" (Team & Project Manager)

En una fase de proyecto ya en proceso, el equipo tiene la responsabilidad de generar todas aquellas incidencias que van surgiendo en el transcurso del proyecto. El Project Manager tendrá que estar al tanto de las mismas y hacer seguimiento para evaluar que esas incidencias no varían el transcurso del proyecto y los tiempos definidos.

Elementos básicos de una incidencia

Las incidencias en Jira deben establecerse una vez se ha creado el proyecto y su configuración, pero también han de alimentarse de manera consecutiva.

Epic asociado

Todas las incidencias deberán de tener un epic asociado, ya sea que se establezca en el cronograma, backlog o en un sprint concreto.

Nomenclatura

No existe una nomenclatura estricta para la definición de las incidencias, pero si debe ser lo más descriptiva y minimalista posible para respetar el espacio de texto visible.

Puedes hacer uso de la descripción de la incidencia para alargar más la especificación de la tarea.

Tiempo

Al igual que los epics, las incidencias también deberán de tener un tiempo específico.

Si una incidencia se establece fuera

Estimación de horas

Las incidencias, a diferencia de los epics no llevarán una estimación de horas asociada. Pro, si deberemos tener en cuenta que el sumatorio de horas de implicación en incidencias de un epic concreto no puede ser mayor que la estimación total de ese epic.

¿Y qué pasa si es mayor? 🚨 Si ese tiempo se sobrepasa, habrá un problema gordo, ya que la organización, ejecución, venta y gestión de horas no ha sido pautada correctamente.

En servicios on going, las tareas pautadas en 1 mes concreto no podrán superar las horas definidas de ese mes.

Responsable de las incidencias

Cada incidencia tiene un responsable asociado. El responsable de la incidencia es el encargado de mantener actualizado/a el estado de las tareas, así como su correspondiente consecución.

¡Una incidencia, no puede tener varios responsables!

De la misma manera, de forma autónoma, el equipo individualmente será responsbale de mantener actualizado el pipeline con nuevas incidencias que puedan surgir.

Asignación de la capacidad

Las incidencias no se vincularán con la carga de trabajo en Tempo. Si los epics.