ARTICULO SOBRE LA MEDICION DE COMPLEJIDAD DE HISTORIAS DE USUARIO

Bueno hablan sobre una parte muy importante del Scrum aparte de las historias de usuario tienen
que tener la capacidad de evaluar cada historia y asignar un valor de complejidad ,este valor es
muy importante ,as que a la hora de asignar tienen que ser muy precavidos, ya que como
programadores al escuchar la historia imaginan como sera el escenario de este mismo ,as que
imaginen al que lo va usar pero en realidad deberan centrarse en detalles,aquellos aspectos a
nivel de software que harn realidad esta historia como ser la interfaz, tablas , controladores y
conexiones a Bases de datos, estos detalles son muy genricos ya que desglosando cada uno se
convierten en ms extensas ,bueno pero ahora ,hablen de mtodos para poder definir este valor
de complejidad .Se conoce un juego que se hace en el grupo que se llama Scrum Pocker ,en esta
sesin el grupo se rene con un solo objetivo ,lograr asignar valores de complejidad a sus historias
de usuario ,pero hay que tener cuidado de que las historias de usuario estn antes bien definidas y
bien claras ,pero aunque as sea siempre el grupo tiende a fallar en este juego ya que los valores
estimados se hacen cortos en el transcurso del sprint ,pero hay que tener en cuenta ciertos
criterios antes de que cada uno ponga un valor de complejidad a la historia de usuario como ser :
Ver ms all de la historia de usuario : Al escuchar la historia de usuario se imaginan un escenario
en el que el como va a interactuar con el software y prestan ms detalles en la vista que en su
funcin ,haciendo ver que la historia no es tan compleja como parece, haciendo que demos un
valor menor de lo que en realidad debera ser .As una recomendacin que pueda o no usar seria
que imagine no como interactuar, sino como lograr hacer esa interaccin.
Desglosar una historia de Usuario : Al momento de querer asignar un valor sean sinceros como
programadores cada quien tiene su fuerte en alguna rama de la programacin como ser interfaz y
Bases de datos ,una recomendacin que podra o no usar seria imaginar como seria el esqueleto
de la historia de usuario e imaginar algunos puntos clave a usarse dentro de esa historia como
decir una ventana, tablas, etc pero solo imaginar ,no decir ,porque esto no es momento de
mencionar estos aspectos de software ,se lo har despus ,por ahora se deben centrar en dar un
valor de complejidad ,entonces en base a esta hiptesis que sacamos sobre posibles puntos clave
se darn cuenta de qu valor podrn asignarle.
Cuidado con el valor de complejidad : Al dar un valor de complejidad de historia de usuario como
se menciona antes, cada programador tiene su fuerte y en ocasiones para uno resulta ser fcil
hacer una cosa y a otra persona quiz no, entonces viendo esto una recomendacin que podra
usar o no usar seria que si la historia habla sobre algn aspecto de software que nos resulta fcil
hacer , tratar de dar el valor de complejidad mucho mayor a la que cree ya que esto tomara como
prevencin sobre futuros malos clculos.
Bueno estos seran aspectos importantes a tomar en cuenta antes de dar un valor de
complejidad,pero aun as siempre tendemos a dar un clculo malo ,pero por qu?, quiz sea que
como grupo,cada uno ver de manera diferente la historia de usuario ,todos tienen que tratar de
entrar en la misma sintona como grupo ,todos tienen que estar muy atentos a la historia de
usuario ,evaluarla muy detalladamente ,as que les doy una recomendacin pero como siempre es

