¿El scrum master también estima las historias de los usuarios?

Recientemente comenzamos a trabajar con scrum en un nuevo (gran) proyecto. Soy desarrollador, pero no participo en ese proyecto más que en mi rol como scrum master.
Conozco el software que usan, pero no uso la mayoría de sus herramientas/idiomas yo mismo.

Cuando hicimos nuestras primeras estimaciones puntuales de la historia, simplemente levantamos los dedos en una sesión en línea, luego discutimos las estimaciones (altas) y llegamos a un consenso.

Yo 'accidentalmente' también di una estimación.
¿Es esto aconsejable?

La pregunta ¿Quién debe estimar las historias de usuario? no es específico sobre la parte del scrum master aquí.

Soy desarrollador, pero no participo en ese proyecto más que en mi rol como scrum master. ¿Quieres actuar solo como Scrum Master, o quieres una parte de la acción de desarrollo, por así decirlo? :) Ahí está tu respuesta...

Respuestas (4)

Si haces trabajo de desarrollo en el sprint, debes estimar. Si no lo hace, entonces es mejor que no proporcione sus propias estimaciones de puntos de historia.

Puedes ayudar a tu equipo con información y consejos, y apoyarlos para llegar a un consenso, pero debes dejar que las personas que hacen el trabajo realicen las estimaciones, de lo contrario, podrías estar influenciándolos en una dirección u otra y entonces no tendrás cuello. en el juego cuando se trata de hacer el trabajo.

Si el equipo aprecia su aporte y quiere que brinde una estimación de las historias de los usuarios, está bien, pero es mejor concentrarse más en su rol como Scrum Master y no crear precedentes que luego lo lleven a hacer cosas más profundas en tecnología y menos Scrum Master"ing".

¿Qué califica como "trabajo"? ¿Funciona facilitar los rituales de scrum? ¿El equipo de cuidado de bloques está teniendo trabajo? ¿Está ayudando al propietario del producto con el trabajo de registro?
@AndrewSavinykh: trabajo como en el trabajo de desarrollo, como en la implementación de los requisitos de las historias de usuario. Estimas las historias de los usuarios. No se estiman cosas como organizar el backlog o facilitar eventos de scrum, varias reuniones, etc., que toman algo de tiempo del sprint, pero generalmente es una cantidad fija, ya que muchas de ellas son actividades con límite de tiempo.
@Bogdan Buena explicación. Si no está escribiendo código, no tiene idea de la complejidad o la cantidad de trabajo involucrado. Un maestro de scrum puede levantar los dedos, pero a menos que estén codificando, no es una estimación, es una conjetura.
Si se le pregunta a un experto en scrum que no realiza ningún trabajo de desarrollo, la mejor respuesta es señalar los datos anteriores de los equipos actuales sobre puntos y tiempo. "En mi época, tendríamos esto eliminado en..." no. Esto no se trata de lo que otros pueden hacer.

La Guía Scrum dice que el Equipo de Desarrollo es responsable de todas las estimaciones. Cuando el SM no es también un miembro del equipo de desarrollo, entonces debería depender del equipo en qué medida participa el SM. Es razonable contribuir a las discusiones de estimación si tiene algo útil que decir, pero le sugiero que se quede en un segundo plano para que el equipo sienta que "las personas que realizarán el trabajo hacen la estimación final".

No, las estimaciones deben ser realizadas por quien completará el trabajo. El Scrum Master no es necesariamente un experto en el dominio en todas las áreas en las que trabaja el equipo de desarrollo, ni es responsable de realizar o completar el trabajo.

La forma en que generalmente he visto que esto se hace es que el equipo de desarrollo lo discuta y vote, o que quien sea que tenga asignado el trabajo lo estime.

Si el Scrum Master debe participar en el proceso de estimación depende de si tiene información valiosa. Si tiene la perspicacia técnica para asumir las tareas, puede seguir adelante. Si no, entonces no tiene sentido.