¿Cuando una historia de usuario está "acabada acabada"?

Parece simple, pero en realidad no lo es tanto. ¿Cuando se puede decir que una historia de usuario está acabada realmente?

Primero vamos a comenzar con algunas definiciones.

• Acabado: 
• Hacer que algo llegue a su término.
• Historia de usuario: 
• Es una representación de un requerimiento de software escrito en una o dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de las discusiones con los usuarios y las pruebas de validación).
• Cada historia de usuario debe ser limitada, esta debería poderse escribir sobre una nota adhesiva pequeña. Dentro de la metodología XP las historias de usuario deben ser escritas por los clientes.

Entonces, ¿cuando podríamos decir que una historia de usuario está finalizada o acabada realmente? Como el término acabado es un tanto ambiguo, creo muy importante que cada equipo defina lo que para cada uno significa que una historia de usuario se pueda dar por finalizada dentro de un equipo.

He aquí algunos aspectos que pienso que se deberían tener en cuenta:

• Partes básicas que forman parte de las pruebas de validación.
• Pactar con el cliente las pruebas de validación de cada historia.
• Entorno se va a utilizar para pasar las pruebas de validación definidas por cada historia.
• Decidir quien es la persona/s que deciden cuando una historia se cierra. (Cliente, Equipo de Calidad, Producto Owner,...)
• Utilizar una herramienta de control de incidencias que permita mapear bugs con las historias afectadas.
• ...

Es un buen trabajo, que cada equipo lo que es para ellos el concepto de "historia acabada acabada" para evitar así que puedan darse malos entendidos.

Saludos,
JK

Why scrum can feel like a Overhead?

Scrum an agile development methodology framework, many people might not agree and would say its a methodology. As Uncle Bob has commented scrum is deliberately incomplete and can be adapted and makes it best fit for each team.

Then in this scenario can it be really a overhead??

There can be various reasons of why scrum can be felt as burden or a overhead, let´s jot jolt down some of them..

1) Scrum has been imposed on the people and they feel its more to control them than to make life easier. This kind of sensation can be noted when it was only management´s decision to implement scrum and no adequate process of adaptation was undertaken. This can make people think that scrum is overload, its bringing more responsibilities. But really speaking there is only 15mins daily and 3-4 hours bi-weekly. if you hear its a overload/ Overhead, one of the things you can be sure is team is manifesting that the decision is being pushed on them.

2) The case also can be that team doesn't like to follow processes or was not following any formal process of development. In these situations the sprint planning, the daily meetings and the important aspect of iterative delivery can be result like a overhead for the team.

Most probably results from previous development process were late delivery, not meeting user requirements and unmate commitments.

3) The most probable reason is the team only looks at the things they have to do and not what are the improvements/ benefits such as greater visibility into progress, closer contact with customers and users who can validate that the most-desired features are being built, closer coordination and greater communication with coworkers to ensure all team members are heading in the same direction, and so on....

4) The other possible reason can be that the scrum principles are not being followed correctly. The daily meeting are not limited to 3 answers and are being done for extended period of time. The planning meetings are uninformative and also extended period of time. The sprints and teams are not blinded. and so on...

5) Feeling of scrum overhead can also be existent if the team doesn't feel integrated. If there is non-existence of common projects or common Goals. This situation normally arises in the companies which are oriented towards services rather than products.

Said this a team can work its progress towards a scrumbutt most probally goes through one of these reasons. The most important part of implementation teams believing in scrum and understanding how it helps them to improve the work environment.

In my own experience Scrum is lightweight, the management is low and it gives more productive time and helps us in improving our focus on the planned work, reducing the deviations and raising the alarms in early stages.

Common sense is most important aspect of Scrum.

SCRUM metido con calzador

Imagen que resume la reunión de Sprint Plan del grupo:

15 minutos por Skype

En el grupo donde estoy de Scrum Master - rol que veo poco mediterraneolizable y en ese tema quizá entro algún día - se da la particularidad de que no estamos todos en la misma ubicación física, sino que estamos físicamente en dos sedes y a la practica en unos tres o cuatro oficinas. En este caso se planteó hacer la reunión diaria de manera telemática, y se selecciono Skype para hacer una sala de chat donde realizar la reunión. La primera decisión fue si lo hacíamos en chat de texto o en videoconferencia, pero dado que la conferencia - y no hablemos ya de la videoconferencia - con más de un interlocutor no acaba de funcionar de manera maravillosa (aún no sé porque tecnicismos), optamos por la magnifico, estupendo y tradicional mecanismo de chat en texto, almenos para comenzar.

Seria falso relatar las magnificas cualidades del chat de texto - carece de sentido - porque no hemos hecho ninguna reunión “de pie” en con el grupo, por lo que comentaré las cosas que me han llamado la atención de realizar las reuniones por chat:

1) Dado que las reuniones duran 15 minutos, es importante tenerlo escrito antes y pegar el resumen personal, ya que si hay que escribirlo en el mismo momento, cosa que alarga la reunión.

