¿Quién puede agregar "tareas" en Scrum/Kanban?

Cuando hacía Kanban en mi empresa anterior, cualquiera podía crear una tarea, una historia o una epopeya en nuestro tablero. Sin embargo, solo el PO podría priorizarlo.

En mi empresa Scrum actual, solo el PO crea Epics y Features, y generalmente crea las Historias de usuario. El equipo de desarrollo crea tareas y algunas historias de usuario "técnicas".

¿El concepto de "tarea" para problemas nuevos solo debe crearlo el equipo de desarrollo? ¿O puedo, como propietario del producto, también agregar tareas que yo como propietario del producto puedo hacer?

En cualquier situación, siempre era posible que un propietario de producto creara tareas para que las hiciera él mismo. Es posible que encuentre en su tablero Kanban que las tareas de orden de compra no siguen el mismo proceso que las tareas de desarrollo. es decir, las tareas de PO pueden tener una ruta de

Por hacer ___ En progreso ___ Revisado ___ Terminado

donde como las tareas de desarrollo pueden ser más como

Trabajo atrasado ___ Revisar ___ Desarrollar ___ Prueba de unidad ___ Prueba del sistema ___ Instalar para producir ___ Cerrado

Si este es su caso, una segunda tabla para trazar el segundo proceso es el camino a seguir. si el proceso es el mismo entonces el mismo tablero está bien.

También se pueden usar tarjetas de diferentes colores para ayudar a visualizar las tareas que son para los diferentes roles si lo desea.

Saludos

Gran pregunta. Los términos Elemento pendiente (PBI), Historia de usuario y Tarea a menudo se usan de diferentes maneras y pueden resultar confusos.

La respuesta simple a su pregunta es que en un tablero Kanban (especialmente fuera de Scrum) generalmente tiene un nivel de elementos que pueden ser historias de usuarios, tareas, tickets, solicitudes o lo que su equipo necesite. Entonces, si desea generalizar estas cosas a "Tareas" en lugar de tratar de usar historias de usuarios, no hay nada de malo en eso. De hecho, incluso puede usar una combinación de diferentes tipos de elementos, todos están en el mismo nivel.

Con la respuesta simple fuera del camino, aquí hay un poco más de complejidad:

En scrum, comúnmente vemos dos niveles en el tablero: tareas y elementos pendientes. La razón es que nos permite distinguir entre el elemento de valor agregado (el elemento pendiente, a menudo una historia de usuario) y la pequeña cosa discreta que se debe hacer, que es solo un paso en la entrega del elemento más grande. Esto se debe a que, en scrum, queremos usar el tablero para que el equipo organice su trabajo (tareas), pero también vigilar cómo progresa el equipo para agregar una funcionalidad valiosa al producto y lograr el objetivo del sprint (PBI).

En un tablero puramente Kanban, solo me preocupa el flujo de trabajo, por lo que generalmente no hay múltiples niveles de tareas. En la mayoría de los casos, todo en un tablero Kanban agrega valor y los pasos para entregarlo aparecen en las columnas del tablero.

Requisitos de escritura: las historias de usuario representan "deseos" de nivel excepcionalmente alto escritos desde el punto de vista de los usuarios finales para enfatizar el valor comercial en lugar de los detalles técnicos. Las historias se refinan a medida que se acerca la próxima reunión de planificación del sprint. Eventualmente, el equipo de desarrollo descompone las historias agregando tareas granulares. Tenga en cuenta que existen otros formatos, como recorridos de usuarios, casos de uso, etc. Las historias de usuario no funcionan bien con los requisitos no funcionales, por ejemplo. Entonces, ¿por qué limitarte a ti y a tu equipo con historias de usuario? Habiendo dicho eso, la mayoría de los elementos de su cartera de pedidos deben escribirse en formato de historia, a menos que esté trabajando en un producto que no interactúa mucho con los usuarios.

Quién hace qué: el propietario del producto debe escribir las historias de usuario de alto nivel. Luego, el equipo de desarrollo, durante las sesiones de refinamiento del backlog y la planificación de sprints, agregaría las tareas requeridas para completar la historia de usuario. Esta es la división natural del trabajo pero no una regla estricta. Dado que también es desarrollador, no hay nada que le impida escribir tareas. Similarmente,

Una nota sobre Kanban y Scrum: independientemente de si usa una herramienta en línea o un tablero con notas adhesivas, tiene mucho sentido diferenciar diferentes tipos de tareas. Si su herramienta no admite tipos de tareas o la adición de subtareas, utilice etiquetas o códigos de colores. Incluso las herramientas más sencillas/gratuitas como Trello ofrecen esta función. Por lo tanto, sus historias serían amarillas y todas sus subtareas naranjas. Otros colores representan otras cosas. Esto también se puede hacer fácilmente usando notas adhesivas, que vienen en diferentes formas y colores :).

Esto es algo que el equipo puede decidir en conjunto. Averigüe los diferentes tipos de trabajo (nueva historia, resolución de errores, cambios de operaciones, etc.) y acuerde cómo se introducen nuevos trabajos en cada categoría en el flujo y quién lo hace.

Sospecho que encontrará el mayor valor en mantener todo el trabajo de un producto determinado en el mismo tablero. Separar los tipos de trabajo lo dejará con subvisiones sesgadas; desea visualizar la imagen completa.