¿Debería incluir tareas que no sean de desarrollo en su backlog de Scrum?

Question

Tenemos problemas para la incorporación de ciertos tipos de tareas en nuestros productos y Sprint retrasos:

• reuniones con clientes
• Formación y
• tareas administrativas de intercambio de conocimientos

Algunos de estos no están directamente relacionados con el proyecto, por lo que es fácil dejarlos de lado y referirse a ellos como gastos administrativos generales (lo que reduce los puntos factibles de la historia en un sprint).

Algunas tareas, sin embargo (generalmente reuniones de clientes) son recurrentes o muy frecuentes. ¿Cómo deben manejarse? Por lo general, no se relacionan directamente con ninguna historia de usuario en particular, pero son vitales para el proyecto.

Answer 1

En mi opinión, las "tareas" realmente no pertenecen a la cartera de pedidos del producto, los elementos de la cartera de productos (PBI) deberían usarse para cosas que son visibles para los usuarios finales u obligatorias para lograr tales elementos y expresadas en una forma de demostrar su valor comercial.

Los sucesos recurrentes, como reuniones, tareas administrativas, etc., realmente no coinciden con esta definición de PBI y no los incluiría en el nivel de Product Backlog. En realidad, no veo el sentido de rastrearlos en absoluto (suena como una sobrecarga inútil, es decir, desperdicio) y simplemente los incluiría en la velocidad general. Simplemente funciona.

eventos

no recurrentes, como una reunión especial, R & D, exploración, etc. realmente no pertenecen a la PB ni (¿cómo debería un valor PO ellos y dar prioridad a ellos ??) y yo prefieren incluir su "costo "en la estimación de la PBI relacionada. Y cuando el artículo es seleccionado, creamos una tarea correspondiente en el Atrio de Sprint, con una estimación de espacio de tiempo.

Y manejamos entrenamientos como vacaciones. Si un miembro del equipo va a algún entrenamiento, esto afecta la asignación de miembros del equipo (por ejemplo, 90%) y, por lo tanto, la capacidad general del equipo calculada al comienzo de un Sprint. Y recogemos menos artículos.

Answer 2

En mi último proyecto pusimos en marcha algunas actividades en nuestro scrum board. No estaban en la cartera de pedidos del producto, pero los inventamos durante nuestro juego de planificación.

El tipo de actividades que incluía era talleres de clientes, actividades de liberación, etc.

La razón por la que los incluimos en nuestro tablero scrum fue para que sea visible para cualquier persona en el equipo de lo que todos los demás estaban haciendo, y en algunos casos también para asignar la tarea a alguien que no está en el medio de otra tarea crítica.

Answer 3

La tarea no está relacionada con la acumulación de productos. La tarea está relacionada con la acumulación de sprints. Las actividades que describiste no son tareas.

Cuando planificamos nuestro próximo sprint siempre reducimos la capacidad planificada en todas las fiestas y entrenamientos. También reducimos la capacidad por "gastos administrativos". En nuestro caso, la sobrecarga administrativa suele ser de 1MD por miembro del equipo por semana. Esta sobrecarga es para reuniones y posiblemente asistencia para el mantenimiento de proyectos ya implementados.

Editar:

Creo que nunca se debe crear tareas para reuniones, presentaciones, etc., en su cartera de pedidos de primavera. ¿Por qué?Porque cada tarea tiene alguna estimación que afecta el sprint actual. Durante las tareas de sprint se completan en tiempo real y, en base a ese gráfico, se muestra el progreso del equipo en la entrega del valor del cliente. ¿Qué valor recibirá el cliente de la reunión? Además, tal tarea probablemente no esté relacionada con la historia concreta del usuario, de modo que ¿qué progreso será visible en la tabla de quema del producto? ¿Cómo se decide cuántas historias de usuarios se deben tomar para el próximo sprint cuando se debe contar con un valor que no está incluido en su complejidad (puntos de la historia)?

Agregar tales tareas ficticias (tareas sin ningún valor agregado) a su acumulación de sprints también afectará su velocidad. Parecerá que cada punto de la historia cuesta más que en realidad porque el tiempo de las reuniones se incluirá en el trabajo real.