2) Hacen falta unas cuantas bastantes conversariones por skype para que las reuniones se hagan más cortas y el equipo sepa cuando se está alargando o no y que se hagan más eficientes.

3) Todo el mundo puede coger la batuta de la reunión, pero no es mala idea que cada persona pegue su resumen del día, espere unos momentos a ver si alguien quiere comentar alguna cosa y que pase el turno de palabra a un compañero que no haya dicho nada. Léase: paso de testigo.

4) Si hay que hacer algún comentario dirigido a una persona, puede ser interesante indicarlo de manera directa, p.e.

@roberto : este bloqueo es el mismo que el de ayer, no?

Así se facilita que no entren más personas en la conversión directamente.

5) La información que se escribe, se guarda en un log y luego puede ser interesante querer buscarla por algún motivo. Por ese motivo, añadir marcadores en el texto que se escribe, puede ayudar en un futuro a localizar cosas. Como ejemplo puedo añadir mi nombre de al principio

[juanp]

ayer: bla, bla, bla

hoy: bla, bla, bla

bloq: ninguno

Así, sé que buscando en los logs por [juanp] encontraré mis entradas.

6) Por el mismo motivo que (5) al comenzar la reunión es bueno poner una buena separación, porque Skype pone todos los logs juntos, dos buenas lineas de asteriscos pueden hacer correctamente su función.

Como el tema es curioso, he surfeado a ver si encontraba alguna cosa interesante. Sorpresa!
A Practical Guide to Distributed Scrum: Distributed Daily Scrum Meetings comenta pros i contras del chat de texto ; será interesante ver si en el futuro podemos ampliar o refinar este cuadro.

Pros	Cons
Whole team takes part in each day. Team can discuss blockers and remove them immediately. A transcript of the chat can easily become a set of notes for the meeting. May be easier for non-language speakers to write their thoughts instead of speaking.	The team loses both face-to-face and verbal communication. Unlike teleconference interaction, the Scrum Team cannot hear voice inflections. No guarantee the Scrum Team is paying attention to the chat session. Full accountability for the meeting occurring at the same time every day is fully on the ScrumMaster. Can be chaotic depending on how the team conducts the meeting.

Más visibilidad?

Después de haber cerrado las dos primeras semanas de aplicación de esta maravillosa metodología, creo que ya han surgiso una serie de situaciones y experiencias que podemos utilizar para ir mejorando nuestras tareas diarias con respecto al Scrum.

En la entrada de hoy únicamente quiero hablar del pasado y transmitir algo que ya hemos comentado y es que he echado en falta algo más de visibilidad durante el proceso de creación de los grupos y asignación de responsabilidades. Antes que nada quiero que quede claro que esto no es una crítica a nadie, simplemente unas impresiones personales que ójala nos ayuden a tod@s a mejorar. Este proceso que ya ha comenzado no encontrará resistencia por mi parte, es más, si hay que empujar.. se va a empujar con fuerza!! (espero que no tiremos a nadie..).

Durante este proceso de creación de grupos, hemos visto que se ha tenido en cuenta el perfil y conocimientos de cada persona, la tecnología y proyectos en realización, el estado de los mismos y las necesidades y prioridades para la empresa.

Por mi parte, realmente no esperaba estar dentro del grupo de P.O's, igual en algún grupo pero como apoyo, más que nada porque paso mucho tiempo fuera de la oficina y realmente el Scrum requiere de bastante contacto entre los integrantes del grupo (a Joan Carles esto le mola!!).

Tras la publicación de los grupos, la sorpresa fué generalizada y esto es normal, ya que es un tarea complicada y que seguramente necesita de una revisión contínua hasta encontrar una estructura estable, pero personalmente pienso que si se hubieran hecho unas breves entrevistas con los P.O's propuestos, seguramente nos hubiéramos ahorrado los cambios que se han realizado en éstas dos semanas y aquellos que están pendientes encima de la mesa.


Recalco que esta es mi opinión, entendiendo la problemática que existía, urgencia y que esta tarea no era sencilla, por eso para mí está claro que cuánto más gente y más información se hubiera tenido en este proceso, pues mejor hubiera sido el resultado.

Aparte de la información de la que dispone la empresa sobre las personas que la integran y que está reflejada en nuestros CV y aquella que más o menos es conocida, estoy totalmente seguro de que cada uno de nosotros disponemos de información privilegiada sobre las capacidades de los miembros de nuestros equipos.

Aquí queda la reflexión, me gustaría conocer vuestro punto de vista aunque me da a mí que no se va a alejar mucho del mío.. De momento lo dejamos aquí aunque también hay otras cosas que ya hemos visto y que tenemos que mejorar entre todos, como adelanto:

• Algo más de formalismo en la realización de las tareas, normalizandolas para todos los grupos.
• Establecimiento y disponibilidad de herramientas de trabajo (Wiki, Plantillas excell, ..)
• JIRA. Lo pongo aparte por la importancia de establecer el circuito base y sus configuraciones a utilizar por todos los proyectos.
• Mecanismos para equipos formados por personas en diferentes ubicaciones.
  

