UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.

TÉCNICAS DE ESTIMACIÓN Y MEDICIÓN DEL PRODUCT BACKLOG Y

SPRINT BACKLOG.
Marvin Osvaldo Barahona Ramírez
e-mail: marosvramirez@gmail.com
Edwin Enrique Dimas Valle
e-mail: edwinenriquedimas@gmail.com
Lorena Esmeralda López Guadrón
e-mail: lg.esme@hotmail.com
Andrés Enrique Orellana Martínez
e-mail: andres.aeom@gmail.com
Carlos Francisco Rivas Fuentes
e-mail: cfrivas2010@hotmail.com

RESUMEN: Este documento presenta una 2 OBJETIVOS

investigación bibliográfica detallada sobre las técnicas de
estimación y medición de la lista del producto y la lista de
pendientes del producto; las cuales son parte de una
metodología flexible y ágil de desarrollo de software
llamada Scrum. Se hace énfasis en las técnicas de
priorización de actividades, lineamientos que se
establecen en base al esfuerzo o puntos de historia, al
nivel de urgencia de cada tarea y a la búsqueda de la
satisfacción del cliente. Se abordan dos enfoques para
conocer la velocidad de desarrollo; primero, la estimación
por presentimiento, que únicamente toma en cuenta la
autovaloración del equipo mismo; y luego, se detalla con
un ejemplo el método de estimación de la velocidad por
medio de los puntos de historia. Finalmente, para ayudar
en el desarrollo de reuniones del equipo de trabajo, se
explica una práctica ágil de planeación de tareas llamada
Planning Póker.
PALABRAS CLAVE: Estimación, Lista de Pendientes
del Sprint, Lista del Producto, Medición.
1 INTRODUCCIÓN
El modo tradicional de desarrollo de proyectos se
queda corto a la hora de hacer que el trabajo de equipo
sea colaborativo, además de hacer estimaciones muchas
veces exageradas para evitar retrasos en la planeación.
Dentro del proceso Scrum, se deben considerar las
estimaciones hechas a la lista de especificaciones del
producto que serán modificadas continuamente en el
transcurso del proyecto. Cada Sprint significará un
cambio en la lista de especificaciones del producto: se
eliminarán, modificarán o agregarán los elementos de
dicha lista
Las técnicas para la planificación toman de
referencia las experiencias con proyectos anteriores de
los desarrolladores del equipo, de esta forma llegar a un
consenso común es más sencillo y se optimiza lo mejor
posible.
2.1 OBJETIVO GENERAL
Identificar el uso de las técnicas de estimación y
medición de la lista del producto y de la lista de
pendientes del Sprint, teniendo en cuenta sus
componentes, ventajas y desventajas.
2.2 OBJETIVOS ESPECÍFICOS
Exponer de forma clara y concisa las técnicas
investigadas, detallando las etapas en las que se aplica
cada técnica y quiénes intervienen.
Describir las diferentes técnicas aplicables en la
estimación y medición de la lista del producto y la lista de
pendientes del Sprint, para poder seleccionar cual es la
técnica adecuada en un contexto específico.
3 TÉCNICAS UTILIZADAS EN LA
PLANEACIÓN DEL SPRINT
En la estimación y planificación ágil, se considera
que el desarrollo de software no puede ser predicho ni
estimado en forma precisa y el primer paso hacia la
planificación es la aceptación de este concepto.
Durante cada reunión de planeación del Sprint, el
dueño del producto se asegura de tener una lista del
producto adecuada para presentarse a los demás
miembros del equipo. Esto incluye que cada elemento
(cada historia de usuario, US por sus siglas en inglés)
tenga definido:
• Un identificador
• Un nombre
• Estimación
• Prioridad
Cuando el dueño del producto crea un nuevo
elemento de la lista del producto, se dirige al equipo de
desarrollo, explica su significado y pide a al equipo de

