Scrum Master Certified Expert - Smce

Scrum Master Certified Expert - SMCE

Estimación, Planificación Y Seguimiento en Un Contexto Ágil

Ciclo de vida Agile Scrum Recolección de requisitos

Planificación de Sprint

Construcción del Sprint

Revisión y retrospectiva del sprint

Historias de usuario ¿Qué es una historia de usuario? ►

Son utilizadas en los métodos ágiles para la

Ayuda y asesora

especificación de requisitos ►

►

al Product Owner a encontrar nuevas técnicas de

Son una descripción breve de una funcionalidad tal y como la percibe el usuario Describen lo que el cliente o el usuario quiere que se implemente y se escriben con una o dos frases utilizando el lenguaje común del usuario

estimación y priorización Scrum Master

Ventajas que aportan las historias de usuario Al ser muy cortas, representan requisitos del modelo de negocio que pueden implementarse rápidamente días o semanas

Permiten dividir los proyectos en pequeñas entregas.

Necesitan poco mantenimiento.

Permiten estimar fácilmente el esfuerzo de desarrollo.

Mantienen una relación cercana con el cliente.

Son ideales para proyectos con requisitos volátiles o no muy claros.

Épicas ✓ Es una súper historia de usuario que se distingue por su gran tamaño ✓ Tienen una alta

granularidad ✓ El equipo la descompone en

historias de usuario con un tamaño más adecuado para ser gestionadas

Información en una historia de usuario

Es preferible no adoptar formatos rígidos Los resultados de scrum y agilidad no dependen de las formas, sino de la adaptación de sus principios

Recomendación de atributos

ID: identificador de la historia de usuario, único para la funcionalidad o trabajo

Descripción: descripción sintetizada de la historia de usuario.

Estimación: Esfuerzo necesario en tiempo ideal de implementación de la historia de usuario. story points

Prioridad: permite determinar el orden en el que las historias de usuario deben de ser implementadas

Descripción: Debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Como [rol del usuario], quiero [objetivo], para poder Ejemplo: Como usuario registrado quiero poner artículos en el carrito de compras para armar mi pedido

Criterios de aceptación Los criterios de aceptación ayudan al equipo de desarrollo a entender el funcionamiento del producto, de manera que estimarán mejor el tamaño de la historia de usuario.

Existen diversos métodos para medir la calidad de los criterios de aceptación.

SMART

Uno de ellos es el método en el que se han de cumplir en lo máximo posible los siguientes criterios:

S M A R T

Specific (Específicos) Measurable (Medibles) Achievable (Alcanzables) Relevant (Relevantes) Time-boxed (Limitados en el tiempo)

Calidad en las historias de usuario Para asegurar la calidad en la escritura de historias de usuario se sugiere el método INVEST El método sirve para comprobar la calidad de una historia de usuario revisando que cumpla una serie de características: • I-

Independent (independiente): debe ser autónomo

• N - Negotiable (negociable): puede ser cambiado o reescrito • V - Valuable (valiosa): entregar valor al usuario final. • E - Estimable (estimable): siempre se puede estimar

• S - Small (pequeña): no debe ser tan grande que sea imposible planificar o priorizar con un nivel de certeza • T - Testable (comprobable): debe ser medible con un resultado esperado conocido

Priorización de historias de usuario Los items del backlog de producto, deben guardar un orden de prioridad, cuya base se apoye en: ✓ Beneficios de implementar una funcionalidad ✓ Pérdida o costo que demande posponer la implementación de una funcionalidad ✓ Riesgos de implementarla ✓ Coherencia con los intereses del negocio ✓ Valor diferencial con respecto a productos de la competencia.

Asegura que el Dueño de Producto conozca cómo ordenar la Lista de Producto para

maximizar el valor Scrum Master

Técnica MoSCoW para priorización del Product Backlog

M - MUST HAVE

(es necesario): se debe tener la funcionalidad implementada en la solución, sino esta fallará o la solución no puede ser considerada un éxito.

(es recomendable): se debería tener la funcionalidad implementada en la solución ya S - SHOULD HAVE que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no existe pero debería de haber causas justificadas para no implementarla

C - COULD HAVE

(podría implementarse): es deseable, por tanto sería conveniente tener esta funcionalidad implementada en la solución, dependerá de las posibilidades de los tiempos y el presupuesto del proyecto.

W - WON'T HAVE

(no lo queremos): se trata de una funcionalidad de muy baja prioridad o descartada en ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando cobre importancia, puede pasar a alguno de los estados anteriores.

Estimación ágil utilizando planning poker

El punto historia o story point La medida que utilizamos es el punto historia o story point. Un punto historia es mezcla de:

El Scrum Master podrá ser quien actúa de

✓ Complejidad: Una historia que es más compleja que otra tendrá más puntos historia.

moderador

✓ Esfuerzo: Quizás una historia no tiene complejidad pero si requiere esfuerzo (ejemplo: Crear Web Services de integración para varias aplicaciones), también tendrá más puntos historia que otra más corta. ✓ Incertidumbre o riesgo: Es la probabilidad de que algo no esperado aparezca en la historia de usuario, siempre por falta de información previa.