Ready, steady.... go!

En esta semana hemos afrontado nuestro primer reto: el lanzamiento del primer sprint.

Los PO somos los encargados de recoger y priorizar las diferentes historias que forman el product backlog del sprint del equipo. Esta tarea, a priori sencilla, requiere un poco más de esfuerzo cuando un equipo se responsabiliza de más de un proyecto y cada uno con un interlocutor de cliente diferente.

Hemos enfocado esta situación haciendo que dichos interlocutores (externos al equipo) asuman el rol de clientes y sean invitados a la reunión de planificación de sprint. Los PO de los equipos han recogido sus historias en el product backlog y conjuntamente han definido las prioridades. En los casos en que no han podido asistir a la reunión de planificación, los PO se han encargado de reunirse con estos clientes y recoger previamente sus historias y priorizaciones.

En algunos casos se ha detectado, tras el cierre de la planificación del sprint, que hay historias que podrían o deberían haber entrado pero que los PO no han recogido los backlogs y que se han quedado fuera. Se ha decidido que dichas tareas pasen a la planificación del siguiente sprint.


Este es uno de los puntos en los que debemos ezforzarnos en mejorar. Supone un cambio en la manera de planificar el trabajo del equipo: pasamos de planificar a una semana vista (generalmente) a "congelar" 2 semanas de trabajo (lo que hemos definido para los sprints).

Otro punto que hemos detectado al revisar la planificación es que prácticamente sólo hemos recogido el backlog para la duración del sprint. En el caso en que sea necesario incluir más historias en el sprint tendremos que gestionar cómo lo haremos.

Primeros pasos

Bueno, ahora ya va en serio, hemos comenzado la aventura ágil.

Después de que Angel Medinilla viniera a impartir una sesión de evangelización sobre agile, de que algunos de nosotros fuéramos a cursos de formación sobre Scrum, de realizar algunas sesiones de divulgación interna,de crear el primer equipo Scrum y de lanzar un pilotaje con un proyecto, de definir los equipos de toda la organización, de ubicar a los diferentes equipos y bautizarlos (proceso más complejo de lo que parece), etc.. se ha decidido lanzar Scrum a toda la organización.

Esta imagen refleja bajo mi punto de vista, bastante bien la situación actual. Todo el mundo tiene muchas preguntas y dudas. Para algunas vamos encontrando respuestas que nos convencen a todos, para otras convencen a algunos y para otras aún estamos buscando respuestas.

Buenos, expliquemos entonces algunos temas básicos de como nos estamos organizando. Nuestros equipos, están formados entre 6 y 10 personas,en los que cada están incluidos entre 1 y 2 Product Owner (PO) y entre 1 o 2 Scrum Masters (SM).

Se decidió que los responsables de proyecto asumieran el rol de PO interno y que el equipo de especialistas (seniors técnicos) asumieran el rol de SM. Esta decisión, que en un principio pareció acertada, ahora se está revisando y la semana que viene tenemos varios reuniones de feedback porque han aparecido algunas dudas sobre el tema de roles y responsabilidades.

A la hora de distribuir nuestros equipos entre los diferentes proyectos que hay en marcha, se ha decidido asignar PO y SM a equipos completos, a excepción de un compañero que es PO de dos equipos.

El hecho de asignar PO y SM a equipos a tiempo completo y a que partimos de una situación en la que hay proyectos en las que los componentes del equipo de proyecto antiguo, en algunos casos, están divididos entre varios equipos Scrum, está provocando algunos retos interesantes, como los que os cuento a continuación:

• ¿Qué hacemos cuando un proyecto está dividido entre varios equipos?
• Hemos decidido que se el equipo donde se encuentra el PO del proyecto, sea el responsable de este proyecto.
• ¿Quién establece la prioridad de las tareas de un proyecto cuyo PO es de otro equipo?
• Hemos pensado que sería muy recomendable que el PO del proyecto, se coordine con el PO del equipo que planifica el sprint para acordar la prioridad de estas tareas.
• ¿Quién debe asistir a las reuniones de Scrum Diario?
• Hemos creído conveniente, para algunos proyectos críticos repartidos entre varios equipos, los PO y SM asistan a las sesiones de Scrum.
• ¿Quien informa del grado de avance y situación de estos proyectos?
• Hemos creído conveniente que esta comunicación se realice por parte del PO del proyecto

También durante esta primera etapa, hacemos la reunión diaria de Scrum de Scrums, en las que asisten un PO o SM de cada equipo en la que se trata de:

• Un resumen de las tareas realizadas por el equipo.
• Un resumen de las tareas previstas.
• Explicación de los bloqueos detectados.

Estas sesiones están siendo muy útiles, ya que:

• han conseguido en muy poco tiempo dar mucha visibilidad sobre la situación de cada proyecto, tema que anteriormente era mucha más complicado.
• se han detectado bloqueos que han podido resolverse gracias a la colaboración de todos.

Bueno, con esto creo que es suficiente por hoy. La semana que viene más.

Un saludo,

Juan C. Fernández