1
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.
desarrolladores que realicen una estimación. Los
desarrolladores, tras discutirlo, acordaran una
estimación.
La estimación se puede realizar usando el
presentimiento de los desarrolladores o estimando los
“puntos de historia”, una forma de cuantificar el esfuerzo
necesario para realizar una US. [1]
El hecho que el dueño del producto agregue la
estimación al elemento se conoce como “aseo” o
“refinamiento” de la lista del producto, que también
incluye asignarles la prioridad a los elementos.
La prioridad es definida por el dueño del producto,
ya que es el encargado de identificar las necesidades de
información requeridas para el sistema; y puede
determinar, con ayuda del cliente, el orden en qué se
deben completar las US identificadas.
La prioridad de los elementos definirá que
elementos se considerarán primero para integrar la lista
de pendientes del Sprint, incluyendo en esta lista la
cantidad adecuada de elementos. La cantidad adecuada
se determina usando el presentimiento o calculando la
velocidad del equipo de desarrollo, en base a sus
desempeños anteriores.
Cuando se define la lista de pendientes del Sprint,
se debe estimar el tiempo que tomará cada actividad.
Esta estimación la realizan los miembros del equipo de
desarrollo, teniendo en cuenta los antecedentes del
equipo y la organización interna.
En conclusión, el proceso de una reunión de
planificación de Sprint se puede resumir en (incluyendo la
priorización y estimación inicial, que se debe realizar
antes de la reunión):
1. El dueño del producto, auxiliándose del equipo
de desarrollo, asigna una estimación inicial a
cada US en términos de puntos de historia.
2. El dueño del producto define la prioridad de cada
US identificada con ayuda del cliente.
3. Tomando en cuenta la prioridad y estimación de
las tareas, el equipo de desarrollo decide qué US
incluir en el próximo Sprint. (ya sea usando el
presentimiento o usando la velocidad del
equipo). Estos elementos seleccionados
formarán parte de la lista de pendientes del
Sprint.
4. La lista de pendientes del Sprint se debe
planificar con mayor detalle. A los elementos que
la integran, el equipo de desarrollo les estima un
tiempo ideal (usualmente utilizando Planning
Póker). Esto le sirve al equipo como un
parámetro para la medición del progreso durante
el Sprint.
2
4 ESTIMACIÓN DE LAS HISTORIAS
Esta estimación la hace el equipo de desarrollo y el
dueño del producto, y se logra respondiendo a la
pregunta:
Si un pequeño grupo de personas, encerradas todo
el día con suficientes recursos para poder trabajar,
trabajasen todo el día en esta tarea, ¿cuántos días se
tardarían en completar la tarea?
Los puntos de historia serán, entonces, calculados
en base a la respuesta a esta pregunta:
Puntos de historia = cantidad de personas * días
requeridos
Por ejemplo, si se requieren 4 personas encerradas
todo el día para completar una historia de usuario en 2
días, los puntos asignados a esa historia son 8.
La importancia de esta comparación es poder
comparar cada historia con las demás. No es correcto
afirmar que una historia con 8 puntos se realizará en 4
días si dos personas se dedican a eso. Lo correcto es
afirmar que una historia de 8 puntos se realizará en el
doble de recursos (ya sea tiempo, personas, etc.) que una
historia de 4 puntos. [2]
5 PRIORIZACIÓN DE LAS HISTORIAS
Una vez asignada la estimación inicial de cada
historia, es necesario ordenarlas. Este orden determinará
qué tareas se realizarán primero; se realiza un proceso de
priorización. [3]
Puntos a considerar antes de priorizar:
• Reconocer que no todo tiene la misma
importancia
• El valor es relativo y depende de cada usuario:
no solo se toma en cuenta la opinión del cliente
sino también la opinión de quienes serán los
usuarios finales.
5.1 TÉCNICA BUSINESS VALUE & STORY
POINTS
Técnica que propone priorizar las historias de
usuario basándose en la opinión de todos los implicados
en el proyecto: el dueño del producto, cliente y equipo de
desarrollo.
Se basa en dos atributos de las US: los puntos de
historia (como ya se explicó, cuantifican el esfuerzo
necesario para cada US) y el valor del negocio.
El valor de negocio es un valor numérico asignado a
cada US donde a mayor valor, mayor importancia tiene
para el cliente.
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.

La prioridad se determina como muestra la Ec.1. • Prioridad 1: Si es importante y urgente por lo

tanto debe realizarse inmediatamente.
PRIORIDAD = VALOR DE NEGOCIO/PUNTOS DE • Prioridad 2: Si es urgente pero no importante se
HISTORIA (1) delega.
• Prioridad 3: Si es importante pero no urgente se
5.2 TÉCNICA URGENTE agenda.
• Eliminar: cuando no es ni urgente ni importante
Similar a la técnica anterior, pero en lugar de utilizar no se lleva a cabo.
los puntos de historia se utiliza el concepto de urgencia.
Pasos:
Se toman valores de 1 a 5, donde 5 implica que la 1. Hacer una lista con todas las tareas pendientes.
funcionalidad debe cumplirse ya y 1 indica que no hay 2. Identificar en que cuadrante se encuentra cada
apuro en completarla. El valor de negocio sigue la misma ítem de la lista.
escala y se valoran de igual forma. 3. Tachar las actividades categorizadas con
‘eliminar’.
Una vez establecidos ambos valores en todas las 4. Revisar las prioridades.
US, se multiplican y el producto obtenido en cada una se 5. Agrupar tareas que tengan recursos similares
ubica según se indica en la tabla 1. según su prioridad.
6. Realizar las tareas de acuerdo a su prioridad.
Tabla 1

5 5 10 15 20 25 Al final del proceso, se colocan las tareas en una matriz

cómo la mostrada en la Fig. 1.
Valor de negocio

4 4 8 12 16 20

3 3 6 9 12 15

2 2 4 6 8 10

1 1 2 3 4 5

1 2 3 4 5 Figura 1. Matriz de Eisenhower

Urgencia
Las US de mayor prioridad son las que se
encuentren en la zona roja, luego las que se encuentran
en la zona naranja, luego las que se encuentran en la
amarilla y finalmente las que están en la zona verde.
5.3 MATRIZ DE EISENHOWER
Dwight David Eisenhower ideo esta técnica como
método de priorización en la toma de decisiones
basándose en dos ejes: urgencia e importancia.
Para determinar que es urgente y que importante es
necesario responder a las siguientes preguntas:
• ¿Qué pasaría si no lo hago ahora?, si la
respuesta es nada, significa que no es urgente.
• ¿Me acerca a mi objetivo? Si la respuesta es no,
quiere decir que no es importante.
Las prioridades de esta técnica son: Prioridad 1, 2,
3 o eliminar (x); y se determinan del siguiente modo:
5.4 KANO MODEL
Es una teoría de desarrollo de productos o servicios
y de satisfacción del cliente y usuario, desarrollada por el
profesor Noriaki Kano. Es utilizada para clasificar y
priorizar requisitos en función de lo que satisface al
usuario. Dividió las necesidades del cliente en cuatro
categorías:
 Calidad requerida (Must-be/Basic needs): atributos
considerados básicos, la falta de ellos se percibe
como mala calidad ya que se trata de características
imprescindibles, sin embargo, el cliente no las pedirá
explícitamente y es necesario tener la capacidad de
identificarlas.
 Calidad deseada (Performance): características que
el cliente pide de manera explícita. El cumplimiento
de ellas tiene el poder de aumentar la satisfacción del
cliente, su incumplimiento al contrario genera
insatisfacción.
 Calidad motivante (Delighter): atributos que el cliente
no esperaba encontrar y que le generan sorpresa y

3
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.
agrado; al ser “extras” su ausencia no le causa
insatisfacción. Son atributos totalmente
diferenciadores.
 Calidad indiferente (Indifferent): Atributos que no