del juego

Scrum Master

Estimación ágil utilizando planning poker La baraja de Scrum Poker, cuenta además con dos cartas adicionales: Una taza de café, que significa Haga os u a pausa Un signo de interrogación, que puede sig ifi a No estoy segu o del esfue zo ue de a da o ta ié No e te dí uy ie los e ue i ie tos .

Estimación ágil utilizando planning poker ✓ Baraja de cartas numeradas siguiendo la serie de Fibonacci. ✓ Serie de Fibonacci: Se compone de una serie lógica donde cada número es la suma de los dos anteriores:

A menor número, menor esfuerzo demanda una Historia de Usuario. Y cuanto más elevado es el valor, mayor esfuerzo. Fuente imagen: http://store.mountaingoatsoftware.com/products/planning-poker-cards

¿Cómo jugar? ✓ Cada integrante del Equipo posee en sus manos una baraja de cartas con los números correspondientes a la sucesión de Fibonacci ✓ El Product Owner presenta una historia de usuario para ser estimada.

El Scrum Master podrá ser quien actúa de

✓ Todos los participantes proceden a realizar su estimación en forma secreta, sin influenciar al resto del Equipo, poniendo su carta elegida boca abajo sobre la mesa.

moderador

✓ Una vez que todos los integrantes han estimado, se dan vuelta las cartas y se discuten principalmente los extremos.

del juego

✓ Al finalizar la discusión se levantan las cartas y se vuelve a estimar, esta vez con mayor información que la que se tenía previamente. ✓ Las rondas siguen hasta que se logra consenso en el Equipo y luego se continúa desde el punto número uno con una nueva historia de usuario

Scrum Master

Conceptos de tamaño y velocidad En dos o tresiteraciones(Sprint), se podrá estimar la velocidad del equipo y por lo tanto el tamaño y duración del proyecto.

La velocidad es la cantidad de story points que se completan por iteración

Velocidad del equipo La velocidad del equipo en Story Point o puntos historia. Por ejemplo: un equipo de 3 personas hace en promedio 52 Story Point en un Sprint de 4 semanas. Con esta velocidad el equipo puede tomar historias de usuario que sumen máximo 52 Story Point. Luego, se realiza el Tasking, aquí se define el número de horas por cada tarea a realizar de la Historia de Usuario, el número de horas debe ser par y una tarea no debe superar las 8 horas. Una vez realizado el Tasking se realiza el tiempo de dedicación del recurso humano. Ver ejemplo

Equipo de Desarrollo (Development Team)

Utilizando un tablero de tareas Los tableros de tareas favorecen la

Su objetivo principal es gestionar de manera general como se van completando tareas

comunicación

Se basa en un tablero dividido en columnas las cuales representan el estado por el que una tarea puede pasar

Consta de tres columnas: Pendiente, En progreso y Terminado

El Scrum Master facilita la gestión del tablero de tareas

directa del equipo al actualizar la información en reuniones frente a ellas además de compartir la visibilidad de la evolución del proyecto con todos los implicados

Utilizando un tablero de tareas La exposición de las tareas facilita la detección temprana de problemas al monitorizar continuamente la evolución del proyecto.

La actualización de la información just-in-time, ayuda a identificar en un primer momento los posibles impedimentos, problemas y riesgos.

Utilizando un tablero de tareas Columnas utilizadas ✓ Pendiente ✓ En Progreso ✓ Hecho Cada

columna

visualiza el estado de las actividades y las

filas representan los diferentes tipos

actividades

de

Monitoreo del Progreso

Monitoreo de progreso - Gráfico de producto(BurnUp) Es una herramienta de

planificación del propietario del producto, que muestra visualmente la evolución previsible del producto. Proyecta en el tiempo su construcción, con base a la velocidad del equipo (En el eje Y del gráfico se registra el tiempo medido en Sprints o en tiempo real y en el eje X el esfuerzo estimado para construir las diferentes historias de la lista de producto

Monitoreo de progreso (burndown Chart) La gráfica Burn Down representa el trabajo pendiente de realizar a lo largo del

velocidad

tiempo, es decir, la a la que se están completando los objetivos Lo actualiza el equipo en el scrum, para

avance

comprobar si el ritmo de es el previsto, o se puede ver comprometida la entrega del sprint. La estrategia ágil para el seguimiento del proyecto se basa en: Medir el trabajo que falta, no el realizado. Seguimiento cercano del avance

Monitoreo de progreso (burndown Chart) ✓Día a día cada miembro del equipo actualiza en la Lista de Pendientes del Sprint el tiempo que le queda a las tareas que va desarrollando, hasta que se terminan quedando a cero el tiempo pendiente. ✓Con esta información se actualiza el gráfico poniendo cada día el esfuerzo pendiente total de todas las tareas que aún no se han terminado (en el eje Y del gráfico se registra el trabajo que aún falta por realizar y en el eje X se detallan los días del Sprint)

¡Gracias!