decisin suya elegirla, al oir una Historia de usuario analicen desde el lado del como as que
centrn en la necesidad del como vean qu es lo que de verdad quiere hacer, lavn el odo muy
bien ,ya que estos detalles son los ms importantes ,aparte de las condiciones de satisfaccin a la
hora de escuchar la necesidad del como pueden imaginar un escenario grande en donde el
como ejecutara su accin ,pero para ejecutar esta accin tiene que cumplir ciertas condiciones
de satisfaccin, cosa que tienen que leer aunque sea 3 veces cada una para poder ver en su
imaginacin como se cumplen ,saben que una cosa es imaginar y otra muy distinta es la realidad,
pero teniendo una vista de la imaginacin pueden aunque no por mucho tener una perspectiva de
lo que ser la realidad y as una perspectiva del futuro software a desarrollar en este caso una
parte de ella, pero aun as imaginen esos detalles que hacen que se den cuenta que necesitarn
implementar en una pequea parte de software ,pero aun as siempre tienden a fallar.
Por qu teniendo estas ideas y siguiendo estas recomendaciones fallan ?
En realidad esto es ms aspecto humano que tcnico ,pues como personas estan muy interesados
en acabar lo ms antes posible ,as que tienden a elegir nmeros de complejidad malos. Algunos
consejos que pueden seguir podran ser:
Siempre darse un tiempo : Bueno en realidad el tiempo para elegir un valor de complejidad a la
historia de usuario tiene que ser el mayor posible .por qu dirn? en realidad es porque tienen
que darles tiempo de comprender muy bien esta historia ,cada uno de los integrantes tienen que
ser capaces de dar una interpretacin de la misma.
Defender tu valor : Despus de asignar el valor a la historia de usuario segn su criterio y su
interpretacin de la misma a veces se ven distintos valores, no es cosa nueva. pues cada uno tiene
una distinta perspectiva de la historia de usuario, lo ideal sera ,que cada uno defienda su valor y
explique por qu lo puso as, los dems miembros del grupo escucharn atentamente y vern su
perspectiva y deliberarn si tienen alguna duda ,pero lo ms importante es que cada uno
comprenda porque puso ese valor a la historia de usuario ,lo ideal sera eso , pero como regla del
scrum pocker solo el valor ms alto y el ms bajo definen por qu eligieron ese valor ,el seguir esta
regla o la que propongo, es decisin suya ,ya que Scrum no es un conjunto de reglas a seguir tal
vez la recomendacin dicha no sea adecuada pero uno decide si seguirla o no.
Al jugar SCRUM POCKER ms que un juego es una etapa en la cual los grupos interactan juntos y
deliberan y consiguen asignar un valor de complejidad a las historias de usuario generalmente al
momento de hacer la asignacin se puede presentar algunos problemas.
Como cualquier problema es necesario dar alguna solucin a continuacin vean algunos
problemas presentados y unas recomendaciones para tratar de solucionarlo y recuerde que
seguirlas o no depende de uno.

Valores iguales en todos : A veces se da este escenario en el cual todos los participantes
escogieron el mismo valor oh, dir cosa ms fcil ,entonces esto ya est definido ,pero en realidad

esto es un problema ,aunque parezca imposible pero cierto ,acptenlo ,todos los del grupo no
pueden pensar lo mismo, sabemos que cada quien tiene un pensamiento diferente, en si ,para
tratar de solucionar este problema una recomendacin a seguir sera que cada uno de los
integrantes defienda su valor desde su punto de vista tcnico ,para as ver si algn otro no tom
en cuenta ciertos criterios,generalmente esto sera la solucin ptima para este problema pero
seguirla o no es cosa suya ,quiz encuentre otra solucin ms lgica que lo crea ms conveniente
usar para este problema.
Valor infinito : Bueno a veces se pueden tomar con la sorpresa de que aparezca esta carta en
algn integrante del grupo, esto es un problema,porque hay alguien del grupo que no est
comprendiendo esta historia de usuario ,entonces qu hacer?, pues la recomendacin seria
preguntarle a l que es lo que no comprende de la historia y as cada uno de los integrantes dar
una pequea explicacin de la parte que no entiende , as poder lograr que el compaero entienda
a qu se quiere llegar y pueda dar algn valor de acuerdo a su criterio, seguir esta recomendacin
de decisin suya.
3 ms Valores infinitos : Bueno esto ya es un problema mayor pues el hecho de que uno o dos
no comprendan es pasable pero si se aade un tercero a este asunto ya es en s un problema de la
historia de usuario y no as del grupo ,entonces la recomendacin a seguir seria llamar al cliente y
decir que cambie su historia de usuario porque sencillamente es una historia mal hecha y as no se
puede trabajar .
Bueno en si estos son los problemas ms comunes a la hora de escoger un valor se dijeron alguna
recomendaciones para solucionarlos pero seguirlas o no es decisin de cada quien, tal vez su
grupo considere muy malas estas soluciones y tengan en mente otras mejores soluciones.
En si hasta aqu ya deberan tener una idea de que asignar un valor es sencillamente difcil, bueno
en si lo es ,pero ya ms o menos despejamos algunas dudas, lo que probablemente ayude a
mejorar ese valor, ahora si bien ,tienen recomendaciones no significan que todo est resuelto
deben todava asignar el valor , entonces qu valor dar ? bueno esto no se le puede decir, pues
tiene que asignarle, quiz siguiendo las recomendaciones tengas alguna idea, pero siempre
tiendes a fallar, entonces es siempre dicho que los primeros valores que des van a ser siempre
malos ,pues para esto necesitas de experiencia ,quiz ahora se presenta una historia de usuario
cuyo valor de complejidad que le diste fue 15 pero en realidad esto vali 25 despus de resolverlo,
pero si en un futuro se diera una historia parecida ya no sera 25 o 15 sera menos pues ya
tenemos armado el esqueleto, solo faltaran los cambios, bueno en si ahora necesitan experiencia
para poder mejorar estos valores ,pues a ms experiencia mejores resultados para estos valores.
Ahora hablemos un poco sobre lo que hacer durante el juego del SCRUM POCKER como ser el
tiempo los recesos si se dieran .

