Buscar en Gazafatonario IT

domingo, mayo 12, 2013

Lista de Chequeo Scrum


Clic sobre la imagen para ampliar. Clic para [Descargar] la Lista de Chequeo Scrum
De las muchas listas de verificación que encontré, esta llenó mis expectativas. La lista original es de Henrik kniberg. La pueden encontrar en sueco y en otros idiomas en: www.crisp.se/scrum/checklist.
Esta es la traducción al español.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum, o para evaluar tu actual implementación de Scrum.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum, pero se aseguraron de que el propósito de la práctica Scrum se cumplió de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la Retrospectiva como una herramienta de discusión, no como una herramienta de evaluación.

¿Cómo la uso?

        Joe: “Para esta retrospectiva, les he traído una pequeña y útil lista de chequeo. ¿Hay algo de esto que no estamos haciendo?”.

        Lisa: "Hmmm, veamos. Bueno, ciertamente nos hace falta la Definición de Terminado y no estamos midiendo la Velocidad”.

        Joe: “Bueno, la 'Definición de Terminado' está listada bajo 'Scrum Esencial' ¡así que parece muy importante! La Velocidad está listada bajo 'Recomendado, pero no siempre necesario' así que eso puede esperar y empecemos con lo esencial.

        Lisa: “Mira, también nos hace falta ‘Entregar producto funcionando y probado cada 4 semanas o menos'. ¡Eso está listado bajo 'Lo Fundamental'! Tiene sentido, ¡porque Mercadeo siempre se está quejando de eso!”

        Joe: “Quizás un concepto como la 'Definición de Terminado' podría ayudarnos a tomar porciones más pequeñas por sprint y liberar funcionalidades más seguido.”

        Lisa: “Buena idea, intentémoslo.”

¿Cómo NO la uso?

        Gran Jefe: “Bien, equipo, hora de ver qué tanto cumplimos con Scrum. Llenemos esta lista de chequeo, por favor.”

        Joe: “Jefe, estoy feliz de reportar que estamos haciéndolo todo. Bueno, todo excepto los gráficos de trabajo pendiente del Sprint.”

        Gran Jefe: “¡Mal, mal equipo! Aquí dice que ustedes deberían estar haciendo estas... eh...  ¡cosas pendientes del sprint! ¡Las quiero ver!”

        Lisa: “Pero nosotros hacemos sprints de 2 semanas y casi siempre entregamos lo que nos comprometemos a hacer, y los usuarios están felices. Las gráficas de trabajo pendiente del sprint no agregarían valor en este escenario”.

        Gran Jefe: “Bueno, aquí dice que deberían hacerlo, así que no dejen que los encuentre haciendo trampa otra vez, ¡o llamaré a la policía Scrum!”

¿Es esta una lista de chequeo oficial?

No. La lista de chequeo refleja mi opinión personal y subjetiva acerca de lo que realmente importa en Scrum. He pasado años ayudando a compañías a empezar con Scrum y he conocido a cientos de otros practicantes, instructores y entrenadores; y he encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Descargar la lista de chequeo Scrum
Puedes descargar la lista en formato PDF aquí.

Más sobre esta lista de chequeo de Scrum

Para profundizar más en los conceptos de la lista, puedes leer este artículo:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

7 comentarios:

  1. ese ¡O llamaré a la policía Scrum! me hizo reír jajajajaja buen articulo

    ResponderBorrar
  2. Muchas gracias Lucho :)

    Estoy aplicando un modelo de madurez en la empresa en la que me encuentro... pero si bien, se ve como "evaluación" no permite permear al equipo la importancia de que uno mismo evalúe el proyecto desde una perspectiva de "miembro del equipo" el modelo de madurez lo evalúan los coaches, y aunque en mi caso lo platico con el equipo y les comento el "por qué" La mayoría se sienten "calificados" en vez de involucrados...

    Una lista en la que se establezca comunicación y cada uno vea desde su perspectiva los puntos fuertes o débiles compromete y motiva más al equipo.

    ResponderBorrar

  3. I visit each day a few websites and sites to read content, however this weblog gives quality based writing. outlook 365 login

    ResponderBorrar
  4. Buenas creo que tenéis una errata, el PO no participa en la daily.

    Un saludo

    ResponderBorrar
    Respuestas
    1. ¡Hola, muchas gracias por tu participación en el foro! Quizás te refieras al punto donde dice "PO participa al menos unas pocas veces por semana". Mira que este se encuentra bajo la sección "Recomendado pero no siempre necesario", para empezar. Es decir, puede estar o quizás no. En cualquier caso no se pierde nada con ensayar. La guía de Scrum es clara al decir que la reunión Diaria es una reunión del Equipo de Desarrollo, pero es posible que asistan otras personas como simples observadores. O, en el caso del PO, también como participante activo. De hecho, se usa que cada día, el Equipo de Desarrollo sea capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar en conjunto como un equipo autoorganizado para lograr el objetivo del Sprint y crear el Incremento anticipado durante el resto del Sprint. Y qué mejor momento para bindar esta explicación que al final de una reunión diaria, sin que esto sea considerado "seguimiento y control". Las posibilidades son muchas: sí, no, tal vez. Sí y solo observa, sí y participa como cualquier otro miembro del equipo Scrum. Con toda seguridad, una reunión Diaria efectiva minimizará la necesidad de otras reuniones, incluso las que se requieren con el PO. ¡Saludos!

      Borrar
  5. Hola Lucho! Siempre he considerado fundamental que el Product Owner sea una persona y no un equipo. Aunque hablen como "una sola voz". Me gustaría conocer tu opinión al respecto.

    Saludos

    ResponderBorrar
    Respuestas
    1. Anderson. todo está dentro de lo posible. La recomendación inicial es que sea una persona, no un comité. Sin embargo, otra cosa es el desarrollo de productos grandes. En ese escenario quizás sea necesaria la conformación de un "equipo de producto". Aunque sigue primando que al equipo de desarrollo le hable un único representante de aquel. Siempre es lo mejor. En aras de optimizar el tiempo y la efectividad de las reuniones. Muchas gracias por tu cuestionamiento. ¡Saludos!

      Borrar