PDF de programación - Checklist para Scrum Masters

Checklist
 para
 Scrum
 Masters
 

Fuente original : Michael James ([email protected]).
http://www.colabpro.com
14 September 2007 (Revised 24 July 2012)

Traducción : José Vázquez Sánchez. ([email protected])
http://www.gestiondeproyectosit.es
@PepeVazquezS
(09 Marzo de 2013)

INTRODUCCIÓN
 

Sobre
 la
 dedicación
 del
 Scrum
 Master.
 

Un ScrumMaster adecuado puede manejar dos o tres equipos a la vez. Si te
sientes satisfecho con limitar tu rol a la organización de reuniones, la
aplicación de timeboxes en las dinámicas Scrum, y con responder y ayudar a
la gente con los impedimentos que explícitamente se declaren, podrías llegar
a funcionar con la dedicación a tiempo parcial en esta función.

El equipo del cual seas Scrum Master muy probablemente seguirá siendo
superior a la media, y podrá satisfacer las expectativas en su organización
aplicando Scrum, y probablemente no ocurrirá nada catastrófico en el
proyecto con tu dedicación parcial. Sin embargo, si eres capaz de imaginar
un equipo que tiene una gran oportunidad para lograr cosas que nadie creía
posible, dentro de una organización transformada, deberías considerar que
no puedes ser solamente un Scrum Master adecuado, debes ser un Gran
ScrumMaster.

Y un gran ScrumMaster puede manejar un solo equipo a la vez.

Se recomienda un ScrumMaster dedicado por cada equipo de unos siete
siembros, sobre todo cuando el equipo está empezando con Scrum.

Si aún no has descubierto todo el trabajo que hay que hacer para el
desarrollo del proyecto y/o producto , sintoniza con el propietario del
producto, con tu equipo, con las prácticas de ingeniería, y con la organización
que está fuera del equipo.

Si bien no hay una receta única para todos, esta checklist describe las cosas
típicas que los ScrumMasters suelen pasar por alto.



Copyright
 ©
 2007-­‐2012
 Michael
 James.
 
 All
 Rights
 Reserved
 
Traducción
 autorizada
 2013
 -­‐
 José
 Vázquez
 Sánchez.
 

1
 

Checklist
 para
 Scrum
 Masters
 

 

Product Owner?.

Parte
 I
 -­‐
 ¿Cómo
 lo
 está
 haciendo
 el
 Product
 Owner?
 

Los Scrum Masters ayudan a mejorar el trabajo del Product Owner,
ayudándoles a encontrar maneras de mantener el Product Backlog y el
Release Plan. (Ten en cuenta que sólo el dueño del producto puede dar
prioridad a la los PBI ( Product Backlog Items) )

¨ ¿Está el Product Backlog priorizado de acuerdo con lo que transmite el

¨ ¿Estan los requisitos y deseos de todos los interesados capturados en el

¨ ¿Es el Product Backlog de un tamaño manejable? Para mantener un
número manejable de elementos, mantener las cosas con mayor detalle
en
inferior. Es
contraproducente sobreanalizar demasiado los PBI que estén en la parte
baja de
las
conversaciónes en curso entre desarrollo de productos y los actores /
clientes.

la Pila de Producto. Los requisitos cambiarán en

Product Backlog ? Recuerda: el backlog es emergente.

la parte superior,

las epicas en


¨ ¿Cumplen los requisitos (especialmente los que están cerca de la parte
superior de la Pila de Producto) la definición INVEST de las historias de
usuario?

la parte

con



Independiente, Negociable, de Valor, eStimable, pequeño ( Smart ) , y
Testeable?


¨ Has educado al dueño del producto sobre la deuda técnica y cómo
evitarla?. Una manera de afrontarla puede ser escribir pruebas
automatizadas y refactorizaciones para cada PBI que haya tenido
dificultades y se haya "parcheado" para evitar retrasos en la entrega.

accesible para todos los interesados?


¨ Es el Product Backlog un radiador información, claramente visible y

¨ Si estás utilizando una herramienta automatizada para la gestión del
Backlog, sabe el PO cómo usarla fácilmente?.Las herramientas de
gestión automatizadas
el peligro de convertirse en
refrigeradores información sin la irradiación activa del ScrumMaster.

introducen


¨ ¿Puedes ayudar a irradiar información, mostrando las impresiones y

opiniones sobre el Backlog de todos los interesados?

Copyright
 ©
 2007-­‐2012
 Michael
 James.
 
 All
 Rights
 Reserved
 
Traducción
 autorizada
 2013
 -­‐
 José
 Vázquez
 Sánchez.
 

2
 



o diagramas gráficos para para transmitir la visión

Checklist
 para
 Scrum
 Masters
 

¨ ¿Puedes ayudar a irradiar la información mediante la creación esquemas

¨ ¿Has ayudado al Product Owner a organizar los elementos del backlog

