El equipo quería mejorar su forma de trabajar con Scrum. Tras aprender los fundamentos, identificaron herramientas útiles como Team Foundation Server. Construyeron el Product Backlog y la Definición de Hecho. Durante los Sprints planificaban usando TFS, se autoorganizaban y actualizaban el Sprint Backlog. Al finalizar, hacían la revisión y retrospectiva para mejorar continuamente.

2. jlsoria@plainconcepts.com
http://geeks.ms/blogs/jlsoria

4. http://bit.ly/AsvWvK

5. http://bit.ly/AsvWvK

6. Una historia de
superación
Érase una vez un equipo que quería mejorar su
forma de trabajar.
Conocían Scrum, pero no estaban seguros de
estar aprovechándolo al máximo.
Habían oído hablar de herramientas que
podían ser de ayuda, pero desconocían cómo
sacar todo el partido de ellas.

7. Afortunadamente, contaba
n con un buen Scrum
Master, dispuesto a
ayudar al equipo en su
afán de mejora
Lo primero que hizo el Scrum Master, fue
asegurarse de que todo el mundo conocía los
fundamentos de Scrum.

8. El Manifiesto Ágil – El alma de
Scrum
Estamos descubriendo formas mejores de desarrollar
software tanto por nuestra propia experiencia como
ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones sobre procesos y
herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación
contractual
Respuesta ante el cambio sobre seguir un plan

9. Scrum en esencia
Scrum es un framework empírico para el desarrollo de
productos complejos.
Se trabaja en iteraciones fijas de 2 a 4 semanas
llamadas Sprints, que se suceden hasta que se
completa el proyecto.
Los requisitos y peticiones de cambio se gestionan
usando una lista ordenada y priorizada llamada Product
Backlog.
El Product Backlog es gestionado por el Product
Owner, que colabora con los interesados y con el

10. Scrum en esencia (II)
El Scrum Master se asegura de que Scrum se
aprovecha al máximo, entrena al equipo y gestiona
problemas que surjan.
Los Equipos son auto-organizados y
multifuncionales, y se componen de 6±3 personas.
Al principio de cada Sprint, se lleva a cabo la Reunión
de Planificación de Sprint, en la que el equipo
pronostica la parte del Product Backlog que será
completada. El plan se refleja en el Sprint Backlog.

11. Scrum en esencia (III)
Para el final de cada Sprint, el Equipo intenta completar
un incremento de funcionalidad de
valor, potencialmente entregable, que se resume en el
objetivo del Sprint.
Una vez que se ha seleccionado un objetivo del Sprint, el
alcance, Equipo y duración se consideran fijos para ese
Sprint.
Todos los días durante el Sprint, el Equipo lleva a cabo la
reunión Daily Scrum, en la que se sincronizan los
esfuerzos, se comprueba el progreso, se sacan a la luz
impedimentos y se planifican los siguientes pasos.

12. Scrum en esencia (IV)
El estado del proyecto y de la iteración son conocidos en
todo momento. Las métricas esenciales son el trabajo
restante y la velocidad.

13. Scrum en esencia (V)
Al final de cada Sprint, el Equipo muestra el incremento
que ha sido completado en la Revisión de Sprint. El
Product Owner recopila todo el feedback a tener en
cuenta para Sprints futuros.
Después, el Equipo mantiene una reunión de
Retrospectiva para hablar de la marcha del Sprint e
identificar acciones de mejora.
Durante todo el proyecto, el Product Owner promueve el
“grooming” del Product Backlog, para introducir
cambios y reordenaciones según las necesidades de
negocio.

14. samgu@microsoft.com

15. Después, se plantearon qué tipo
de herramientas podrían ser
útiles para aplicar todas esos
conceptos y prácticas.
Tras mucho buscar, encontraron algo que podría cubrir
la mayoría de sus necesidades.

17. Construyendo el Product
Backlog
El Equipo Scrum quería aplicar cuanto antes los
conceptos y prácticas que acababan de conocer.
“Pero, antes de empezar, deberíamos asegurarnos de
que tenemos un buen Product Backlog”
Recuerda: sólo con los requisitos no es suficiente. Vas a
necesitar el orden y las estimaciones.

18. El Product Owner construyó el
backlog inicial, y pidió al Equipo
ayuda para las estimaciones.
Entonces tuvo mejor criterio
para tratar con la ordenación.
Empezaron a utilizar las características de gestión de
elementos de trabajo de Team Foundation Server.

19. Scrum Norris
Scrum Norris completa todo
el Product Backlog en cada
iteración.
Scrum Norris no estima. Él
sabe.
Scrum Norris gana al
Planning Poker

20. La Definición de Hecho
Una vez que el backlog inicial estaba listo, surgió una
pregunta… ¿cómo podremos saber si hemos terminado
de trabajar en un elemento en particular?
El Scrum Master se apresuró a responder: deberíais
preparar una Definición de Hecho, que resuma las
condiciones que se deben cumplir para que una
funcionalidad se considere lista para ser entregada.

21. El Equipo acordó una Definición
de Hecho, lo suficientemente
buena para garantizar que
entregarían valor al final de cada
Sprint.
A continuación la publicaron en Team Foundation
Server, para que todo el mundo pudiese consultarla
cuando fuese necesario.

22. Scrum Norris
Cuando Scrum Norris dice
“hecho”, es que está “hecho”.
Scrum Norris hace la
Integración Continua una vez
cada 5 años

23. El Objetivo del Sprint
“Hemos llegado a la Reunión de Planificación de
Sprint, y es el momento de pronosticar qué seremos
capaces de completar. Nos vendría muy bien tener
alguna pista….”
“Después, una vez que estemos a gusto con el
pronóstico realizado, lo resumiremos en el Objetivo del
Sprint, que servirá de guía durante la iteración.”

