Requisitos, tareas, historias, prioridades objetivos,… una de las cosas más difíciles a la hora de desarrollar un producto software no es la arquitectura, ni los test, ni siquiera el lenguaje de programación, los más complicado es saber que hacer en el momento adecuado. Qué tenemos que construir, por qué vamos a hacerlo, como lo haremos y que es lo que va primero.
Sí, estoy hablando de priorizar, de objetivos. Así que aquí voy a intentar descubrir algunas técnicas para priorizar un product backlog o al menos intentarlo. No vamos a entrar en detalle de como hacerlo, hay miles de recursos que seguro lo explican mucho mejor que yo, solo quiero tener una pequeña lista de técnicas y un par de pinceladas de cómo funcionan.
MoSCoW (Must – Should – Could – Won’t)
Todos los requisitos son importantes, pero es necesario priorizar cuales son los que más valor aportan. Una forma de hacerlo es clasificarlos en:
- Must: tiene que estar sí o sí para que el sistema sea un éxito.
- Should: debería estar en la versión final, pero si llegase el momento y fuera necesario, se podría prescindir de él.
- Could: sería interesante que la solución incluyera este requisito. Aunque se trata de una característica opcional.
- Won’t: son requisitos que no se incluirán en esta versión, pero que podrían considerarse en el futuro.
Esta clasificación puede ser modificada durante el proceso de desarrollo redefinirse en cada sprint.
Clasificar así los requisitos nos sirve para tener foco en lo importante y no «malgastar» esfuerzos en historias que podrían ser interesantes pero no son lo prioritario.
El mayor problema de está técnica es que si todo es importante, nada es importante…
Hierarchical product backlog
La idea de está técnica es agrupar los requisitos de manera jerárquica. Es decir, lo que hacemos es estructurar el trabajo: desde los objetivos más grandes, hasta los detalles más minuciosos. Para ello nos ayudamos de un plan basado en temas, iniciativas, épicas, historias y tareas.
- Themes: areas donde la organización quiere enfocarse.
- Iniziatives: son colecciones de épicas que tienen un objetivo común.
- Epics: son grandes cantidades de trabajo que se pueden dividir en una serie de tareas más pequeñas (llamadas historias).
- Stories: son requisitos escritos desde la perspectiva de un usuario final.
- Task: son la descomposición de la historia en pequeñas partes (generalmente independientes)
Puede servirnos si tenemos por ejemplos unos themes o epics definidos por cuatrimeste (quarter en inglés), es decir, si tenemos la compañía marca una serie de hitos a cumplir en un periodo de tiempo podemos «aterrizar» esos objetivos desgranándolos. Aunque bien es cierto que no es necesario refinar hasta tarea el primer día, sino que debería ser algo progresivo a medida que vamos lanzando producto y aprendiendo del feedback recibido.
User Story Mapping
Lo que acaba pasando en un product backlog es que tenemos una pila quasi-infinita de «product backlog items» y así es imposible priorizar. A menos que el product owner «borre/actualice/archive/ordene» elementos de manera frecuente se hace imposible priorizar. Por ello Jeff Patton creó User Story Mapping, un Product Backlog en dos dimensiones: releases y funcionalidades.
La idea es definir unos objetivos a muy alto nivel, a partir de dichos objetivos definir «épicas» y distribuir esas épicas a lo largo del tablero.
Descomponemos las épicas en historias y una vez estén creamos «slices/releases»
Impact Mapping
Es una técnica de planificación que propone concentrar los esfuerzos en lo realmente importante. Para ello se basa en hacer preguntas concretas para determinar que es aquello que debemos contruir para llegar a los objetivos deseados.
Las cuatro preguntas son:
- ¿Por qué?: Identificamos los objetivos. Representa el problema a resolver.
- ¿Quién?: Son los que influencian el éxito. .¿Quiénes pueden crear/obstruir el efecto deseado?
- ¿Cómo?: Coloca a los actores en la perspectiva de los objetivos. ¿Cómo nos podrían ayudar a alcanzarlos?
- ¿Qué? Es donde se contruyen las épicas o historias. ¿Qué podemos hacer como equipo?
User Personas
Consiste en elaborar una «plantilla» en la que tratamos de describir a los usuarios junto con sus necesidades. La idea es crear una ficha de una «persona ficticia» que corresponda a un grupo de usuarios y a la que podamos «preguntar» cuales son sus necesidades para intentar cubrirlas con historias de usuario.
Roadmap
Es un plan de alto nivel que describe como el producto va a ir evolucionando en el futuro. Permite proyectar en el tiempo donde quieres que este tú producto en el futuro. La idea es tener una especie de calendario mensual donde se «anoten» los hitos que tenemos que cumplir. En base a esos hitos definir los sprints goals
Otras técnicas de priorización
Existen otras muchas técnicas de priorización, no menos importantes de las que hemos nombrado aquí. Por ejemplo: Purpose Alignment Model (http://www.agilocity.co.za/prioritizing-using-the-purpose-alignment-model/) , Weighted shortest job first (Lo más corto al principio), expert opinion, financial analysis, kano analysis,…
Conclusión
Existen muchísimas técnicas de priorización del backlog, la idea es conocer algunas y poder probarlas. Tener un tablero visual donde poder «tocar» como va evolucionando nuestro producto es esencial para no perder el foco, evitar el desperdicio y aportar el máximo valor.
Algunos libros y referencias:
- Scrum – A Pocket Guide (Best practice)
- Agile Estimating and Planning (Rober C Martin)
- User Story Mapping: Discover the Whole Story, Build the Right Product
- Impact Mapping: Making a Big Impact with Software Products and Projects
- https://jummp.wordpress.com/2013/04/27/metodo-moscow/
- https://www.atlassian.com/agile/project-management/epics-stories-themes
- https://jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf
- http://www.barryovereem.com/the-user-story-mapping-game/
- https://www.impactmapping.org/
- http://jmbeas.es/guias/user-personas/
Jesús L.C. - Apuntes de un aprendiz 
Yo sigo la técnica que me enseñaron en el instituto para estudiar y para los exámenes: lo más complicado y grande en primer lugar.
Así, si no llegas bien al deadline con el cliente, sólo serán detalles lo que reste y no le dará mucha importancia, pues se pueden ir haciendo poco a poco con el proyecto ya en marcha.
Me gustaMe gusta