Actualmente estoy en el proceso de hacer que mi equipo esté en condiciones de comenzar a usar Scrum y Sprints en las próximas dos semanas. Tengo la intención de asumir el papel de Scrum Master siempre que todos en mi equipo estén de acuerdo en que tiene sentido. Uno de los miembros de mi equipo solo trabaja a tiempo parcial y he recibido comentarios variados sobre la duración y el propósito de una reunión de planificación de sprint. Una sugerencia que tuve fue dividir la reunión de planificación del sprint en más de un día, en parte para que la persona a tiempo parcial aún pueda participar plenamente durante el plan del sprint. Sin embargo, esto le quita más tiempo "productivo" a la persona a tiempo parcial. Esto también supone que la planificación del sprint es algo que lleva "alrededor de un día" para lograrlo, dado un sprint de dos semanas.
Entonces, ¿debería incluir a mi persona a tiempo parcial en nuestras sesiones de planificación de sprint? ¿O es mi trabajo servir como su representante y asegurarme de que, aunque no esté presente para la planificación del sprint, sus habilidades y necesidades aún se satisfagan?
Creo que hay otro punto en esta pregunta que aún no está cubierto y es:
(¿o por qué tiene que tomar mucho tiempo?)
Respuesta corta: en la planificación de un sprint, solo debe planificar el sprint .
Lo que eso significa:
Porque la gente hace demasiado en la planificación de un sprint. Entre los peores asesinos de la planificación se encuentran sin ningún orden en particular: desglose de tareas, estimación de tareas, estimación de historias, "preparar" las historias para planificarlas en primer lugar, discutir características, averiguar quién está disponible durante el sprint en primer lugar. Podría seguir. Y también podría hacerlo la planificación del sprint.
No hagas estas cosas en una planificación de sprint . No son planificación, son preparación y te preparas de antemano. Porque saber es la mitad de la batalla .
Obtuve los mejores resultados sacando a estos asesinos de la planificación de esta manera:
NB: Mencioné 'listo' un par de veces. Esto se relaciona con la definición de hecho (que define cuándo algo cuenta como entregado), pero cubre el otro extremo del proceso, la planificación de su sprint, la definición de cuándo una historia está lista para dividirse en tareas y estimarse. Para esto, al igual que para el Departamento de Defensa, usted y su equipo deben averiguar qué necesitan y con qué se sienten cómodos.
Sin embargo, quiero darte un ejemplo mío:
Si obtiene una rutina con sus pasos divididos de esta manera, su planificación no tomará mucho tiempo (tan solo dos horas para un sprint de dos semanas) y cada uno de los pasos se puede colocar de manera flexible a lo largo del sprint para hacer posible que asistan incluso sus empleados a tiempo parcial.
Su personal a tiempo parcial debe estar presente para la planificación de Sprint. Específicamente:
Todos los miembros del equipo Scrum deben participar en Sprint Planning. Si bien es importante que todos los miembros del equipo participen en la estimación de los elementos del Product Backlog, es fundamental que todos los que realizan las tareas participen activamente en la descomposición de las historias para el Sprint Backlog.
Las estimaciones precisas se basan en lo que los miembros del equipo saben (o no saben) sobre una historia. A menos que planee realizar las tareas usted mismo, no importa si piensa que una tarea es fácil, difícil o intermedia porque no es usted quien está haciendo el trabajo.
Cuando todo el equipo estima, tiene un consenso más amplio de lo que está involucrado y cuánto trabajo se necesita. Además, en un enfoque basado en equipos, más de una persona contribuye a cada historia, y cada persona que trabajará en una tarea relacionada con la historia debe:
Estas cosas son esenciales para que un equipo autoorganizado pueda coordinarse entre sí durante un sprint. Hacer esto por poder es derrotar los principios de autoorganización que Scrum debe aprovechar.
En el caso de los recursos a tiempo parcial, esto es aún más importante porque los trabajadores a tiempo parcial tienen más gastos generales cognitivos y de procesos que las personas a tiempo completo, y deberán coordinarse más estrechamente con el resto del equipo para garantizar transferencias exitosas. Empeorará las cosas, no las mejorará, al desintegrar a sus empleados de medio tiempo del resto del equipo en nombre de la eficiencia.
Esto variará según el equipo y el proyecto, y deberá adaptar los plazos para sus necesidades específicas. Para equipos nuevos, recomiendo comenzar con un día completo para Sprint Planning cada sprint, donde:
Los equipos experimentados pueden reducir este tiempo, especialmente con el uso efectivo de Backlog Grooming, pero tratar de reducirlo "solo porque sí" es una economía falsa. Después de todo, Sprint Planning es donde se realiza una parte significativa del análisis y diseño del equipo, por lo que asignar solo el 10 % de su sprint para asegurarse de que está construyendo las cosas correctas de manera sostenible es mucho más importante que recortar algunas horas-hombre de su presupuesto.
Eso depende del equipo, pero debe ser en un horario fijo. Dado que está tratando de incorporar personas a tiempo parcial, el equipo debe elegir un día que sea conveniente para la mayor cantidad de personas posible, y los trabajadores a tiempo parcial también deberán ser flexibles.
Los sprints pueden comenzar cualquier día de la semana que elija, por lo que no tiene nada de malo comenzar sus sprints un jueves si eso es lo que funciona mejor para su equipo. Lo esencial es que el cronograma sea tanto predecible como sostenible .
También puede dividir las sesiones de Product Backlog y Sprint Backlog en días, pero esto genera una sobrecarga adicional del proceso. Esto puede ser necesario si tiene recursos a tiempo parcial o matriculados, pero su equipo y su organización deben reconocer que esto creará una carga adicional en su proceso. TANSTAAFL ; es simplemente el precio que el equipo debe pagar si no puede garantizar los recursos dedicados, y la organización debe tratarlo como el costo de hacer negocios en lugar de desearlo para el maizal .
El principio básico de Agile/Scrum es que debe haber una comunicación directa entre el propietario del producto y el equipo que realiza el trabajo. Además, los miembros que realizarán el trabajo deben hacer un compromiso de equipo para completar lo que se inscribieron. Por lo tanto, debe intentar incluir a su persona a tiempo parcial en sus sesiones de planificación de sprint.
Sin embargo, no dijiste cuál es tu papel. Parece que eres el ScrumMaster. Como ScrumMaster he coordinado con recursos de medio tiempo mientras el sprint está en progreso.
No existe una regla estricta de que la planificación del sprint deba tomar un día para un sprint de dos semanas. Si puede realizar una planificación eficaz, sin acortar las actividades esenciales, está bien acortarla.
Recomiendo echar un vistazo a la Guía de Scrum disponible a través de Scrum.org (la compañía de Ken Schwaber): prácticamente establece las cosas y está escrito/mantenido por los codificadores del marco (Jeff Sutherland y Schwaber).
Todos los miembros del Equipo Scrum deben estar allí:
Solo las personas que realmente hacen el trabajo deben actuar en su nombre.
La reunión de planificación de Sprint es una reunión única, no más de 8 horas de duración para un Sprint de 30 días, proporcionalmente más corta en función de la duración del Sprint (por lo que un Sprint de 15 días tendría una reunión de Planificación de Sprint de no más de 4 horas ).
No se recomienda distribuir la reunión en varios días, ni siquiera para incluir a la persona a tiempo parcial. Un par de opciones serían:
Pero, si su equipo no puede determinar qué se puede hacer dentro de un sprint en una sola reunión de planificación, hay algo que debe examinarse. Por ejemplo, la duración del sprint puede ser demasiado larga/corta, los elementos de la cartera de productos pueden no estar definidos lo suficientemente bien como para estimarlos correctamente, etc. Con un sprint de dos semanas, está viendo una reunión de planificación de aproximadamente 4 horas, como máximo (la mayoría de los cuadros de tiempo en Scrum son duraciones "que no se deben exceder" y proporcionales en función de la duración del sprint, excepto la reunión diaria de Scrum de 15 minutos o menos).
Espero que ayude. Avíseme si desea alguna aclaración.
jason lowenthal
marca phillips
jason lowenthal
Todd A. Jacobs
jason lowenthal