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 sería el escenario de este mismo ,así que
imaginen al que lo va usar pero en realidad deberían centrarse en detalles,aquellos aspectos a
nivel de software que harán realidad esta historia como ser la interfaz, tablas , controladores y
conexiones a Bases de datos, estos detalles son muy genéricos ya que desglosando cada uno se
convierten en más extensas ,bueno pero ahora ,hablen de métodos para poder definir este valor
de complejidad .Se conoce un juego que se hace en el grupo que se llama “Scrum Pocker” ,en esta
sesión el grupo se reúne 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 estén 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 más 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 más detalles en la vista que en su
función ,haciendo ver que la historia no es tan compleja como parece, haciendo que demos un
valor menor de lo que en realidad debería ser .Así una recomendación que pueda o no usar seria
que imagine no como interactuará, sino como logrará hacer esa interacción.
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 programación como ser interfaz y
Bases de datos ,una recomendación que podría 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á después ,por ahora se deben centrar en dar un
valor de complejidad ,entonces en base a esta hipótesis que sacamos sobre posibles puntos clave
se darán cuenta de qué valor podrán 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 fácil
hacer una cosa y a otra persona quizá no, entonces viendo esto una recomendación que podría
usar o no usar seria que si la historia habla sobre algún aspecto de software que nos resulta fácil
hacer , tratar de dar el valor de complejidad mucho mayor a la que cree ya que esto tomaría como
prevención sobre futuros malos cálculos.
Bueno estos serían aspectos importantes a tomar en cuenta antes de dar un valor de
complejidad,pero aun así siempre tendemos a dar un cálculo 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 sintonía como grupo ,todos tienen que estar muy atentos a la historia de
usuario ,evaluarla muy detalladamente ,así que les doy una recomendación pero como siempre es

cada uno de los integrantes tienen que ser capaces de dar una interpretación de la misma. no es cosa nueva. lavén el oído muy bien . es decisión suya .decisión suya elegirla.pero lo más importante es que cada uno comprenda porque puso ese valor a la historia de usuario . Por qué teniendo estas ideas y siguiendo estas recomendaciones fallan ? En realidad esto es más aspecto humano que técnico .así que tienden a elegir números de complejidad malos.saben que una cosa es imaginar y otra muy distinta es la realidad.pues como personas estan muy interesados en acabar lo más antes posible . pero como regla del scrum pocker solo el valor más alto y el más bajo definen por qué eligieron ese valor .pero en realidad . dirá cosa más fácil . los demás miembros del grupo escucharán atentamente y verán su perspectiva y deliberarán si tienen alguna duda . al oir una Historia de usuario analicen desde el lado del “como” así que centrén en la necesidad del “como” vean qué es lo que de verdad quiere hacer.aparte de las condiciones de satisfacción a la hora de escuchar la necesidad del “como” pueden imaginar un escenario grande en donde el “como” ejecutara su acción . pero teniendo una vista de la imaginación 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.ya que estos detalles son los más importantes .por qué dirán? en realidad es porque tienen que darles tiempo de comprender muy bien esta historia . lo ideal sería .el seguir esta regla o la que propongo.pero aun así siempre tienden a fallar. Al jugar SCRUM POCKER más que un juego es una etapa en la cual los grupos interactúan juntos y deliberan y consiguen asignar un valor de complejidad a las historias de usuario generalmente al momento de hacer la asignación se puede presentar algunos problemas.ya que Scrum no es un conjunto de reglas a seguir tal vez la recomendación dicha no sea adecuada pero uno decide si seguirla o no. Defender tu valor : Después de asignar el valor a la historia de usuario según su criterio y su interpretación de la misma a veces se ven distintos valores.entonces esto ya está definido .lo ideal sería eso . pero aun así imaginen esos detalles que hacen que se den cuenta que necesitarán implementar en una pequeña parte de software . cosa que tienen que leer aunque sea 3 veces cada una para poder ver en su imaginación como se cumplen .pero para ejecutar esta acción tiene que cumplir ciertas condiciones de satisfacción. Como cualquier problema es necesario dar alguna solución a continuación 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. Algunos consejos que pueden seguir podrían 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 . pues cada uno tiene una distinta perspectiva de la historia de usuario.que cada uno defienda su valor y explique por qué lo puso así.