Tiempos y Recesos durante el juego : En nuestra sesin de SCRUM POCKER se tienen 2 factores
para lograr una buena sesin y tener mejores resultados sobre los valores de complejidad los
cuales son el tiempo y los recesos ,si bien ya mencionamos antes lo del tiempo es crucial a la hora
del SCRUM POCKER precisamos siempre que este dure mucho para que la historias de usurario
sean bien medidas y comprendidas y otro factor importante son los recesos o la cartas con tazas
de caf, bueno en si estar sentados evaluando cada historia y a veces sin llegar a una conclusin
mutua hace que cada miembro se sienta cansado y necesitan renovar energas, as para ello se da
un corto receso para ir a estirarse o tomar o comer algo ,en s el punto es que cada uno vuelva
con mayores energas y con ms ganas de participar, entonces as se tendr un buena sesin de
SCRUM POCKER bueno en si esto solo son ideas no significa que hay que seguirlas eso depende
de cada grupo.
Bueno en si con esto ya tendramos una idea ms clara sobre lo difcil que es asignar un valor de
complejidad .A que al principio no le pareci difcil, pero ahora tiene una base quiz no sea la
mejor, quiz tenga mejores ideas, puede o no aplicar estos son solo tips para poder comprender la
asignacin de valor complejidad.
Conclusiones sobre la asignacin de valor de complejidad
Bueno como pudieron leer, el proceso de asignacin de valor de complejidad no es cosa fcil, pero
siempre tienen que dar alguno a una historia de usuario, hay que tomar en cuenta muchos
factores para llegar a hacerlo, pero tambin algunas recomendaciones para evitar tropiezos en el
grupo ,quiz sea inevitable poder fallar y darle un valor muy bajo al que merece un valor alto pero
es necesario entender la historia de usuario y desglosarla de tal manera que tengan alguna idea de
qu se usar y as dar algn valor mejor.
Pero hay que tener cuidado ya que a veces sus capacidades de programacin les dan una mala
jugada ,entonces hace que una historia de usuario se devale y consiga un valor inexacto ,al
parecer tienden a evaluar la historia de usuario de acuerdo a su experiencia en programacin,
pero lo que en realidad debe hacerse es evaluar la historia de usuario no solo en experiencias sino
tratar de aadir algo ms de valor para as tratar de no ajustarse a la hora de hacer el sprint, quiz
est adelantando ,pero es que despus una historia es solo el comienzo del juego, hay que ver
ms adentro de la historia para comprenderla , entonces hay que tener esos cuidados a la hora de
elegir un valor ,quiz siempre tiendan a poner valores muy elevados o muy bajos algo puede estar
fallando ,una recomendacin que pueden seguir es que antes de empezar el juego para la
asignacin de valores tienen que saber de cada integrante del grupo sus experiencias de
programacin ,quiz les sirva como ayuda para poder ver las capacidades de cada uno y que
demuestre que su valor de complejidad asignado es el que de verdad est calculando, pues a
veces tienden a equivocarse en esta parte, porque dan un valor de complejidad y no pueden
explicarlo, es decir creen que al dar un valor de complejidad le dan un nmero y piensan que
mientras ms mayor ser mejor o al revs .pero lo que tiene que decir su valor de complejidad es
cuantas veces su experiencia vale esta historia, pero como dijimos antes es mejor darle un + 1 a
este valor por si se presentara algn problema despus al momento de realizar el sprint, pero solo

es una recomendacin seguirla es solo decisin del grupo .solo ac demuestra que deficiencias
tuvieron en el grupo y las posibles soluciones que dimos, quiz ahora vea que no son convenientes
y tal vez tenga en mente mejores soluciones, pero en Scrum no se maneja reglas no hay que seguir
un programa sino todo es trabajo en equipo en base a sus reglas solo Scrum les dice cmo podran
hacer.
Bueno espero haberle orientado un poco ms sobre este tema de asignacin de valores de
complejidad quiz no sea de su agrado las recomendaciones, ideas , solucin de problemas pero
son las que se siguen para solucionar y tomar decisiones para determinar los valores de
complejidad de las historias de usuario del grupo. Recordemos que estas recomendaciones, ideas
y soluciones no son para aplicar como orden sino para orientar, puede seguirlo si lo ve
conveniente como tambin no seguir si es lo contrario.