Scrum-time.com
Sprint Planning Meeting

Sprint Planning Meeting


Una de las medidas más esenciales en la metodología Scrum es claro el Sprint Planning Meeting. En la medida dada toman parte el propietario del producto, el Scrum Master y todo el equipo de la elaboración. Aparece a veces la participación de las partes exteriores interesadas, sin embargo esto es raro.

Durante Sprint Planning Meeting Product Owner describe las tareas más prioritarias. El equipo en este momento hace bastantes preguntas para más exactamente estimar y distribuir las tareas, que se cumplirán durante el Sprint.

El propietario del producto no debe describir cada elemento del Product Backlog. Para el Product Owner el punto de referencia bueno será la llegada al Sprint Planning Meeting y la conversación sobre las tareas, que en la suma serán distribuidos a dos sprints. Si el equipo toma 5 tareas en el Sprint corriente , la conversación será sobre las 10 tareas top de todo Backlog.

Dos artefactos recibidos en Sprint Planning Meeting:

  • Sprint Goal;
  • Sprint Backlog.
Цель спринта в Sprint Planning Meeting

El objetivo del Sprint – son una o dos frasesformuladas que describen lo que el equipo va a alcanzar durante el Sprint. El equipo y el propietario del producto (juntos) describen el Sprint Goal.

La duración del Sprint Planning Meeting

La flexibilidad de la metodología Scrum está manifestada en todas partes, incluso en la duración del Sprint Planning Meeting. Esta duración depende de la duración del sprint futuro. La fórmula aquí es la siguiente – 1 semana del Sprint = 2 horas del Sprint Planning Meeting. Es decir para el sprint que dura 2 semanas, el Sprint Planning Meeting debe ser 4 horas.

El formato de la reunión

La reunión se devide condicionalmente en dos partes.

Первая часть в Sprint Planning Meeting

En la primera parte el Product Owner hace la revista de los elementos de Product Backlog, que hay que presentar y discutir en la reunión dada. El propietario del producto describe lo que él quiere ver. Se hacen aquí las preguntas y se discuten las tareas en el orden tal vez caótico, puesto que habiendo discutido una tarea, más tarde puede ocurrir una pregunta definidor más. En realidad el objetivo de tales especificaciones es la eliminación de cualquier ambigüedad.

A finales de la primera parte se forma el Objetivo del sprint / Sprint Goal.

Список в Sprint Planning Meeting

En la segunda parte el equipo forma ya el Sprint Backlog, donde las tareas se estiman en las horas. En la etapa dada la intervención del Product Owner es inadmisible. En realidad el Propietario del producto debe encontrarse en la zona del alcance y el equipo puede atraerlo, pero él no debe estar en la habitación donde va la discusión. A veces de verdad hay unos casos cuando él asiste, pero entonces el Scrum Master debe asumir la responsabilidad por la creación de la atmósfera tranquila para el trabajo del equipo. El Product Owner no siempre puede comprender algunos procesos profundos y durante la discusión donde el equipo decide si hacerlo así o no, el Propietario del producto puede causar el pánico.

Ejemplo

Como un ejemplo mostraremos como siempre las tareas de la creación de la tienda de Internet.

Necesitamos: realizar las funcionalidades básicas de la cesta de compras, incluso la adición, la eliminación y el cambio.

La elaboración del proceso de control: pagar el encargo, tomar la carga, el encargo del papel de regalo etc.

En general el objetivo del sprint sirve como un punto del informe para «los participantes exteriores». Prácticamente en cualquier proyecto hay unas personas interesadas que desean saber cómo trabaja el equipo pero que no necesitan (y además esto no está permitido) ir a la profundidad del trabajo del equipo y estimar cada tarea, y uno u otro paso hecho del Scrum Team. El Sprint Goal aquí es un ejemplo perfecto de tal "medía". Todo es muy simple, el objetivo está alcanzado o no, y no si los elementos están hechos o no están hechos.

El segundo artefacto es el Backlog del sprint, que es la lista de trabajo para la realización en el sprint.

lo importante es que el equipo debe decidir cuánto trabajo puede cumplir. Es inadmisible el planteamiento de las tareas así: el trabajo es para 4 sprints, así que en el primer sprint el equipo debe cumplir 25 % de todas las tareas.

Product Owner

Product Owner

Sprint

Sprint

Product Backlog

Product Backlog

Scrum Team

Scrum Team
Project Manegement
Project Manegement

Tiempo Scrum Time

keyboard_arrow_up