afectan a la satisfacción del cliente, pues no afectan
en el rendimiento del producto o servicio.
Algunos autores agregan la Calidad inversa, estos
atributos por excesivos generan rechazo por parte del
cliente.
El modelo considera además dos cuestiones que
generan cambios en el modelo:
1. El impacto del tiempo: las necesidades de los
clientes son dinámicas y sus expectativas son
cambiantes por lo que una característica que en su
momento se consideró motivante puede pasar a ser
deseada y luego requerida con el paso del tiempo.
2. Las distintas percepciones de una misma
característica: un mismo atributo puede ser
categorizado de forma distinta por diferentes
personas, en cuyo caso es recomendable basar la
clasificación en los usuarios finales.
Lo anterior planteado se resume en un diagrama
como el mostrado en la Fig. 2.
Figura 2. Modelo de Kano
5.5 MoSCoW
Se originó a partir de la metodología DSDM
(Dynamic Software Development Method). Es una forma
sencilla para ordenar características o historias de
usuario en orden de prioridad.
4
MoSCoW representa:
‘Must have’ (Imprescindible): características que
deben estar presentes antes de que el producto sea
lanzado, pues se trata de atributos imprescindibles.
‘Should have’ (Debería tener): características que
no son imprescindibles para el lanzamiento, sin embargo,
se consideran muy importantes y tienen un gran valor
para el cliente.
‘Could have’ (Podría tener): características
agradables para el cliente y que no requieren demasiado
esfuerzo o coste. En caso de que los periodos de entrega
estén en riesgo deben ser las primeras características en
ser eliminadas.
‘Won’t have for now’ (Opcionales): características
que están excluidas del ámbito de la aplicación durante el
tiempo previsto pero que pueden incluirse en una fase
futura de desarrollo.
Con cada letra se representa el nivel de prioridad
con su consecuencia directa sobre el valor del producto.
5.6 WSJF (Weighted Shortest Job First)
Significa hacer el trabajo más pesado y más corto
primero, este método fue creado por Dean Leffingwell por
medio de SAFe (Scaled Agile Framework) y está basado
en principios económicos LEAN. El cual es un método
basado en cálculos.
Para conocer la prioridad de cada funcionalidad se
necesita del peso (WSJF) que proviene del costo de
demora (CD) y del esfuerzo que lleva completarla en
términos de duración (D). Se usará la Ec. 2.
WSJF = CD/D (2)
Luego se ordena la lista de mayor a menor y este es
el orden de prioridades en el que se debe trabajar. Si
existe empate se realiza primero la actividad de menor
duración.
Para determinar el costo de demora se deben
considerar 3 factores:
1. Valor de negocio: ¿Cuál es el valor relativo de
esta funcionalidad para el negocio?
2. Valor de criticidad de tiempo: ¿Existe un tiempo
fijo de entrega? ¿Cuán crítica es esta
funcionalidad?
3. Valor de reducción de riesgo/ oportunidad:
¿Evitamos una penalización si entregamos esta
funcionalidad? ¿Reduce algún riesgo si
invertimos en esta actividad y no en otra?
El costo de demora (CD) es la suma de estas tres
variables, cómo se muestra en la Ec. 3. Es importante
definir una escala uniforme de valores de medida por
ejemplo: secuencia de Fibonacci.
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.
CD = VALOR DE NEGOCIO + VALOR DE CRITICIDAD
DE TIEMPO + VALOR DE REDUCCIÓN DE
RIESGO/OPORTUNIDAD (3)
Para determinar el esfuerzo se suele usar el tiempo
ideal para cada lista del producto obtenido en la
realización del Planning póker.
5.7 OTROS MÉTODOS
5.7.1 BASADOS EN RIESGOS
Esta técnica requiere de un análisis de riesgos
previo a la priorización, luego se propone realizar las US
que involucren mayor riesgo primero.
5.7.2 PRIORIZACIÓN POR RETORNO DE INVERSIÓN
(ROI)
Este enfoque de priorización se realiza calculando
el beneficio económico que se obtendrá en función de la
inversión que se debería realizar.
El cálculo se realiza con la Ec. 4:
ROI = VALOR DE NEGOCIO/COSTO (4)
Donde:
Costo: es el esfuerzo necesario para la construcción
de una característica x del producto.
Valor de negocio: es el rédito económico obtenido
por su incorporación.
5.7.3 100-POINTS METHOD
Este método fue desarrollado por Dean Leffingwell y
Don Widrig en 2003. Se efectúa dando al cliente y a los
responsables del proyecto, 100 puntos que ellos pueden
utilizar para votar en las historias de usuario más
importantes, el objetivo es darle mayor peso a las US más
relevantes, es decir, a las que tienen mayor prioridad para
cada uno comparadas con las demás disponibles.
Una vez finalizado el proceso de votación se suman
los puntajes de cada US, la prioridad es determinada por
el puntaje total de cada una.
5.8 ¿QUÉ MÉTODO SE DEBE UTILIZAR
PARA PRIORIZAR LAS HISTORIAS?
La tarea de priorizar dependerá del criterio del
dueño del producto, ya que sobre él cae la
responsabilidad de comunicar los requerimientos del
cliente a los miembros del equipo de desarrollo.
Esto no significa que el dueño del producto no deba
estar abierto a opiniones. Debe escuchar la posición del
cliente respecto a qué desea para los siguientes avances.
Pero es el dueño del producto el que tiene la última
palabra sobre la priorización que dará a cada US.
5
Mientras más técnicas para priorizar el dueño del
producto conozca, más herramientas disponibles tendrá
para decidir cuál es la adecuada bajo las circunstancias
en las que se encuentre.
6 ESTIMACIÓN USANDO EL
PRESENTIMIENTO
Una vez se ordena la lista del producto, de acuerdo
a su prioridad, se debe seleccionar la cantidad de
historias de usuario que deben completarse en el
siguiente Sprint. Para ello, se introduce la primera técnica:
Usando el presentimiento. [4]
Cómo su nombre lo indica, esta técnica se basa en
cómo se siente el equipo de desarrollo para estimar
cuántas y qué historia de usuario se deben incluir en la
siguiente lista de pendientes de Sprint.
Durante la reunión de planeación del siguiente
Sprint, el equipo de desarrollo discute cada elemento de
la lista del producto para decidir si se incluye o no en el
siguiente Sprint. Esta discusión inicia desde el elemento
con mayor prioridad y se detiene hasta que un elemento
es decidido para quedar fuera de la lista de pendientes
del Sprint.
Esta técnica funciona mejor con equipos pequeños
y un Sprint corto, ya que el equipo completo puede
participar en la discusión y explicar su posición respecto
al trabajo inmediato a realizar. Funciona mejor en un
Sprint corto, ya que la estimación es más compleja a
medida que el tiempo del Sprint aumenta; es por ello que
para un Sprint corto es más probable que las metas
planteadas se apeguen al trabajo que es posible hacer.
Si bien el dueño del producto y el Scrum Master
pueden influenciar en las decisiones del equipo de
desarrollo, son estos los que tienen la última palabra
sobre el trabajo que realizarán en cada Sprint.
7 ESTIMACIÓN UTILIZANDO LA
VELOCIDAD DEL EQUIPO
Esta es la segunda técnica para estimar cuáles
historias de usuario se debe incluir en la lista de
pendientes del producto. Se basa en datos históricos del
equipo de desarrollo para determinar la cantidad
adecuada de elementos que integraran la meta del Sprint.
[5]
7.1 VELOCIDAD
Velocidad es la magnitud determinada por la
cantidad de trabajo realizada en un periodo de tiempo.
Velocidad en Scrum es la cantidad de trabajo realizada
por el equipo en un Sprint. Así por ejemplo, una velocidad
de 150 puntos indica que el equipo realiza 150 puntos de
trabajo en cada sprint.
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.
Al trabajar en implantaciones de Scrum avanzado,
que pueden realizar Sprints de diferentes duraciones, o
no siempre con el mismo número de miembros en el
equipo, la velocidad se expresa indicando la unidad de
tiempo y en su caso también si se refiere a la total del
equipo, o a la media por persona.
Así por ejemplo: “La velocidad media del equipo es
de 100 puntos por semana” o bien: “La velocidad media
de una persona del equipo es de 5 puntos por día.”
7.1.1 VELOCIDAD ESTIMADA
La velocidad estimada se refiere a la cantidad de
puntos de historia que se pueden realizar en un Sprint por
todo el equipo. En la sección 7.2 se describen dos
técnicas para realizar esta estimación.
7.1.2 VELOCIDAD REAL
La velocidad real se determina al final del Sprint, y
es la cantidad de puntos de historia que se completaron
realmente durante ese Sprint. No se contabilizan los
puntos de las historias que no se completaron, aun
cuando estas se hayan iniciado a trabajar.
La Fig. 3 y la Fig. 4 muestra un ejemplo de velocidad
estimada al principio de un Sprint y la velocidad real al
final de dicho Sprint. Cada rectángulo es una historia, y el
número interior es la estimación inicial de dicha historia.
Figura 3. Velocidad estimada
Figura 4. Velocidad real.
Nótese que la velocidad real está basada en las
estimaciones iniciales de cada historia. Cualquier
6
actualización a la estimación de la historia realizada
durante el Sprint es ignorada.
Se trata de una cifra muy aproximada. Pero aun así
es bastante útil, especialmente si lo comparamos con
“nada en absoluto”. Proporciona algunas verdades
crudas: “sean cuales sean las razones, aquí está la
diferencia aproximada entre cuánto pensábamos que
podríamos hacer y cuánto hicimos en realidad”.
7.2 ESTIMACIÓN DE LA VELOCIDAD
La estimación de la velocidad se puede realizar
utilizando dos técnicas: Estimar la velocidad basándose
en las velocidades de Sprints anteriores del equipo de
desarrollo, o estimando la velocidad utilizando el factor de
dedicación.
7.2.1 VELOCIDAD BASÁNDOSE DE VELOCIDADES
ANTERIORES.
Este método es simple: se usa la velocidad real del
Sprint anterior y lo asume como la velocidad del siguiente
Sprint.
Una variante mejorada es utilizar un promedio de las
velocidades de los Sprint anteriores del equipo para el
siguiente Sprint, evitando utilizar valores reales alejados
del promedio como estimaciones.
Esto solo es factible para equipos que ya han hecho
algunos Sprints (de forma que haya estadísticas
disponibles) y que harán el próximo Sprint más o menos
de la misma manera, con el mismo tamaño de equipo, las
mismas condiciones de trabajo, etc. Claro está que no
siempre es este el caso.
7.2.2 VELOCIDAD BASÁNDOSE EN EL FACTOR DE
CONCENTRACIÓN.
En el caso que los recursos y duración de los Sprints
cambien, se debe recurrir al uso del factor de
concentración. Antes de usar este factor, se debe conocer
la cantidad de recursos que se dispondrán en el siguiente
Sprint.
Digamos que estamos planificando un Sprint de 3
semanas (15 días laborables) con un equipo de 4
personas. Lisa estará de vacaciones 2 días. Dave sólo
estará disponible al 50% y estará un día de vacaciones.
Todo se resume en la Fig. 5.
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.

