Somos un equipo cuyo trabajo principal es técnico pero no de desarrollo de software, y hemos estado usando Scrum como nuestro marco principal durante un tiempo (aunque es probable que lo que estemos haciendo esté más cerca de ScrumBut en varios aspectos ) .
Dicho esto, hoy surgió una pregunta en Planificación de Sprint para la que no sabía la respuesta: a veces, al planificar el trabajo, existe la tentación de simplemente hacer algunas de las tareas sin incluirlas en el Sprint Backlog. O son lo suficientemente pequeños como para que sea más rápido realizarlos en lugar de crear una tarea de Jira, o la tarea es parte del proceso de planificación (por ejemplo, hacer una investigación rápida para ayudar a comprender algo que necesita estimación) pero hacerlo conduce naturalmente en un trabajo más grande.
¿Hay alguna guía para reconocer cuándo se debe poner algo en el tablero en lugar de simplemente tirarlo a un lado? Lo mejor que pude sugerir fue "Si necesita pensarlo, probablemente deba ponerlo en el pizarrón".
Las tareas que no aparecen en la lista aumentan el cambio de contexto . La gente tiene que tenerlos en cuenta, pero se olvidan. Luego recuerdan sobre ellos en medio de otra tarea y piensan para sí mismos "Ups, casi lo olvido, pero necesito tenerlo en cuenta. ¿Qué más olvidé?". Esto aleja el poder del cerebro de la tarea real en cuestión. Todo esto puede repetirse varias veces, y al final del día te sientes agotado porque con frecuencia cambias a pensar en estas pequeñas tareas.
Simplemente es más fácil crear un ticket para cada una de esas tareas. O cree 1 ticket donde enumere todas las tareas pequeñas como viñetas. Después de que alguien implemente una de las tareas pequeñas, simplemente puede editar el texto y colocar una pequeña marca de verificación junto a los elementos terminados.
Si lo ignoras durante la planificación no importa mucho. Si estima durante su planificación, simplemente coloque rápidamente un pequeño número en el campo y continúe.
Hay dos preguntas separadas pero relacionadas aquí.
¿Cómo contabilizo el trabajo que forma parte del proceso de planificación?
Scrum da cuenta de esto en el refinamiento de la cartera de productos. Los equipos con los que trabajo tienden a no tener problemas en Jira para el trabajo de refinamiento a menos que el trabajo sea intensivo. Se asigna tiempo en cada Sprint para individuos o pequeños grupos para ver el trabajo en la parte superior de la cartera de pedidos y comenzar a agregar detalles. Las etiquetas permiten al equipo filtrar los problemas que necesitan refinamiento o atención particular (desarrollo, UX, producto).
Para un trabajo muy intensivo que produce algo más que actualizaciones de un ticket de Jira, puede llamarse Spike, que se rastrearía como un problema de Jira, se asignaría a una o más personas y el resultado se adjuntaría y revisaría.
¿Cómo gestiono las tareas pequeñas?
Durante el refinamiento, la persona o el grupo que trabaja en el refinamiento de un problema en particular puede comenzar a agregar tareas. En lugar de usar subtareas o problemas separados en Jira, los equipos con los que trabajo a menudo comienzan enumerando el trabajo dentro del problema original. Si lo necesita, puede usar un campo personalizado para agregar un lugar especial para esta información, o puede usar complementos que agregan funciones como listas de verificación a los problemas de Jira.
A veces, el problema original se descompone en dos cuerpos de trabajo separados. En ese caso, se registraría un nuevo problema y se vincularía al original. Otras veces, el trabajo está más estrechamente relacionado pero se puede dividir entre varias personas. En esos casos, las subtareas pueden ser más útiles. Si es probable que el trabajo lo realice una sola persona, puede enumerarse en el problema original.
Al final, se trata de lograr un equilibrio. Tener más problemas o subtareas puede aumentar la visibilidad, pero también lleva un poco más de tiempo ingresar los problemas y asegurarse de que la información en cada uno sea correcta. Es un acto de equilibrio dependiendo de quién está haciendo el trabajo y cuál es la unidad de entrega.
O son lo suficientemente pequeños como para que sea más rápido realizarlos en lugar de crear una tarea de Jira.
Las razones por las que es posible que desee realizar un seguimiento de una tarea tan pequeña incluyen:
Esto no significa que tenga que rastrearlo, solo que si hay suficiente valor, puede valer la pena rastrearlo.
o la tarea es parte del proceso de planificación
Scrum prevé que el equipo dedique hasta el 10 % de su tiempo a prepararse para el trabajo futuro. Una pequeña tarea que forma parte del proceso de planificación cabe en este 10 % y, por lo tanto, ya se tiene en cuenta en el enfoque de Scrum.
Parece que no tiene mucho sentido hacer un seguimiento de una tarea de este tipo a menos que planee hacer algún tipo de análisis en su proceso de planificación.
He realizado varios proyectos pequeños a lo largo de los años para Apple, por lo que puedo dar fe de que tienen (o tenían...) carteles en las paredes que decían: "¡Ponlo en el RADAR!"
("RADAR" es el sistema de gestión interno que utilizan para casi todo).
"No importa cómo lo hagas, y no importa cuán pequeño pueda 'parecer' ser el asunto", ¡ clava una chincheta [al pobre insecto...] y pégala en el tablero!" No permitas que el existencia de él, ni su posible significado, para escapar del aviso oficial (incluso si nunca te molestas en "asignarle horas"). Lo más importante para la posteridad es documentar que existió .
Claro, está bien usar inicialmente "un conjunto de viñetas, incluso una etiquetada (digamos...) 'FYI' que sigues agregando". Si alguien en una fecha futura necesita reorganizar las cosas, "que así sea". Por ahora: "¡Ponlo en el RADAR!"
don branson