Cuando un equipo no puede desarrollar sus tareas normalmente, por ejemplo por experimentar errores aleatorios en el ambiente de trabajo, lo natural es sobrestimar las tareas de desarrollo para poder llegar a terminar las tareas. Menciono que es natural, porque sale instintivamente debido a que la mayoría de la gente estuvo en un proyecto con un proceso de desarrollo en cascada, y sobrestimar era la forma con que se trataba este problema.
En Scrum, en una reunión de planeamiento del sprint, cuando todas las historias ya tienen story points y hay que crear tareas y estimarlas en horas, la idea es tener en cuenta que se está trabajando en un ambiente ideal. Si se sufren problemas de ambiente de trabajo, hay dos formas de informar esto.
La primera es bajar la capacidad de los miembros del equipo afectados. Bajando la capacidad en un cierto porcentaje, se tienen menos horas por sprint para asignar tareas. Esto hay que informarlo insistentemente al cliente o a quien pueda ayudar a resolver este problema, ya que claramente queda evidenciado que el equipo puede dar más, pero debido a estos problemas se pueden asignar menos tareas, y entonces la velocidad del equipo se aleja de la ideal.
La segunda es no disminuir la capacidad, pero hacer un tracking de estos errores, teniendo una historia llamada "tareas no planeadas", y cargando tareas con un cierto tiempo para informar estos errores. Esto tal vez tenga mayor visibilidad para el cliente, pero insume mayor tiempo al equipo.
Resumiendo, la idea es dejar atrás el viejo paradigma de sobrestimar y mediante alguno de estos dos métodos, reflejar la realidad del trabajo del equipo para que se tomen acciones y se puedan resolver temas que afectan la velocidad.
En Scrum, en una reunión de planeamiento del sprint, cuando todas las historias ya tienen story points y hay que crear tareas y estimarlas en horas, la idea es tener en cuenta que se está trabajando en un ambiente ideal. Si se sufren problemas de ambiente de trabajo, hay dos formas de informar esto.
La primera es bajar la capacidad de los miembros del equipo afectados. Bajando la capacidad en un cierto porcentaje, se tienen menos horas por sprint para asignar tareas. Esto hay que informarlo insistentemente al cliente o a quien pueda ayudar a resolver este problema, ya que claramente queda evidenciado que el equipo puede dar más, pero debido a estos problemas se pueden asignar menos tareas, y entonces la velocidad del equipo se aleja de la ideal.
La segunda es no disminuir la capacidad, pero hacer un tracking de estos errores, teniendo una historia llamada "tareas no planeadas", y cargando tareas con un cierto tiempo para informar estos errores. Esto tal vez tenga mayor visibilidad para el cliente, pero insume mayor tiempo al equipo.
Resumiendo, la idea es dejar atrás el viejo paradigma de sobrestimar y mediante alguno de estos dos métodos, reflejar la realidad del trabajo del equipo para que se tomen acciones y se puedan resolver temas que afectan la velocidad.
2 comentarios:
No sabes por donde pasa el 503? (Solo para entendidos)
Ja, pasa por la esquina de reducción de capacidad y afecto a la motivación. Esto ultimo también es importante, los equipos no están felices y se frustran si su trabajo se ve afectado por errores que no están de su lado y no pueden resolver.
Publicar un comentario