En un standup Scrum, ¿la discusión de lo que se hizo ayer se limitará a las tareas en el tablero o todo el trabajo realizado?


10

Sé que las reglas de Scrum en las standups diarias dicen que el equipo solo debe hablar sobre lo que hicieron ayer, lo que están haciendo hoy y cualquier cosa que los bloquee. Nada más. Pero el problema es que, a veces, los desarrolladores pasan su día haciendo un trabajo irrelevante para sus tareas, y luego hablan de ello en el standup. ¡Es lo que hicieron ayer!

En mi experiencia, descubrí que es más efectivo hablar sobre las tareas en el tablero, mantener el enfoque centrado y mantener el enfoque de todos en sus tareas, revisar sus estimaciones y rastrear sus registros diariamente.

¿Es válido limitar la discusión a las tareas en el tablero?


1
¿Que los desarrolladores pasen días enteros sin trabajar en sus tareas podría ser un problema que sería invisible si no se menciona?
RemcoGerlich

Todos hablan 30 segundos para decir lo que hicieron antes. ¿Cuánto más centrado lo quieres? Usted no revisar las estimaciones. Realiza un seguimiento de las tareas cuando las pasa al siguiente tipo (revisor o evaluador).
gnasher729

Respuestas:


5

De acuerdo con el contenido de la Guía Scrum sobre standups diarios, las tres preguntas para discusión son:

  • ¿Qué hice ayer que ayudó al Equipo de Desarrollo a alcanzar el Objetivo Sprint?
  • ¿Qué haré hoy para ayudar al Equipo de Desarrollo a alcanzar el Objetivo Sprint?
  • ¿Veo algún impedimento que me impida a mí o al equipo de desarrollo alcanzar el objetivo de Sprint?

Todas las preguntas se centran en el objetivo de Sprint, no en las tareas que están en el tablero. Nuevamente, según la Guía Scrum, el Objetivo Sprint se crea en Sprint Planning y define "un objetivo que se cumplirá dentro del Sprint a través de la implementación de la Cartera de Producto, y proporciona orientación al Equipo de Desarrollo sobre por qué está construyendo el Incremento".

Todo lo que hace su equipo de desarrollo debería, idealmente, ayudar al equipo a progresar hacia la Meta Sprint. Estas pueden ser actividades no planificadas que no están en el tablero que tuvieron que hacerse, o podrían ser cosas en un nivel más bajo que pueden haber sido consideradas y estimadas, pero en un nivel más bajo que un elemento en el tablero.

Diría que deje que su equipo hable sobre todo lo que hicieron ayer. Si están hablando de cosas que no ayudan al equipo a alcanzar la Meta Sprint, entonces alguien debería mencionar esto, especialmente si hubieran hecho otras cosas que hubieran hecho que el equipo estuviera más cerca de completar la Meta Sprint.

Una excepción puede ser si un individuo está apoyando a múltiples equipos Scrum. En la reunión, probablemente no deberían hablar sobre todo lo que hicieron ayer, sino sobre lo que hicieron en apoyo del equipo que actualmente está en pie.

La Retrospectiva de Sprint es un buen momento para hablar sobre este tema con el equipo. Hay muchas preguntas para considerar:

  • ¿Está el equipo con poco trabajo en los artículos relacionados con el Objetivo Sprint?
  • ¿Hay demasiado trabajo no planificado?
  • ¿De dónde viene el trabajo no planificado y quién lo autoriza?
  • ¿Por qué las personas trabajan en cosas que no están en el tablero?
  • ¿Deberíamos mostrar más detalles en el tablero para vincular las cosas que hace con los elementos del tablero con mayor facilidad?

2
El problema con "Sprint Goal" es demasiado vago y soñador. en la práctica Sprint Goal == completar las tareas en el tablero. si lo que trabajó no está allí, debería estar o no debería estar trabajando en él
Ewan

1
@Ewan Un cliente llama y nos dice que el software en vivo se bloqueó y tenemos un registro y un informe de error. Es importante tomarse el tiempo para clasificar ese informe de inmediato, incluso si no está en la pizarra en este momento. Puede que esté dentro del alcance o que se pueda incluir en la cartera de pedidos, pero es algo que hice ayer y podría ser la razón por la que no pude ayudar a Bob con su problema hasta después del almuerzo. No debería hacer esa tarea a ciegas, pero probablemente nadie la ponga en el tablero a menos que sea arrastrada a este Sprint. También puedo pensar en otros ejemplos.
Thomas Owens