7.3 HACIENDO ESTIMACIONES USANDO

CÁLCULOS DE VELOCIDAD

Esta técnica consta de dos pasos:

• Decidir la velocidad estimada.

• Calcular cuántas historias se pueden añadir sin

sobrepasar la velocidad estimada.

Suponiendo que la velocidad estimada para el

Figura 5. Horas disponibles para el siguiente Sprint próximo Sprint es de 20 puntos de historia (decidido
mediante alguno de los dos métodos anteriores). Eso
Tenemos 50 días-hombre disponibles en este Sprint. significa que el equipo debe añadir historias al Sprint
Pero esta no es una estimación de la velocidad del hasta que sume aproximadamente 20. Se tiene la lista del
equipo. Un día-hombre ideal es un día perfectamente producto mostrada en la Fig. 6.
efectivo, sin distracciones, lo cual es raro. Lo que es más,
debemos tener en cuenta cosas como trabajo no
planificado que se añade al Sprint, gente que se pone
enferma, etc.

Así que nuestra velocidad estimada será sin duda

menor de 50. ¿Pero cuánto menor? Para esto usamos el
factor de concentración y la Ec. 5

VELOCIDAD ESTIMADA = DÍAS-HOMBRE

DISPONIBLES X FACTOR DE DEDICACIÓN (5)

