
Spanish: 
la planeación ágil es una de las maneras
más sencillas actualmente y eficientes
para poder hacer la planeación de un
proyecto o de un sprint en este vídeo te
voy a platicar cómo llevar a cabo una
sesión de planning poker y vamos a ver
cómo esta técnica le permite a todo el
equipo llegar a un consenso al momento
de estimar una historia si es la primera
vez que nos vemos mi nombre es héctor y
he trabajado con equipos de scrum en
alemán y en estados unidos y en méxico y
la idea de este canal y estos vídeos es
platicarte lo que he visto que funciona
y lo que no funciona esperando que te
sea de utilidad para tu implementación
de scrum si este es un tema que te
apasiona o qué te interesa entonces
suscríbete al canal aquí debajo por
favor para que no te pierdas ninguno de
mis vídeos vamos a entrar de lleno al
tema del planning poker si tu equipo
está estimando en horas y todavía no
empieza a estimar en story points o en
puntos de historia entonces te voy a
dejar un vídeo aquí arriba en donde te
voy a enseñar cuáles son los pasos para
que tu equipo empieza a utilizar story
points y porque la técnica de utilizar
story point se ha vuelto tan popular y
funciona mucho mejor que las horas en
ese vídeo también vas a poder descargar

English: 
Agile planning is currently one of the simpler and more efficient ways
to plan a project or a Sprint. 
In this video
I'll tell you how to carry out a planning poker session and we'll see
how this technique allows the team to reach a consensus when
estimating a story. If this is the first
time we meet,  my name is Hector and
I've worked with scrum teams in
Germany, the United States and Mexico.
The idea of ​​this channel and these videos is to tell you what I've seen that works
and what doesn't work hoping this is useful for your implementation of
scrum. If this is a topic that you
are passionate about or you're interested in,
then subscribe to the channel below for
please so you don't miss any of
my videos. Let's fully into the
planning poker topic. If your team
is estimating in hours and hasn't yet started estimating in story points
then I'll leave a video here above where I'll
show you the steps so that your team starts using story
points and why this technique of using
story points has become so popular and
works much better than hours. In that video you will also be able to download

English: 
the necessary material or presentation
of power point basically so that you
give the talk to your team and start
using story points. Now let's go straight
to learn this technique called "planning poker". The first thing you need
to have a planning poker session
is a list of refined stories. This means
very clear requirements. Number 2,
you need cards with the Fibonacci
series: 1, 2, 3, 5, 8. If due to the situation we're living you're going to have
a remote planning session poker  I'm going to leave a list of
tools that will be useful for you here
below in the description. Most of
them are free and very easy to use. Remember that the idea or
main objective of this planning poker session is that the list of
requirements with which we enter the
meeting are perfectly estimated
with a number of story points each. The steps to carry out this
activity are very simple. In this
meeting,
let's remember the Scrum Master, the Development Team and the Product Owner
will be present. For the first step,
we need one of the members
to explain the first story. If necessary, you might have to add a

Spanish: 
el material necesario o la presentación
de power point básicamente para que le
des la charla a tu equipo y empiecen a
usar story point ahora sí vamos de lleno
a conocer esta técnica
planning poker lo primero que necesitas
para tener una sesión de planning poker
es una lista de historias refinadas es
decir requerimientos muy claros número 2
necesitas cartas con la serie de
fibonacci 1 2 3 58 si por la situación
que estamos viviendo vas a hacer tu
sesión de planning poker de manera
remota te voy a dejar una lista de
herramientas que te van a servir aquí
debajo en la descripción la mayoría de
ellas son gratuitas y son muy fáciles de
utilizar recordemos que la idea o el
objetivo principal de esta sesión de
planning poker es que la lista de los
requerimientos con las que entramos a la
reunión salgan perfectamente estimadas
con un número de story points cada una
los pasos para llevar a cabo esta
actividad son muy sencillos en esta
reunión
recordemos que va a estar el scrum
master el equipo de desarrollo y el
producto on air para el primer paso
necesitamos que uno de los integrantes
explica la primera historia si es
necesario tal vez tenga que agregar un

English: 
little context of why this story is taking place, what the value
of the business is, the criteria of
acceptance, etc. After that
explanation the whole team has to
have understood exactly what
the requirement is about, who and what it is for. Step number 2 consists of each
of the developers, in secret, to take the card that represents the number
of points according to the effort
you need to carry out this
story. All team members must maintain the
card facing down so no one can see what was the estimation
each one gave. It is super important that the team knows what the definition of
done is. Otherwise it will be very complicated to understand whether a story is finished or
not yet. If your team does not have
a definition of done, then I invite you to
enter this video that I am sharing here where you're going to see what
the importance of the definition of done is and why every team must have one.
Once the whole team has finished voting for their story points still having
the card facing down it's time to
pick it up and show it to the rest of the