¿Qué tipo de reuniones quieres agregar a tu acumulación de sprints? SCRUM necesita pocas reuniones: reunión diaria, reunión de planificación, reunión de revisión, reunión retrospectiva y en el proyecto más grande SCRUM of SCRUM. La reunión diaria es tan breve que no tiene que incluirse en la planificación. La reunión de planificación, la reunión de revisión y la reunión retrospectiva no tienen que incluirse en el sprint. SCRUM of SCRUM es específico y no afecta a todo el equipo; puede reducirse de la capacidad planificada de los miembros asistentes. No se necesitan más reuniones. Lo más importante: La comunicación necesaria para completar la tarea forma parte de la estimación de la tarea.

Si necesita otras reuniones, simplemente reduzca su capacidad. Si el cliente, la gerencia o el propietario del producto se quejan de una capacidad pequeña, simplemente explíqueles que se debe a una carga administrativa o de burocracia no estándar.

Answer 4

Las tareas recurrentes típicas son absorbidas por la estimación/velocidad. Cosas como la reunión de pie, interacciones normales del desarrollador, pausas, etc. ...

Para otros eventos que no están relacionados con la creación del producto, prefiero eliminar ese tiempo de la disponibilidad del desarrollador para tener la capacidad correcta.

lo tanto, el número de casos de uso que podemos planificar dependen, su estimación, la velocidad del equipo y, por supuesto, la capacidad

Answer 5

Mi opinión es que si estas tareas no están directamente relacionados con una característica, al igual que el entrenamiento, no debe incluirlos en la acumulación de productos, sino ajustar el tiempo disponible de los desarrolladores y, en consecuencia, la velocidad de sus iteraciones. No es porque tenga, por ejemplo, una semana laboral de 40 horas, por lo que puede esperar que las personas trabajen 40 horas en proyectos.

Answer 6

Si las reuniones u otras tareas no relacionadas con el desarrollo están directamente relacionadas con el logro de los objetivos del proyecto de sprint \ iteration \, entonces no tengo ningún problema en incluirlos en el plan de iteración de retraso de sprint. Si nada más ayuda a asegurar que las tareas se hagan aumentando su visibilidad.

Answer 7

Si no incluye las cosas que las personas deben hacer en su backlog, ¿cómo se propone gestionarlas?

Las iniciativas de no desarrollo toman tiempo, y son tan importantes para entregar un producto de calidad como dev y qa funcionan.

Puede optar por utilizar una cartera de pedidos por separado para esos artículos, o llevarlos en un plan de proyecto separado, pero luego está trabajando desde dos retrasos de trabajo, y la secuencia y el tiempo se convierten en un problema.

Normalmente forzo a los equipos a crear historias para actividades que no son de desarrollo, como 'gerente de producto, necesito crear una hoja de ruta o' como gerente de producto, necesito configurar talleres técnicos para revisar la acumulación de manera que los equipos de desarrollo pueden entender las características '.

realmente depende de la situación, pero si la acumulación es EL lugar central para capturar y administrar el trabajo, ¿por qué es solo el desarrollo y el trabajo de QA para lo que se usa?

Answer 8

Puede gestionar tareas que no sean de desarrollo en una placa Trello. Estas pueden ser actividades de investigación o extracción de datos para usar en el desarrollo. Estos no pertenecen a JIRA o Rally ya que no son tareas de desarrollo y no tienen una estimación del punto de la historia.

Answer 9

No existe una fórmula de corrección para decidir User Stories en Scrum. En mi proyecto, seleccionamos y elegimos qué elemento de trabajo debe convertirse en Historias. P.ej. tareas como la comparación de 2-3 herramientas IDE dev se incluyen en una acumulación porque están directamente relacionadas con el desarrollo. De lo contrario, planifico una actividad de desarrollo de 5 horas por día para cada miembro del equipo para que pasen las horas restantes asistiendo a capacitación, documentación, intercambio de conocimientos, programación entre pares, etc. Esto funciona para justificar demo versus velocidad de sprint.