El factor de concentración es una estimación de Figura 6. Lista del producto.

cómo de centrado va a estar el equipo. Un factor de
concentración bajo puede significar que el equipo espera
encontrar muchas distracciones e impedimentos o que
considera que sus propias estimaciones son optimistas.
El factor de concentración del equipo se calcula
usando la Ec. 6, Dónde se utilizan los datos históricos del
equipo.
FACTOR DE CONCENTRACIÓN = PUNTOS DE
HISTORIA / DIAS-HOMBRE DISPONIBLES (6)
La mejor manera de determinar un factor de
dedicación razonable es estudiar el último Sprint (o
incluso mejor, la media de los últimos Sprints).
En este caso, el equipo puede escoger las 4
historias más importantes hasta un total de 19 puntos de
historia, o las 5 historias más importantes hasta 24 puntos
de historia.
Digamos que escogen 4 historias, ya que se
aproximan más a los 20 puntos de historia. Siempre que
haya dudas, escoge añadir menos historias. Dado que
estas 4 historias suman 19 puntos, la velocidad estimada
final para este Sprint es de 19. El resultado se muestra en
la Fig. 7.

Digamos que en el último Sprint se completaron 18

puntos de historia utilizando un equipo de 3 personas
formado por Tom, Lisa y Sam trabajando las tres semanas
hasta un total de 45 días-hombre. Y ahora estamos
intentando calcular la velocidad del próximo Sprint. Para
complicar las cosas, un nuevo tipo, Dave, se une al
equipo para este Sprint. Teniendo en cuenta las
vacaciones y demás asuntos tenemos 50 días-hombre
ideales en este Sprint.
Figura 7. Historias a incluir en el próximo Sprint.
FACTOR DE CONCENTRACIÓN DEL ÚLTIMO SPRINT:
18 puntos de historia / 45 días hombre = 0.4

VELOCIDAD ESTIMADA DEL SPRINT:

50 días hombre * 40% = 20 puntos de historia.

7
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.
7.4 ADAPTANDO EL PLAN DE ENTREGAS
La realidad no se adaptará ella sola al plan, así que
tendremos que hacerlo al revés. Después de cada Sprint
comprobamos la velocidad real de este. Si la velocidad
real ha sido muy diferente de la estimada, revisamos la
velocidad estimada para próximos Sprints y actualizamos
el plan de entregas.
Si esto nos coloca en una situación problemática,
puede que el dueño del producto empiece a negociar con
el cliente o se dedique a averiguar cómo podemos reducir
el alcance sin romper el contrato. O quizás él y el equipo
encuentren una forma de aumentar la velocidad
eliminando algún impedimento severo que se haya
identificado durante el Sprint.
El dueño del producto podría llamar al cliente y
explicarle que se ha producido un retraso en la planeación
inicial del Sprint y que el plan se ha retrasado; por ende
algunas funcionalidades se deberán pasar para el
siguiente incremento.
Quizás no sean buenas noticias para el cliente, pero
al menos estamos siendo honestos y le estamos dando al
cliente opciones muy pronto: podemos entregar las
funcionalidades más importantes en fecha o entregarlo
todo pero tarde. Normalmente no suele ser una decisión
muy difícil.
7.5 ¿QUÉ TÉCNICA DE ESTIMACIÓN SE
DEBE USAR?
Se han mencionado tres técnicas: usando el
presentimiento, usando la velocidad del equipo basado en
las velocidades pasadas y usando la velocidad del equipo
basado en las horas-persona disponible.
Lo ideal no es elegir rígidamente una de estas
técnicas, se deben combinar:
• Se ve el factor de concentración y la velocidad
real del Sprint anterior.
• Se ve el total de recursos disponibles y se estima
el factor de concentración para el siguiente
Sprint.
• Se discuten las diferencias entre esos dos
factores y se discuten los cambios.
• Una vez que se tenga una lista preliminar de los
pendientes del Sprint, se utiliza el presentimiento
para comprobar la lista. Para ello, se debe
ignorar el número de historias incluidas y
concentrarse en la cantidad de trabajo a realizar.
• Si el presentimiento concluye que hay mucho
trabajo, se deben remover una historia o dos. Si
por el contrario, el trabajo es poco para un Sprint
se deben de agregar historias.
Al final, el objetivo es determinar que tareas de la
lista del producto se deben incluir en la lista de pendientes
8
del Sprint. Las técnicas solo son herramientas para lograr
este objetivo; deben simplificar el trabajo, no volverlo más
complejo de lo necesario.
Problemas de ocupar el factor de concentración:
 Realizarlo puede tomar mucho tiempo.
 El uso del factor de concentración puede dar una
falsa idea exactitud de la estimación.
 Da la sensación que mientras más
desarrolladores se tengan, más trabajo se
realizará.
 Medir la concentración puede darle al equipo el