¨ ¿ Ayudas al Product Owner en el Grooming del Product Backlog y
facilitas la sesión con todo el equipo para sanear el Backlog y prepararlo
de cara al siguiente Sprint?.

en releases o categorizaciones en base a temas?.


¨ ¿Te aseguras que todas las historias están correctamente preparadas
para el Siguiente Sprint y no hay ambiguedades en la definición que
puedan retrasar la descomposición en tareas durante el Sprint Planning?

¨ ¿Conoce todo el mundo el plan de liberación y este sigue coincidiendo
con la realidad?. Debes tratar de mostrar a todos los Gráficos Burndown
de la release y mantenerlo actualizaados después de que los PBI han
sido reconocidos como "Done" en cada reunión de revisión de Sprint. Los
gráficos que muestran tanto la tasa de PBIs realmente obtenidos como
los nuevos añadidos, permiten el descubrimiento temprano de cambios de
alcance durante el Sprint.


¨ ¿El Product Owner ajusta el plan de Releases después de la última
reunión de revisión Sprint?. La mayoría de Product Owners que entregan
sus productos a tiempo y suficientemente probados tienen la buena
costumbre de volver a planear cada Sprint. Esto probablemente requiere
diferir un poco de trabajo para futuras versiones, pero permite que el
trabajo más importante sea descubierto antes de comenzar el siguiente
Sprint.



Copyright
 ©
 2007-­‐2012
 Michael
 James.
 
 All
 Rights
 Reserved
 
Traducción
 autorizada
 2013
 -­‐
 José
 Vázquez
 Sánchez.
 

3
 

Checklist
 para
 Scrum
 Masters
 

 

Parte
 II
 -­‐
 ¿Cómo
 lo
 está
 haciendo
 el
 equipo?
 

Aunque al Scrum Master se le anima a trabajar fomentando la colaboración
con los miembros del equipo, existe el riesgo de que éstos se pierdan en las
tareas técnicas. Ten en cuenta tus principales responsabilidades para con el
equipo:

¨ ¿Esta tu equipo en el estado de flujo? Algunas características de este


estado son :

• Objetivos claros (las expectativas y las reglas son discernibles y las
metas son alcanzables, alineadas apropiadamente con el conjunto de
habilidades y capacidades de los miembros del equipo).



• Concentración y enfoque: un alto grado de concentración por parte del

equipo limitado a un campo de atención concreto.

• Pérdida del sentimiento de auto-conciencia, la fusión de la acción y la

conciencia.

• Feedback directo e inmediato (los éxitos y los fracasos en el curso de
la actividad son evidentes, por lo que el comportamiento se puede
ajustar según sea necesario).

• Equilibrio entre el nivel de habilidad necesaria y el desafío que supone
conseguir los logros. (la actividad a realizar no es ni demasiado fácil ni
demasiado difícil).

• Un sentido de control personal sobre la situación o actividad a realizar.

• La actividad es intrínsecamente gratificante, así que tampoco es

excesivamente necesario motivar al equipo.

mejora?

los otros como suyo propio?


¨ ¿Los miembros del equipo parecen están alineados y celebrar el éxito de

¨ ¿Los miembros del equipo se sienten responsables, y tienen espíritu de

¨ ¿Existen problemas / oportunidades que el equipo no está discutiendo

¨ ¿Has probado una variedad de formatos y lugares para las reuniones de

porque están demasiado incómodos unos con otros?

Retrospectiva del Sprint?

Copyright
 ©
 2007-­‐2012
 Michael
 James.
 
 All
 Rights
 Reserved
 
Traducción
 autorizada
 2013
 -­‐
 José
 Vázquez
 Sánchez.
 

4
 

Checklist
 para
 Scrum
 Masters
 



¨ ¿El equipo mantuvo el enfoque en las metas del Sprint?. Tal vez
deberías llevar a cabo una revisión a mediados de Sprint para volver a
revisar los criterios de aceptación de los items del product Backlog
comprometidos para este Sprint.


¨ ¿El SprintBacklog refleja lo que el equipo está haciendo?. Cuidado con
la "materia oscura" de las tareas no reveladas y las tareas más grandes
que un día de trabajo. Las tareas no relacionadas con los compromisos de
Sprint son impedimentos para esos compromisos.


¨ ¿Tu equipo tiene entre 3-9 personas con una mezcla de las habilidades
suficientes para construir un incremento del producto potencialmente
entregable?

confortable con él?.


¨ ¿El tablero Scrum del equipo está actualizado y el equipo se siente

¨ Son los artefactos (Tablero de tareas, Sprint Burndown, lista de
impedimentos, etc) visibles para el equipo, y adecuados para el equipo a
producto que vas a desarrollar?


¨ ¿Están estos artefactos adecuadamente protegidos de entrometidos? El
exceso de control de la actividad diaria de la gente fuera del equipo puede
impedir la transparencia interna del equipo y la autogestión.


¨ ¿Los miembros del equipo se ofrecen voluntarios para las tareas?

¨ ¿Se ha hecho explícita la deuda técnica en lo