24. “Estaría muy bien tener una idea
de nuestro rendimiento en el
pasado, para poder hacer un
pronóstico en base a esa
información”
Enseguida se dieron cuenta de que esa información se
la iba a proporcionar TFS, sin mucho esfuerzo. Así que
hicieron el pronóstico, acordaron un Objetivo del Sprint y
lo reflejaron todo en TFS.

25. Scrum Norris
La velocidad de Scrum Norris
es de 50.000 puntos por
Sprint.

26. El Sprint Backlog
La segunda parte de la Reunión de Planificación de
Sprint fue dedicada a determinar cómo transformar los
elementos del Product Backlog pronosticados, en un
incremento de valor del producto.
El Equipo construyó un Sprint Backlog inicial, teniendo
presente que se trata sólo de una ayuda para guiar el
trabajo, y que, como tal, cambiaría y evolucionaría a lo
largo del Sprint.

27. “Comenzaremos diseñando el
trabajo, y descomponiendo las
tareas resultantes para que
tengan un tamaño manejable”
Como ya se habían familiarizado con la gestión de
elementos de trabajo en TFS, trabajar con el Sprint
Backlog no fue nada complicado.

28. Scrum Norris
Scrum Norris ya ha
implementado todo al
terminar la reunión de
planificación.
Scrum Norris no planifica. Él
ya sabe lo que hay que
hacer.

29. Durante el Sprint
El Equipo comenzó a auto-organizarse para trabajar en
los elementos pronosticados, sabiendo que el alcance
no sería alterado durante el Sprint. Los Daily Scrums se
sucedieron sin mayor problema.
El Sprint Backlog se actualizaba con regularidad, y las
gráficas de Burndown reflejaban el progreso hacia el
Objetivo del Sprint.
Mientras tanto, el Product Owner continuaba con el
“grooming” del resto del backlog, evolucionándolo para
que reflejase mejor las necesidades de negocio, y
pidiendo ayuda al Equipo cuando lo necesitaba.

30. Completando el trabajo
El Equipo era consciente de que cualquier característica
implementada, debía cumplir la Definición de
Hecho, para poder presentarla en la Revisión de Sprint.
Se trataba de un Equipo multifuncional, así que
consiguieron asumir casi todas las tareas que iban
apareciendo.
El Scrum Master se mantenía alerta para asegurarse de
que el Equipo trabajaba en un entorno adecuado, y de
que cualquier problema era gestionado antes de
convertirse en una amenaza para el Objetivo del Sprint.

31. Una vez más, el Equipo utilizó
sabiamente las herramientas
que tenían a su disposición
Visual Studio y Team Foundation Server están repletos
de características útiles para el Equipo durante el Sprint.

32. Scrum Norris
A Scrum Norris se le permite
llegar tarde a la reunión
diaria.
Scrum Norris sabe que un
burndown real necesita
napalm.
Scrum Norris puede hacer
Sprints de 6 meses.
Scrum Norris escribe primero
el código, y después el test.

33. Tratando con lo inesperado
Un día, durante el Sprint, el Equipo se encontró con
trabajo no planificado que debía ser realizado. Cuando
actualizaron el Sprint Backlog para reflejarlo, el Sprint
Burndown reveló que no iban a ser capaces de entregar
todo lo que habían pronosticado.
Inmediatamente, el Scrum Master y el Equipo se lo
comunicaron al Product Owner, para que pudieran
decidir qué hacer.

34. Decidieron cancelar las subidas
de sueldo al Equipo, y despedir
a alguien, para que aprendiesen
a tener más cuidado la próxima
vez.

35. El Product Owner y el Equipo
acordaron qué sacar del alcance
en el Sprint actual, e intentaron
aprender del error de cara al
futuro.

36. La entrega
Se llevó a cabo la Revisión del Sprint, para que los
interesados pudiesen ver qué había sido completado y
expresasen sus opiniones sobre ello.
Todo el mundo tuvo la oportunidad de dar feedback, el
cual se tuvo en cuenta para la evolución futura del
producto.

37. El Product Owner se sirvió del
Product Backlog y de la
velocidad, para proyectar
posibles fechas de entrega.
También recogió todo el
feedback para poder actualizar el
backlog.

38. Mejorando
Tras la Revisión del Sprint, el Equipo siguió con la
Retrospectiva, en la que trataron de resumir cómo había
ido el Sprint que estaba terminando, buscando
prácticas, herramientas, artefactos o cualquier elemento
susceptible de ser mejorado, reutilizado o descartado.

39. Tomaron nota de los resultados
de la Retrospectiva, y hablaron
de cómo aprovecharlos
Una vez más, utilizaron las herramientas que tenían a
mano para registrar y gestionar toda esta información.

40. Scrum Norris
Scrum Norris no hace
revisiones o retrospectivas.
No hay mejora posible para
el proceso de Scrum Norris.

41. Al final, estaban listos para
comenzar con el siguiente
Sprint, siguiendo con el empeño
de entregar valor.
Usando Visual Studio y Team
Foundation Server, habían
conseguido mejorar
sustancialmente la forma en la
que trabajaban.

42. http://bit.ly/aC5Lb2
http://bit.ly/hmgkRU
http://www.scrum.org/scrumguides/
http://bit.ly/dMsz01
http://bit.ly/xc3rPE
Madrid 12 de Marzo
Bilbao 19 de Marzo
Palma de Mallorca 7 de Mayo
Pamplona 4 de Junio
jlsoria@plainconcepts.com
http://geeks.ms/blogs/jlsoria