falso mensaje que está “desconcentrado”.
Lo ideal es usar estas técnicas para los primeros
Sprint, si no se cuenta con alguna información histórica.
Resulta más exacto considerar cuántas historias (o
puntos de historia) se han realizado en promedio en el
pasado y la disponibilidad del equipo para el siguiente
Sprint, y en base a eso tomar la cantidad de historias que
el presentimiento dicte a tomar.
De esta forma, las reuniones de planeación del
Sprint resultan más rápidas y divertidas, y la estimación
puede llegar a ser más precisa que si se hubiera hecho
calculando la velocidad del equipo.
8 PUNTOS DE HISTORIA Y EL TIEMPO
IDEAL
Hasta ahora se ha considerado la estimación de las
historias de usuario mediante los puntos de historia.
Cómo ya se explicó, esto no se hace con el objetivo de
cuantificar la cantidad de tiempo que tomará la realización
de las historias (su fin es cuantificar relativamente las
historias para poder compararlas).
El tiempo ideal, en cambio, si es una medida del
tiempo que tomará realizar una historia. Para realizar esa
estimación, se deben tomar en cuenta algunos aspectos
que se ignoran cuando se cuentan los puntos de historia.
Mientras más información sea tomada en cuenta
mayor precisión tendrá la estimación del tiempo ideal. Ese
es justamente el objetivo de estimar el tiempo ideal, tener
la mayor precisión posible sobre cuánto tiempo debe el
equipo concentrarse en una tarea.
9 PLANNING POKER PARA LA
ESTIMACIÓN DEL TIEMPO IDEAL
Es una práctica ágil, para conducir las reuniones en
las que se estima el esfuerzo y la duración de tareas.
James Grenning ideó este juego de planificación para
evitar discusiones dilatadas que no terminan de dar
conclusiones concretas.
El modelo inicial de Grenning consta de 8 cartas,
con los siguientes valores: ½, 1, 2, 3, 5, 6, 7 e infinito. Las
mismas fueron desarrolladas para dar soporte a las
estimaciones de versión en Extreme Programming.
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.

El funcionamiento es muy simple: cada participante

dispone de un juego de cartas, y en la estimación de cada
tarea, todos vuelven boca arriba la combinación que
suma el esfuerzo estimado. [6]

Cuando se considera que éste es mayor de x horas

ideales (el tamaño máximo considerado por el equipo
para una tarea), se levanta la carta “infinito”. Las tareas
que exceden el tamaño máximo deben descomponerse
en subtareas de menor tamaño.

Cada equipo u organización puede utilizar un juego

de cartas con las numeraciones adecuadas a la unidad Figura 9. Ejemplo de Planning Póker.
de esfuerzo con la que trabajan, y el tamaño máximo de
tarea que se va a estimar.
9.2 VARIANTE: SUCESIÓN DE FIBONACCI
En la Fig. 8 se muestra un ejemplo de cartas
Basado en el hecho de que al aumentar el tamaño
utilizadas para el Planning Póker.
de las tareas aumenta también el margen de error, surgió
una variante que consiste en emplear números de la
sucesión de Fibonacci para realizar las estimaciones, de
forma que:

• El juego de cartas está compuesto por números

en sucesión de Fibonacci.

• La estimación no se realiza levantando varias

cartas para componer la cifra exacta, sino
poniendo boca arriba la carta con la cifra más
aproximada a la estimación.

Así, si por ejemplo una persona cree que el tamaño

Figura 8. Cartas usadas en el Planning Póker.
9.1 ¿A QUÉ SE DEBE EL ÉXITO DE ESTA
TÉCNICA DE PLANEACIÓN?
adecuado de una tarea es 6, se ve obligado a
reconsiderar y, o bien aceptar que parte de la
incertidumbre apreciada no es tal y levantar la carta de 5,
o bien aceptar una estimación más conservadora y
levantar el 8.

Los resultados positivos del Planning Póker se En particular, los números de esta variación del
derivan de la combinación del uso de opinión experta Planning Póquer son: 0, ½, 1, 2, 3, 5, 8, 13, 21, infinito;
(quien realiza la tarea, la estima), analogía (puesto que como se muestra en la figura 10.
un gran número de historias tienen similitud con el trabajo
desarrollado previamente por el equipo) y división del
esfuerzo de estimación (en historias de un tamaño
adecuado para evitar que la desviación sea elevada).

En las sesiones de Planning Póker debe jugar todo

el equipo de desarrollo, aunque determinadas historias no
afecten por igual a todos los integrantes del equipo será
necesaria la participación activa de todos. El otro role
necesario es el moderador que será el encargado de que
los participantes lleguen al consenso. El moderador suele
ser el dueño del producto.

En la Fig. 9 se muestra un ejemplo de reunión para
realizar el Planning Póker.
Figura 10. Cartas para la variante con serie de Fibonacci
Si se quiere emplear la planificación de póquer para
estimar requisitos a nivel de producto o de versión
(funcionalidades, temas) además de usarlo al nivel de
tareas de sprint, se pueden añadir cartas al juego para
permitir estimaciones de mayor tamaño (34, 55, 89, 144,
etc.).