1
debe agregar un boleto "triage live bug" al tablero y marcarlo como hecho. Luego, al final del sprint puedes decir con seguridad. 'este sprint pasamos X horas mirando los errores del usuario. Por eso llegamos tarde. tenemos que entrenar mejor al servicio de asistencia 'De lo contrario, no se hace nada en ese sprint y el primer ministro solo tiene oídas excusas del equipo' ¡oh, había muchos errores para ver esta semana! encogiéndose de hombros '
Ewan

1
@Ewan Creo que eso es increíblemente innecesario. No quiero pasar mi día escribiendo boletos. Un proceso debe permitirme hacer mi trabajo, y tomar 90 minutos para clasificarlo en lugar de 95 minutos para clasificarlo y luego poner un boleto que diga que calculé que un boleto es una tontería. Especialmente si tienes que clasificar varias entradas. No necesita entradas para discutir cosas en la retrospectiva. Si está utilizando herramientas electrónicas, puede encontrar boletos modificados por el equipo en el Sprint para ver si había muchas cosas para clasificar, no hay rumores allí.
Thomas Owens

1
el nivel de informes si corresponde a su scrummaster / pm / empresa. podrías escribir un boleto de "errores de trigaing" para cubrir todo tu trabajo del día. Pero lo importante es que lo REGISTRE COMO PARTE DEL SPRINT. no asuma que solo se tiene en cuenta por alguna otra métrica
Ewan

0

No, deberías hablar de lo que hiciste ayer.

Si no está en el tablero, debe realizar una de las siguientes acciones:

  • ponlo en el tablero,
  • deja de hacerlo
  • o cambiar de equipo.

El más común, digamos para el trabajo de emergencia no planificado, es escribir una tarjeta y pegarla en la pizarra. Esto asegura que al final del sprint pueda medir la velocidad y explicar por qué no se alcanzaron los objetivos del sprint.

Un miembro del equipo que trabaja en cosas que no están en el sprint es, en mi opinión, una de las razones principales por las que las adopciones ágiles fallan. Por lo general, este es un desarrollador desviado para solucionar problemas en vivo en otro proyecto.

Otra cosa molesta en los sprints es "PM hablando de reuniones para otros proyectos". En mi opinión, el primer ministro no es parte del equipo de scrum, ellos cumplen el rol de Scrum 'Product Owner' y, por lo tanto, están allí para responder preguntas, no para informar el progreso.


3
Existe un trabajo no planificado: trabajo que debe hacerse para desbloquear a alguien o realizar otras tareas que están en el tablero, pero no está en el tablero. A menudo, puede ser más rápido hacerlo y luego ponerlo en el tablero. Depende del equipo discutir cómo manejar eso. Mi equipo actual tiene reglas: todo lo que se implementa en un entorno de producción o de control de calidad o las tareas que demoran 2 horas se incorporan al tablero. Todavía hay algunas tareas más cortas que necesitan suceder que se mencionan pero que no forman parte del tablero porque no se ajustan a los criterios.
Thomas Owens

@Ewan, ¿puedes ampliar eso? ¿Quién maneja la reparación de errores vivos, si no está en el Sprint? ¿Cómo puede ser el propietario del proyecto al mismo tiempo gerente de proyecto? (Quiero decir, ¿quién es él o si está haciendo malabares con ambos roles?)
Dennis

editado para mayor claridad
Ewan

@Dennis: Project Manager no es un rol de Scrum.
RemcoGerlich

@Ewan, gracias. Esto no es esencial para la respuesta, pero tengo curiosidad: el "Primer Ministro hablando de reuniones para otros proyectos", ¿cómo funciona? ¿Los PM entran en una reunión sobre el proyecto X, pero hablan sobre Y? Me cuesta mucho visualizar esto. ¿Cómo / por qué es esto posible? ¿Quiere decir que entran y esencialmente comienzan a cotillear o salir del tema o hay una razón más profunda para que hablen sobre las metas / necesidades específicas de una reunión no inmediata? Yo diría "oye, me alegro de escuchar esto, pero no soy parte del proyecto Y ... sin conocimiento / experiencia allí, ¿podemos volver a X?"
Dennis
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.