Todos los caminos llevan a Roma, pero con Scrum se llega antes.
Quien ha decidido dar el cambio y da los primeros pasos no lo tiene fácil al principio. Con mucho gusto compartimos nuestra experiencia para que Scrum también funcione en su empresa de forma más fácil y fluida. Con estos dos consejos, su retrospectiva y su Sprint Planning saldrán mejor.
1. Retrospectiva
Para llevar a cabo la retrospectiva, nos ha dado buen resultado el siguiente procedimiento: al comienzo del evento, cada miembro del equipo Scrum recibe pósits y un bolígrafo. En ellos se anotan todas las cosas percibidas como positivas y negativas durante el último sprint. A continuación, cada miembro presenta brevemente sus puntos y pega los pósits en una pizarra blanca. Cuando todos los miembros han expuesto sus puntos, los pósits se ordenan por temas; normalmente, ya por el número de pósits se ve qué tema debería tener la máxima prioridad. Es decir: cuantos más pósits haya sobre un tema, más importante es ese tema. Después se discute sistemáticamente cada tema, de la prioridad más alta a la más baja. Las propuestas de mejora se recogen por escrito y al menos una de ellas se incorpora directamente al siguiente sprint y se registra en el Sprint Backlog.
Las siguientes preguntas son estándar en Scrum:
- ¿Qué hemos hecho tan bien que tenemos que hablar de ello para no olvidarlo?
- ¿Qué hemos aprendido?
- ¿Qué tenemos que hacer de otra manera en el futuro?
- ¿Qué es lo que todavía no hemos entendido?
Si se quiere que la retrospectiva sea aún más fácil o más lúdica, hay innumerables posibilidades. Por ejemplo, el Scrum Master dibuja una estrella de mar en una pizarra blanca. Las preguntas se colocan en los brazos de la estrella y, a continuación, se clasifican los pósits según las preguntas.
- ¿Qué fue bien y qué debemos continuar?
- ¿Qué actividad debemos intensificar?
- ¿Qué actividad debemos reducir?
- ¿Qué nueva idea debemos adoptar de inmediato?
- ¿Qué fue menos bien y qué debemos dejar de hacer?
2. Sprint Planning
Para estimar historias, tareas y errores del Product Backlog durante el Sprint Planning, recomendamos lo siguiente para el Planning Poker. Utilice tareas ya estimadas como referencia para su estimación de los story points. Si se trata del primer sprint, podría tener sentido no hacer todavía ninguna estimación en él. En cambio, en el segundo sprint se podrían asignar story points a una historia del primer sprint. Esta puede utilizarse entonces como referencia para estimar las historias del segundo sprint.
Asegúrese de que la estimación de las tareas sea responsabilidad exclusiva del equipo de desarrollo. Ni el Product Owner ni el Scrum Master deben inmiscuirse en esta estimación. Si aun así lo hacen, puede ocurrir que algunas tareas no puedan completarse en un sprint, es decir, que se hayan subestimado.
La experiencia demuestra que siempre es mejor hacer una estimación conservadora que una optimista. Aunque las tareas parezcan analizadas con detalle, a menudo surgen imprevistos y dificultades que retrasan el desarrollo. Si en un sprint se acumulan muchas tareas subestimadas, el sprint degenera en estrés para los desarrolladores, lo que provoca errores y un trabajo poco limpio, o simplemente hace que las historias no puedan completarse.
kununu