sabemos que cada quien tiene un pensamiento diferente.acéptenlo . quizá siguiendo las recomendaciones tengas alguna idea.para así ver si algún otro no tomó en cuenta ciertos criterios.quizá ahora se presenta una historia de usuario cuyo valor de complejidad que le diste fue 15 pero en realidad esto valió 25 después de resolverlo.tienen recomendaciones no significan que todo esté resuelto deben todavía asignar el valor .entonces la recomendación 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 . .para tratar de solucionar este problema una recomendación a seguir sería que cada uno de los integrantes defienda su valor desde su punto de vista técnico . tal vez su grupo considere muy malas estas soluciones y tengan en mente otras mejores soluciones.entonces qué hacer?. seguir esta recomendación de decisión suya.generalmente esto sería la solución óptima para este problema pero seguirla o no es cosa suya . entonces qué valor dar ? bueno esto no se le puede decir. ahora si bien . Valor infinito : Bueno a veces se pueden tomar con la sorpresa de que aparezca esta carta en algún integrante del grupo.esto es un problema . pues tiene que asignarle.pero ya más o menos despejamos algunas dudas.pues para esto necesitas de experiencia . pero si en un futuro se diera una historia parecida ya no sería 25 o 15 sería menos pues ya tenemos armado el esqueleto. lo que probablemente ayude a mejorar ese valor.quizá encuentre otra solución más lógica que lo crea más conveniente usar para este problema.aunque parezca imposible pero cierto . Bueno en si estos son los problemas más comunes a la hora de escoger un valor se dijeron alguna recomendaciones para solucionarlos pero seguirlas o no es decisión de cada quien.todos los del grupo no pueden pensar lo mismo. entonces es siempre dicho que los primeros valores que des van a ser siempre malos . pues la recomendación seria preguntarle a él que es lo que no comprende de la historia y así cada uno de los integrantes dará una pequeña explicación de la parte que no entiende . así poder lograr que el compañero entienda a qué se quiere llegar y pueda dar algún valor de acuerdo a su criterio.pues a más experiencia mejores resultados para estos valores.porque hay alguien del grupo que no está comprendiendo esta historia de usuario . solo faltarían los cambios. bueno en si ahora necesitan experiencia para poder mejorar estos valores . bueno en si lo es . pero siempre tiendes a fallar. en si . En si hasta aquí ya deberían tener una idea de que asignar un valor es sencillamente difícil. 3 ó más Valores infinitos : Bueno esto ya es un problema mayor pues el hecho de que uno o dos no comprendan es pasable pero si se añade un tercero a este asunto ya es en sí un problema de la historia de usuario y no así del grupo . esto es un problema. Ahora hablemos un poco sobre lo que hacer durante el juego del SCRUM POCKER como ser el tiempo los recesos si se dieran .

una recomendación que pueden seguir es que antes de empezar el juego para la asignación de valores tienen que saber de cada integrante del grupo sus experiencias de programación . es decir creen que al dar un valor de complejidad le dan un número y piensan que mientras más mayor será mejor o al revés . entonces así se tendrá un buena sesión de “SCRUM POCKER” bueno en si esto solo son ideas no significa que hay que seguirlas eso depende de cada grupo. quizá esté adelantando . pero como dijimos antes es mejor darle un + 1 a este valor por si se presentara algún problema después al momento de realizar el sprint. Conclusiones sobre la asignación de valor de complejidad Bueno como pudieron leer. pues a veces tienden a equivocarse en esta parte. Pero hay que tener cuidado ya que a veces sus capacidades de programación les dan una mala jugada .al parecer tienden a evaluar la historia de usuario de acuerdo a su experiencia en programación. puede o no aplicar estos son solo tips para poder comprender la asignación de valor complejidad. hay que tomar en cuenta muchos factores para llegar a hacerlo.pero lo que tiene que decir su valor de complejidad es cuantas veces su experiencia vale esta historia. quizá tenga mejores ideas. porque dan un valor de complejidad y no pueden explicarlo.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 algún valor mejor. pero solo . hay que ver más adentro de la historia para comprenderla .entonces hace que una historia de usuario se devalúe y consiga un valor inexacto . Bueno en si con esto ya tendríamos una idea más clara sobre lo difícil que es asignar un valor de complejidad . el proceso de asignación de valor de complejidad no es cosa fácil. entonces hay que tener esos cuidados a la hora de elegir un valor .A que al principio no le pareció difícil.pero es que después una historia es solo el comienzo del juego. pero siempre tienen que dar alguno a una historia de usuario.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. pero lo que en realidad debe hacerse es evaluar la historia de usuario no solo en experiencias sino tratar de añadir algo más de valor para así tratar de no ajustarse a la hora de hacer el sprint. bueno en si estar sentados evaluando cada historia y a veces sin llegar a una conclusión mutua hace que cada miembro se sienta cansado y necesitan renovar energías. pero ahora tiene una base quizá no sea la mejor.en sí el punto es que cada uno vuelva con mayores energías y con más ganas de participar.quizá siempre tiendan a poner valores muy elevados o muy bajos algo puede estar fallando .Tiempos y Recesos durante el juego : En nuestra sesión de “SCRUM POCKER ” se tienen 2 factores para lograr una buena sesión y tener mejores resultados sobre los valores de complejidad los cuales son el tiempo y los recesos . así para ello se da un corto receso para ir a estirarse o tomar o comer algo . pero también algunas recomendaciones para evitar tropiezos en el grupo .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é.

ideas . ideas y soluciones no son para aplicar como orden sino para orientar. Bueno espero haberle orientado un poco más sobre este tema de asignación de valores de complejidad quizá no sea de su agrado las recomendaciones. solución 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. puede seguirlo si lo ve conveniente como también no seguir si es lo contrario. 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 cómo podrían hacer. . Recordemos que estas recomendaciones.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.es una recomendación seguirla es solo decisión del grupo .