Todos los caminos llevan a Roma, pero con Scrum se llega más rápido.
Quien ha decidido pasarse a Scrum y da los primeros pasos no lo tiene fácil al principio. Aquí le ofrecemos un poco de ayuda inicial 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 realizar la retrospectiva, nos ha dado buen resultado el siguiente procedimiento: al comienzo del evento, cada miembro del Scrum Team 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, solo por el número de pósits ya se ve qué tema debería tener la máxima prioridad. Así pues, rige lo siguiente: cuantos más pósits haya sobre un tema, más importante es ese tema. Después se discute cada tema de forma sistemática, 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 debemos hablar de ello para no olvidarlo?
- ¿Qué hemos aprendido?
- ¿Qué debemos hacer de otra manera en el futuro?
- ¿Qué es lo que todavía no hemos entendido?
Hay innumerables posibilidades de hacer la retrospectiva aún más sencilla. Por ejemplo, se pueden colocar las siguientes preguntas en una pizarra blanca. Todos los miembros del equipo pueden responderlas.
- ¿Qué ha ido bien y qué debemos continuar?
- ¿Qué actividad debemos intensificar?
- ¿Qué actividad debemos reducir?
- ¿Qué nueva idea debemos retomar de inmediato?
- ¿Qué ha ido 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 incidencias ya estimadas como referencia para su estimación de los Story Points. Si se trata del 1.er sprint, puede ser conveniente no hacer todavía ninguna estimación en él. A cambio, en el 2.º sprint se pueden asignar a una historia Story Points del 1.er sprint . Después, esta puede servir de referencia para estimar las historias del 2.º sprint.
Asegúrese de que la estimación de las incidencias sea responsabilidad exclusiva del equipo de desarrollo. Ni el Product Owner ni el Scrum Master deben inmiscuirse en esta estimación. Eso podría hacer que las incidencias de un sprint no puedan completarse por haber sido subestimadas.
La experiencia demuestra que siempre es mejor hacer una estimación conservadora y no demasiado optimista. Aunque las incidencias parezcan analizadas con detalle, a menudo surgen imprevistos y dificultades que retrasan el desarrollo. Si en un sprint se acumulan muchas incidencias 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.
¿Está todavía al principio y no entiende nada?
Ofrecemos formaciones en Scrum para facilitarle la iniciación en el tema.
kununu