9
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.
Es frecuente emplear una carta con un símbolo de
duda o interrogación para indicar que, por las razones que
sean, no se puede precisar una estimación. También es
posible incluir otra carta con alguna imagen alusiva, para
indicar que se necesita un descanso.
9.3 ¿CÓMO FUNCIONA?
• Cada participante de la reunión tiene un juego
de cartas.
• Para cada historia, el dueño del producto expone
la descripción empleando un tiempo máximo.
• Hay establecido otro tiempo para que el dueño
del producto atienda a las posibles preguntas del
equipo.
• Cada participante selecciona la carta, o cartas
que representan su estimación, y las separa del
resto, boca abajo.
• Cuando todos han hecho su selección, se
muestran boca arriba.
• Si la estimación resulta “infinito”, por sobrepasar
el límite máximo establecido, la tarea debe
dividirse en sub-tareas de menor tamaño.
• Si las estimaciones resultan muy dispares, quien
asume la responsabilidad de gestionar la
reunión, con su criterio de gestión, y basándose
en las características del proyecto, equipo,
reunión, cantidad de elementos pendientes de
evaluar, puede optar por:
o Preguntar a las personas de las
estimaciones extremas: ¿Por qué crees
que es necesario tanto tiempo?, y ¿por qué
crees que es necesario tan poco tiempo?
Tras escuchar las razones, repetir la
estimación.
o Dejar a un lado la estimación de esa tarea
y retomar al final o en otro momento
aquellas que hayan quedado pendientes.
o Pedir al cliente o propietario del producto
que descomponga la funcionalidad y
valorar cada una de las funcionalidades
resultantes.
o Tomar la estimación menor, mayor, o la
media.
• Si algún miembro del equipo saca la taza del
café es para pedir un descanso, la “?” se utiliza
para indicar que con la información disponible no
se tienen ni idea del esfuerzo a realizar y el 0
10
indica que el esfuerzo es mínimo, prácticamente
despreciable.
En la baraja estándar también está el símbolo de
infinito, para reflejar una historia de extensión
fuera de alcance (con los recursos actuales).
9.4 BENEFICIOS DEL PLANNING PÓKER.
El póker de planificación es una herramienta para la
estimación de los proyectos de desarrollo de software. Es
una técnica que minimiza el anclaje pidiendo a cada
miembro del equipo jugar su tarjeta de estimación de
manera tal que no puede ser visto por los demás
jugadores.
Después de que cada jugador ha seleccionado una
tarjeta, todas las tarjetas son expuestas a la vez. Un
estudio realizado por K. Molokken - Ostvold y NC Haugen
encontró que las estimaciones obtenidas mediante el
proceso de Planificación de póker son menos optimistas
y más precisa que las estimaciones obtenidas a través de
la combinación mecánica de las estimaciones
individuales en las mismas tareas.
9.5 ¿DE QUÉ MANERA SE EVITA EL
ANCLAJE UTILIZANDO EL PLANNING
PÓKER?
El anclaje se produce cuando un equipo discute
abiertamente sus estimaciones. Un equipo tiene
normalmente una mezcla de estimadores conservadores
e impulsivos y puede haber personas que tienen
agendas, es probable que los desarrolladores querrán
todo el tiempo que puedan para hacer el trabajo y el
propietario de un producto o cliente desea que lo realicen
tan rápido como sea posible.
La estimación se afianza cuando el propietario de un
producto dice algo como: "Creo que este es un trabajo
fácil, no puedo verlo tomando más tiempo que un par de
semanas", o cuando el promotor dice algo como: "Creo
que tenemos que tener mucho cuidado, el
esclarecimiento de los problemas que hemos tenido en la
parte trasera podría llevar meses”.
Quien inicia la conversación con la estimación, "creo
que es 50 días" inmediatamente tiene un impacto en el
pensamiento de los otros miembros del equipo, sus
estimaciones se han integrado, es decir, todos ellos
tienen ahora al menos una referencia subconsciente al
número 50 en sus propias estimaciones. Los que estaban
pensando en 100 días es probable que se reduzca y
aquellos que pensaban que 10 se pueden replantear.
Esto se convierte en un problema particular, si el 50 es
hablado por un influyente miembro del equipo.
Debido a que el resto del equipo se ha integrado
pueden conscientemente o no dejar de expresar su
estimación original, de hecho, incluso es posible descubrir
que están pensando lo mismo. Esto puede ser peligroso,
lo que estima que son influenciados por las agendas o las
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.
opiniones individuales que no se centran en conseguir el
trabajo bien hecho.
La Planificación de Póker expone el miembro del
equipo potencialmente influyentes como aislados en su
opinión entre el grupo. A continuación, las demandas que
él o ella argumentan que el caso en contra de la opinión
que prevalece. Si un grupo es capaz de expresar su
unidad de esta manera son más propensos a tener fe en
sus estimaciones originales. Si la persona influyente un
buen caso para discutir todo el mundo verá sentido y
seguir, pero por lo menos el resto del equipo no se han
integrado, sino que se han escuchado a la razón.
9.6 ¿CÓMO APLICAR DE FORMA
CORRECTA EL PLANNING PÓKER?
• Elegir un objetivo de tamaño típico en el
proyecto como patrón con el que comparar el
resto de objetivos y asignarle una puntuación de
carta también media.
• Puede ser conveniente no jugar con las cartas
más altas, ya que el error de estimación es
mucho mayor (además, objetivos tan grandes
dificultan ver el progreso y se tarda más en hacer
visible si existen problemas en el proyecto).
• Dada la dificultad de empezar a trabajar con
puntos de historia y no con esfuerzo en días
ideales, para facilitar el empezar a utilizar
Planning Póker se puede hacer el símil de que,
por ejemplo, dos puntos de historia
corresponden a un día ideal.
• Comparar el tamaño que se va dando a cada
objetivo respecto al de otros (triangulación).
9.7 ¿CUÁNDO SE DEBE REALIZAR UN
PLANNING PÓKER?
La mayoría de los equipos llevará a cabo una sesión
de planificación de Póker poco después de que la lista
inicial de producto este escrito. Este período de sesiones
(que puede extenderse durante varios días) y este se
utilizara para crear estimaciones iniciales útiles en
alcance o tamaño del proyecto.
Debido a que elementos de la lista del producto (por
lo general en forma de historias de usuario) seguirán
siendo añadidas a lo largo del proyecto, para la mayoría
de los equipos será útil llevar a cabo sesiones posteriores
de estimación y de planificación ágiles, esto al menos una
vez por iteración.
La alternativa que aquí se recomienda es realizar
estas reuniones como parte de la reunión de planeación
del Sprint, para estimar las tareas que se realizarán
durante el siguiente Sprint. Esto permite considerar las
historias inmediatamente antes de realizarlas, tomando
11
en cuenta los recursos con los que se cuentan
actualmente.
En la Fig. 10 se muestra una reunión de Planning
Póker.
Figura 10. Reunión de Planning Póker.
9.8 EJEMPLOS DE APLICACIÓN DEL
PLANNING POKER
• Ejemplo 1
Supóngase que un cliente solicita a su empresa la
creación de un software contable, como primer paso se
debe proceder a la reunión de planeación, en esta se
debe de encontrar el cliente junto con todo el equipo
asignado a la creación del software.
En dicha reunión, se deben establecer los
requerimientos del sistema contable, dados estos el
equipo debe decidir la técnica de estimación que utilizaran
para determinar el tiempo requerido para el proyecto.
Supondremos que se escogió utilizar la técnica de
Planning póker para realizar estas estimaciones, lo que
sigue es entregar una baraja a cada miembro del equipo
(cabe recalcar que estas deben ser específicas para el
desarrollo de esta técnica), teniendo todo preparado se
comienzan a listar los requerimientos antes establecidos
uno por uno y dejando un tiempo prudencial en el cual se
realizarán preguntas acerca de este y se darán las
votaciones.
Imaginemos que uno de los requerimientos del
sistema es que teniendo todos los asientos contables se
elaboren reportes financieros; luego de haber leído este
requisito del sistema cada uno de los miembros del
equipo debe de escoger una carta de entre la baraja y
colocarla boca abajo hasta que se diga que la muestren,
mientras unos lo harán rápidamente otros tendrán dudas
las cuales pueden expresar antes de dar su opinión.
Está de más decir que el tiempo que cada persona
estima será completamente diferente a lo que opina el
resto del equipo (En la mayoría de los casos), por
ejemplo, para el ingeniero de software puede ser una
tarea un poco compleja, la misma idea podría compartir
el analista de sistemas, por tal razón le dan una valoración
de 40 puntos de estimación, mientras que para el tester
UES. Barahona, Dimas, López, Rivas, Orellana. Técnicas de estimación y medición.
.