Spanish: 
poco de contexto del por qué se está
haciendo la historia cuál es el valor
del negocio cuáles son los criterios de
aceptación etcétera después de esa
explicación todo el equipo tiene que
haber entendido exactamente de qué se
trata el requerimiento para quién es y
en qué consiste el paso número 2 es que
secreto cada uno de los desarrolladores
tome la carta que representa el número
de puntos de acuerdo al esfuerzo que se
necesita para llevar a cabo esta
historia todos los miembros del equipo
de desarrollo tienen que mantener la
carta viendo hacia abajo para que no
puedan ver cuál fue en la estimación que
dio cada uno es súper importante que el
equipo sepa lo que es la definición of
done si no es muy complicado entender en
dónde está terminada una historia y en
donde todavía no si tu equipo no tiene
una definición odón entonces te invito a
que entres a este vídeo que estoy
poniendo aquí en donde vas a ver cuál es
la importancia de la definición odón y
por qué todo equipo tiene que tener una
una vez que todo el equipo ha terminado
de votar por sus story point si tienen
la carta viendo hacia abajo es hora de
levantarla y demostrarle al resto del

English: 
team. The idea is that this exercise results in a healthy talk or discussion
for people to explain why they gave the story five points or
why another person, another developer,
gave it one point or why another one gave it three.
What's most common is that people who
voted for extreme values , meaning
the highest value and the lowest value,
discuss and present their arguments
about why  they voted or valued the story that way.  What did they see?
What were the risks they saw? What dependencies or unknown things did they see
for the work to be done and what
other factors or criteria they took into
account to evaluate the effort either very
high or very low. Ideally, after
the discussion, a consensus is reached and a value or a midpoint is defined that
will be the estimate agreed by the entire
team. Here a good practice that I
recommend is that if there's a divided decision and there are people or
developers who believe that the story is worth 5 and another part of the team
believes that the story is worth 3, they should always go for the higher value. Why do I
recommend this? Well, because there is a lot more to lose or much more at risk

Spanish: 
equipo la idea es que este ejercicio
detone una plática o una discusión sana
para que las personas platiquen porque
le dieron cinco puntos a la historia o
porque otra persona otro developer le
dio un punto o porque otro le dio tres
lo más común es que las personas que
votaron por los valores extremos es
decir el valor más alto y el valor menor
platiquen y expongan sus argumentos de
por qué votaron o por qué
la historia de esa manera que fue lo que
vieron qué riesgos vieron qué
dependencias que desconocidos vieron en
el trabajo que se tiene que hacer y qué
otros factores o criterios tomaron en
cuenta para evaluar el esfuerzo muy
grande o muy pequeño idealmente después
de la discusión se llega a un consenso y
se define un valor o un punto medio que
será la estimación acordada por todo el
equipo aquí una buena práctica que yo
recomiendo es que si tenemos una
decisión dividida y hay personas o
desarrolladores que creen que la
historia vale 5 y otra parte del equipo
cree que la historia vale 3 siempre hay
que irnos por el valor mayor porque
recomiendo esto bueno porque hay mucho
más que perder o hay mucho más en riesgo

Spanish: 
si se subestima una historia que en
realidad era de 5 puntos y nosotros le
dimos 3 a lo que se pierde si se estima
una historia en 5 puntos cuando en
realidad era de 3 al término de estos
sencillos pasos tendremos la historia
estimada y en común acuerdo' por todo el
equipo lo que sigue es ir haciendo
exactamente el mismo proceso con cada
una de las historias que queremos
refinar hasta terminar las historias que
planeamos refinar en esta sesión de
planning poker aquí debajo en la
descripción del vídeo te voy a dejar
links a todas las herramientas que yo he
utilizado y que me han funcionado
bastante bien si este vídeo te está
dando algo de valor te pido por favor
que me regales un like aquí debajo para
saber que este es contenido que te
interesa y que tengo que hacer más
vídeos como este antes de que te vayas
te invito a que veas este vídeo que es
mi favorito del canal este vídeo habla
sobre 77 mitos y malas prácticas de
scrum y estoy seguro que le va a servir
mucho a ti ya tu equipo muchas gracias
por su atención nos vemos en el próximo
vídeo

English: 
if we underestimate a story that was actually 5 points and we
gave 3 in relation to what's lost if we estimated a story in 5 points when it
was really 3. At the end of these simple steps we will have the story
esteemed and in common agreement 'by the whole team. What's next to do
is exactly the same process with each of the stories we want to
refine until we finish the stories that
we plan to refine in this planning
poker session. Down here, in the
video description I'll leave you
links to all the tools that I have
used and that have worked for me
pretty well. If this video is providing any value, I ask you to please
give me a like here below to know that you're interested in this content
and that I have to do more videos like this. Before you leave,
I invite you to see this video which is
my favorite of them all. This video talks
about 77 myths and bad practices of
scrum and I'm sure it will be very useful
for you and your team. 
Thank you very much for your attention! See you in the next
video.
