@Teban Gracias por la herramienta, le echaré un ojo. De momento estimamos las historias de usuario con la planificación de poker y usando días. Luego, ya sin poker, partimos en tareas y las ponemos en horas.

Respecto a la planificacion poker, consigues planificar, comprobar que realmente se han entendido las cosas, y ademas crear rituales dentro de un equipo que lo unen. Parece una chorrrada, pero en mi opinion esta serie de “rituales” fomentan las buenas relaciones entre los miembros del equipo (ademas que en poco tiempo vas a ver como ayudan a estimar)

Suerte jeje

Gracias por compartir.

Tengo claro lo de los pollos y los cerdos, de hecho comenté que allí estabamos dos que no deberíamos votar (propietario del producto y yo como invitado), pero ya sabes, nos dejamos llevar por la novedad de eso de jugar a las cartas. A la próxima, al menos yo, me negaré e iré sólo de observador.

Veo que todavía se nos escapan muchos detalles, en parte por falta de rigor, en parte por desconocimiento. Scrum se explica en cinco minutos, pero tiene muchos detalles que no sé si son Scrum estándar o se han añadido después, como lo de “puntos”, “planificación por poker”, “velocidad del equipo”, etc.

En cuanto a nuestra planificación, ayer la sorpresa fue agradable. Mi desesperanza fue principalmente porque una tarea de 1 hora prevista del primer día, debido a muchos problemas imprevistos, acabó llevando todo el día a uno de los desarrolladores. En un grupo de tres desarrolladores y un sprint de una semana, eso supone un retraso considerable. Sin embargo, el avance de ayer me ha dado nuevas esperanzas, ha ido más rápido de lo esperado y aunque no llegaremos al 100%, tampoco nos quedaremos al 50%.

Gracias por la invitación y se bueno.

1) Los “pollos” no hablan en las reuniones de otros equipos y mucho menos si se trata de votar. Sólo lo hacen los “cerdos” (que para eso están implicados).

2) No pasa nada (de momento) por no llegar a cumplir las estimaciones de un sprint porque son eso: estimaciones. Es un grave error intentar llegar a hacer más “pegándose el palizón” o “barriendo bajo la alfombra”. Lo que tenéis que ir averiguando es cuál es vuestra velocidad. A partir de ahí podréis ir mejorando, pero siempre de manera sostenible. Lo que te tocaría ahora, como ScrumMaster, sería ir avisando al dueño del producto de que no se va a poder entregar todo de lo que se habló en la reunión de planificación. Lo que sí le puedes asegurar es que lo que pueda estar estará “hecho-hecho”, es decir, no habrá que volver a trabajar sobre ello más adelante. Y además le podrás garantizar que estará siempre lo más importante para él, que para eso lo priorizó así en el backlog y luego el equipo habrá ido trabajando sobre las historias por orden de prioridad para el dueño del producto.

3) No te agobies por llevar varios proyectos a la vez, ten en cuenta que la mayoría del trabajo lo hacen ellos, tú, como ScrumMaster, “sólo” tienes que dedicarte a eliminar sus impedimentos.

Por último, quería aprovechar para invitaros al encuentro del próximo martes 26 de Agile Spain en Madrid.