es una tarea sencilla valorándola con 13 puntos de de anclaje del grupo de planeación, lo cual mejora de gran
estimación, pero luego de un par de rondas se llegó al manera el tiempo de la toma de decisiones con respecto
acuerdo que este requerimiento solo tendrá 20 puntos de al desarrollo de software logrando que un proyecto inicie
estimación. más rápidamente.

Lo mismo sucederá con el resto de requerimientos,
se establecerán diferentes valores de puntos de historia,
sin embargo, al final se llegará a un acuerdo el cual se
aproximará de buena manera al tiempo real que se
tardará el equipo en la realización de cada requerimiento,
obteniendo el tiempo total del proyecto.
• Ejemplo 2:
El equipo y el Dueño de Producto están contentos
con el plan de Sprint y están listos para terminar con la
reunión. El Scrum Master dice “esperad un segundo, esta
historia llamada “añadir usuario”, no tiene estimación.
Hagamos una estimación.” Tras un par de rondas de
Planning póker el equipo acuerda 20 puntos de
estimación, haciendo que el dueño de producto se levante
preso de un ataque de rabia, “¡¿Cómo?!”.
El desarrollo de software no puede ser predicho ni
estimado de forma precisa, sin embargo, aplicando ya sea
una o varias de las técnicas de planeación se logra tener
un estimado del tiempo y el esfuerzo necesario para el
desarrollo de este.
11 REFERENCIAS
[1] J. Vila. (2016, Septiembre 3). Cómo estimar el Backlog del
Producto [En línea] Disponible
en: http://managementplaza.es
[2] H. Kniberg, “Scrum and XP from the trenches: How we do
Scrum, 2nd. Edition, C4Media, United States, p. 7, 2015
[3] C. Gorosito. (2016, Septiembre 1). Cómo priorizar las
actividades de un proyecto – Parte 1 a 6 [En línea].
Disponible en: http://agilecoaching.com.ar

Tras unos minutos de discusión acalorada, resulta
que el equipo entendió mal el alcance de “añadir usuario”
y pensaban que significaba “un bonito interfaz Web para
añadir, eliminar, buscar usuarios”, cuando el Dueño de
Producto quería decir “añadir usuarios a mano haciendo
sentencias SQL contra la base de datos”. Estiman de
nuevo y acaban con 5 puntos de estimación de tiempo
ideal.
[4] H. Kniberg, “Scrum and XP from the trenches: How we do
Scrum, 2nd. Edition, C4Media, United States, pp. 28-29,
2015
[5] H. Kniberg, “Scrum and XP from the trenches: How we do
Scrum, 2nd. Edition, C4Media, United States, pp. 29-32,
2015
[6] (2016, Septiembre 1). Planning Póker. [En línea] Disponible
en: http://www.scrummanager.net/

10 CONCLUSIONES

En el método de desarrollo ágil la reunión de

planeación es sumamente importante, ya que en ella se
definirán todos los requerimientos del software y la
prioridad de cada uno de ellos, se estimará el tiempo que
durara el proyecto, el esfuerzo necesario para llevarlo a
cabo, entre otros; sin embargo, es igual de importante
seguir organizando más reuniones en las cuales se dé
seguimiento a cada una de las partes de desarrollo e
incluso se esclarezcan dudas sobre aspectos específicos
del software.

Se debe de tener muy en cuenta el nivel de prioridad

que posee cada actividad o requisito del software con el
fin de satisfacer principalmente las necesidades más
importantes de los clientes en el periodo de tiempo
determinado por ambas partes

Se debe realizar una buena estimación de la

velocidad que posee el equipo de trabajo para la
realización de las actividades de los proyectos
establecidos, de esta forma se podrá optimizar el número
de puntos de historia que se pueden trabajar en un
periodo de tiempo determinado

El Planning póker es una técnica muy efectiva para

el cálculo de estimaciones, ya que esta minimiza el nivel

12