Technical Debt / Deuda Técnica

Una de las cuestiones que cualquier proyecto Ágil necesita tener en cuenta es cómo solucionar el technical debt o deuda técnica.

El desarrollo en iteraciones cortas puede llevar a entregar una funcionalidad que no está "completa" desde un punto de vista de diseño/arquitectura más general. Desarrollamos una funcionalidad concreta; no tenemos tiempo de pensar cómo ésta encajaría si diseñásemos una aplicación más amplia y nos centrásemos en construir una solución escalable y robusta.

En los proyectos waterfall "tradicionales", la solución está diseñada "por completo" desde un principio. El "gran proyecto" se piensa y se diseña por adelantado y luego la fase de desarrollo consiste en implementar ese diseño al nivel acordado de calidad. Nada de deuda técnica, entonces. Pero... !Esto no es cierto! Y no es cierto porque los proyectos waterfall tienen estimaciones y plazos. Y las estimaciones y los plazos son las dos fuerzas opuestas que comprometen la calidad. Las estimaciones pueden (y serán) erróneas, pero el plazo no se puede modificar (o al menos eso es lo que piensa la dirección). Así que por lo general un proyecto waterfall se inicia con el equipo entregando software de calidad y termina con ese mismo equipo incurriendo en deuda técnica cuando se acerca la fecha límite y se dispara la presión.

De todos modos, volviendo al mundo Ágil. Sí, normalmente tenemos deuda técnica y tenemos que hacerle frente. Mi opinión es que el equipo debe tener el "poder" de decidir la cantidad de deuda técnica que quiere abordar en un sprint en particular, siempre y cuando se consulte con el product owner y esté de acuerdo en las razones eximidas por el equipo.

El equipo técnico es el que conoce mejor el riesgo de acarrear deuda técnica. Así que debe ser capaz de explicar y negociar con el product owner la inclusión de tareas para solucionarlo durante un sprint. Es un ejercicio útil, porque no sólo hace que el product owner sea más consciente de lo que realmente significa el desarrollo de software, sino que también ayuda al equipo de desarrollo a superar la tentación de tener sprints puramente técnicos. ¡Por algo tenemos el product owner!

Y no sólo eso. Cuando se sugiere cuanta deuda técnica debe incluirse en un sprint, el equipo técnico debe tener en cuenta lo siguiente:

• Naturaleza del proyecto/funcionalidad: Algunas características se desarrollan porque se cree que son una gran idea, pero una vez que se entregan a los usuarios, resulta que no son tan útiles, no son realmente utilizados, o incluso pueden llegar a desaparecer (todo el mundo conoce la regla 80/20).
  Mientras que otras características resultan ser grandes éxitos. Son éstas las que tienen que ser escalables y sólidas. Son estas las que mayor importancia tienen si hablamos de deuda técnica.
  No hay ninguna razón para tratar de abordar toda la deuda técnica, sino centrarse en lo que va a tener continuidad.
  
• Encontrar el equilibrio adecuado entre las tareas técnicas y las tareas de desarrollo de nuevas funcionalidades: Cuando se inicia un proyecto Ágil, el negocio comienza a recibir funcionalidad antes que en un proyecto waterfall tradicional. Pero... ¡Cuidado! Si después "gastamos" un montón de sprints dedicados sólo a abordar la deuda técnica y no a la entrega de características tangibles para el negocio, (por muy importante que lo "techie" sea), corremos el riesgo de desilusionar a los usuarios. Es irónico pensar que lo que hemos hecho sea "malcriar" a los usuarios, pero en cierta manera es lo que hacemos con un proyecto Ágil. ¡Y necesitamos tener usuarios satisfechos!
  

One of the issues that any Agile project needs to face is how to address technical debt.

Developing in short iterations can lead to deliver functionality that is not "complete" from an overall design point of view. We implement just this feature; we don’t have time in an iteration to build a wider solution, scalable and robust.

In traditional waterfall projects, the solution is designed "completely" as part of the great schema of things. The grand design is done upfront and then the development phase consists in implementing this design to the agreed level of quality. No technical debt, then. But this is not true! And it is not true because waterfall projects have estimations and deadlines. And estimations and deadlines are two forces that play against each other to compromise quality. The estimations can (and will) be wrong, but the deadline is normally fixed (or so management likes to think). So typically a waterfall project starts with the team delivering quality software and ends up incurring in more and more technical debt as the deadline approaches and the stakeholder/project management pressure soars.

Anyway, going back to the Agile world. Yes, we normally have technical debt and we need to address it. My view is that the team should be empowered to decide the amount of technical debt that wants to address in a particular sprint, as long as they check with the product owner and he/she agrees to the reasons behind.

The tech team is the one knowing the risk of carrying over technical debt. So they should be able to explain and negotiate with the product owner the inclusion of technical debt items in sprints. This is a useful exercise, because not only makes the product owner more aware of what really means to develop software, but also helps the tech team to overcome the temptation of having sprints only "to address technical debt". We have the product owner for a reason!

And not only that. When suggesting the amount of technical debt that should be included in a sprint, the tech team should take into account the following:

• Nature of the project/feature: Some features are developed because they are thought to be a great idea, but once they are delivered to users, it turns out they are not that helpful, they are not really used or even they can be disregarded (everybody knows the 80/20 rule).
  While other features, however, turn out to be great successes. They need to be scalable and made more robust.
  There is no point in trying to address all technical debt, but to focus on what will have continuity.
  
• Find the right balance between tech debt items and new functionality: When you start an Agile project, the business starts seeing functionality sooner than in a traditional waterfall project. But beware! If then you spend a lot of sprints just addressing tech debt and not delivering tangible features to the business, however important the "techie" stuff might be, you have the risk of disengaging users. It is hard to think that you have "spoiled" them, but basically you have. And you need happy customers!
  

Kanban

En este post quiero empezar a hablar del uso de Kanban para soporte a producción. En entornos en los que se utiliza SCRUM para el desarrollo de productos, muchas veces hay aspectos del paradigma SCRUM que no son apropiados para resolver las necesidades de los equipos de operaciones o de infraestructuras.

Por ejemplo:

• Iteraciones: El concepto de iteración puede resultar no apropiado porque los equipos que dan soporte a producción necesitan tener tiempos de respuesta más rápidos (apaga fuegos).
  
• Equipos multidisciplinares vs. equipos especializados: Una de las bases de SCRUM, los equipos multidisciplinares (¿Quien no sueña con un desarrollador de esos a los que a veces se llama “renaissance developer”?), no puede ser aplicable en departamentos de operaciones o infraestructuras, con perfiles altamente especializados.
  

Y es en esos casos donde se puede utilizar Kanban. Pero… ¿qué es Kanban? ¿Cómo se compara con SCRUM? En este post daré las bases de Kanban, y en otros sucesivos me centraré en problemas más particulares y detalles de ponerlo en marcha.

Kanban se puede resumir de la siguiente forma:

• El flujo de trabajo debe ser visible: La famosa “pizarra” de SCRUM. O, en otras palabras, divide el flujo de trabajo en diversas etapas y muéstralas. En la siguiente ilustración he puesto un ejemplo de panel Kanban que utilicé en un proyecto:
  
  
  
  
  En este caso, los diferentes colores correspondían a tipos de tareas. No es necesario distinguir entre tipos de tarea, aunque a veces puede ser útil. También se pueden utilizar diversos tableros Kanban si se tienen diversos equipos, o bien un solo tablero para todos. Además, el diseño del tablero también se puede customizar: los estados de trabajo en vertical y diferentes proyectos / departamentos en horizontal, etc.
  
  
  ¿Qué tarea se escoge para pasar al siguiente estado? Por ejemplo, dentro de la lista de tareas que están pendientes, ¿cuál será la siguiente en la que se trabajará? Kanban no prescibe un método en particular. Se pueden realizar reuniones de priorización, o bien un método más fácil: La más antigua, por ejemplo. Esto es una diferencia con el Product Backlog con prioridades de SCRUM.
  
  
• Limita el Work in Progress: Este es el concepto fundamental. El equipo sólo puede trabajar en x elementos a la misma vez. Este número es más difícil de establecer correctamente de lo que parece a simple vista. En un principio, casi seguro que los equipos se equivocarán. Pero por la naturaleza de “prueba y error” de Kanban, el numero se irá modificando hasta que funcione.
  
  Es el número 4 del ejemplo gráfico anterior:
  
  
  
  
  
  Significa que el equipo, pase lo que pase, sólo puede trabajar en 4 elementos a la vez.
  
  En general:
  
  • Si el limite WIP es demasiado bajo, podemos tener a miembros del equipo de brazos cruzados. Esto es especialmente crítico si el tipo de tareas no son fácilmente compartidas (tipos de trabajo en los que poner a más personas trabajando en ellas sólo creará problemas).
    
  • Si el límite WIP es demasiado alto, baja el tiempo de respuesta. Nos acercamos a la forma de trabajar tradicional (estamos en mil cosas y no acabamos ninguna). No se sabe nunca cuando el negocio tendrá resolución y, además, no hay presión para solventar cuellos de botella porque el equipo se puede poner a trabajar en otra tarea sin problemas.
    
  
  
  A veces, encontrar el límite de WIP correcto llega a parecerse más a un arte que a una ciencia.
  En algunos casos, también se pueden poner límites en otras columnas. Por ejemplo, en “paso a producción”. Esto ayuda porque así evita que se acumulen elementos en cualquier estado.
  En general, las ventajas son que limitando el WIP tenemos una forma muy gráfica para detectar cuellos de botella y que conseguimos que el equipo se concentre en resolver el trabajo que tiene entre manos.
  
  
• Mide y optimiza el tiempo medio para completar un elemento: A esto se le llama “tiempo de ciclo”, en inglés “Lead time”. Es importantísimo porque el “Lead time” es la base de las expectativas de negocio y también se utilizará para ir adaptando el límite de WIP hasta llegar a un valor óptimo para cada equipo.
  
  
  
  
  Aunque ahora no me extenderé sobre el tema, es bastante lógico deducir que para que la métrica de “Lead time” tenga sentido, las tareas deben tener tamaños más o menos equivalentes. O, si no es así, tener una medida en “horas-hombre”, “puntos de historia”, etc. Las tareas se priorizan y se estiman en reuniones de planificación, que en el caso de Kanban se pueden establecer cuando sea más necesario.
  

Resumiendo, muchas veces se utiliza Kanban para el soporte a produción y SCRUM para el desarrollo. Ambos comparten principios comunes, lo que los hace perfectamente compatibles. Sobretodo, los dos están basados en la evaluación continua. El método de la prueba y el error. En este aspecto, SCRUM es más restrictivo que Kanban. En SCRUM, la reunión de retrospective es imprescindible y se realiza al final de una iteración. En Kanban, no hay limitaciones al respecto. Y cuando “insertamos” retrospectives de forma más o menos organizada en un método Kanban, estamos llegando a un sistema que se ha empezado a llamar “Scrumban”.

In this post I want to talk about using Kanban for production support. In environments where SCRUM is used for product development, often some aspects of the SCRUM paradigm are not appropriate to meet the needs of operations or infrastructure teams.

For example:

• Iterations: The concept of iteration may be inappropriate because the teams that give support to production need faster response times (a “firefighting” approach).
  
• Multidisciplinary teams vs. specialized teams: One of the foundations of SCRUM, to have multidisciplinary teams (who does not dream of a "renaissance developer", as sometimes multidisciplinary developers are called?) may not be applicable in operations or infrastructure departments, with highly specialized profiles.
  

And in those cases where SCRUM is not appropiate, we can use Kanban. But ... what is Kanban? How does it compare to SCRUM? In this post I will give the basis for Kanban, and in further ones I will focus on first-hand problems and details of how to put it to work.

Kanban can be summarized as follows:

• The workflow must be visible: This is similar to the famous SCRUM whiteboard. What this means is to divide the workflow in several stages and make them visible in a whiteboard or panel. I have created a graphic of a Kanban panel I used in a project:
  
  
  
  
  
  In this case, different colors corresponded to different types of tasks. It is not necessary to distinguish between task types; each case is different. You can also use various Kanban boards if you have different teams, or just a single board for all teams. You can also customise the board itself: different work stages in vertical and different projects / departments in horizontal, etc..
  
  What task is chosen to be moved to the next state? For example, in the list of pending tasks, which one will be next? Kanban does not prescibe a particular method. You can have prioritisation meetings, or chose an easier way: Take always the oldest task, for example. This is a difference with the SCRUM’s prioritised Product Backlog.
  
  
• Limit the Work in Progress: This is the fundamental concept. The team can only work on x items at once. This number is more difficult to establish correctly than it would seem at first. Initially, the teams will almost certainly be wrong when choosing a work limit. But by the "trial and error" law used in Kanban, the number will be adapted until we find a limit that works for the team.
  
  The WIP is the number 4 in this example:
  
  
  
  
  It means that the team, no matter what happens, can only work in 4 items at once.
  
  In general:
  
  • If the WIP limit is too low, we have members of the team doing nothing. This is especially important if the tasks are not easily shared.
    
  • If the WIP limit is too high, you end up with poor response times. We get closer to the traditional way of working (we are working in a thousand things at the same time and we are not geting anywhere). The business does not know when a problem will be fixed and there is no pressure to fix bottlenecks because the team can work in another task without problems.
    
  
  
  This is why, sometimes, choosing the right WIP limit is more an art than a science.
  Also, in some cases you can also set limits in other columns. For example, in "Release". This is helpful as it prevents the accumulation of elements in any state.
  In general, limiting WIP is a very good method to graphically detect bottlenecks.
  And limiting WIP, we got the team to concentrate on solving the job at hand.
  
  
• Measure and optimize the “Lead time”: The time to complete an item. It is very important because the "Lead time" is the basis for business expectations and also will be used to gradually adapt the WIP limit, up to an optimal value for each team.
  
  
  
  
  Although now I will not dwell on the subject, it is quite logical to deduce that for the metric of "Lead time" to make sense, the tasks should have roughly equivalent sizes. Or if not, we need to have them estimated in "man hours", "story points", etc.. The tasks are prioritized and estimated at planning meetings, which in the case of Kanban can be set when needed most.
  

In short, Kanban is often used for support as SCRUM is used for product development. Both share common principles, which makes them fully compatible. Above all, both are based on continuous assessment: the method of trial and error. In this regard, SCRUM is more restrictive than Kanban. In SCRUM, the retrospective meeting is required and is to be held at the end of an iteration. In Kanban, there are no constraints on the matter. And when we start having retrospectives in a organised way, sometimes scheduling them aligned with the SCRUM teams, we are getting close to what is started to be known as "Scrumban."

Un buen SCRUM Master / A good SCRUM Master

Mucho se habla (sobretodo en los procesos de selección) sobre las cualidades que un buen SCRUM Master debería tener, aparte de los conocimientos técnicos.

Es un tema de vital importancia y como tal, se discute también en trainings, cursos de certificación y en muchos foros. Porque, como en todos los trabajos, a veces son las "soft skills" las más difíciles de evaluar. Cuando contratamos a un desarrollador de software, tenemos claro las habilidades técnicas que requerimos (Java, C++, SQL, lenguajes de scripting, etc...), pero a la hora de identificar las “soft skills”, muchas veces nos limitamos a listar una serie más o menos estándar, porque tampoco somos capaces de darles la justa importancia: Queremos a alguien con capacidad de comunicación, entusiasta y "team player". Seguro que las habéis leído en las ofertas miles de veces.

En el caso de un SCRUM Master, estas "soft skills" son aún más importantes si cabe. Precisamente son sus "soft skills" las que le harán tener éxito. Si el SCRUM Master ha sido en un pasado (o es todavía) jefe de proyecto, muchas de las cualidades que necesitará ya las ha tenido que poner en práctica. Pero si el SCRUM Master es un técnico, la cosa se complica.

Según mi experiencia, las cualidades que van a hacer que un SCRUM Master tenga éxito son:

• Ser un buen comunicador.
  
  La comunicación no es una parte importante... ¡es esencial! Se calcula que un 90% del tiempo de un jefe de proyecto es la comunicación. No conozco datos sobre qué % aproximadamente pasa un SCRUM Master comunicando (cuando ejerce como tal, no cuando hace otras tareas), pero me atreviría a decir que es un porcentaje similar.


• Ser "bueno" con la gente.
  
  Puesto que esta definición es demasiado amplia y abstracta, me concentraré en los rasgos que más importantes me parecen: Ser paciente, ser capaz de entender que cada persona es diferente, saber tratar con diferentes caracteres, saber escuchar y saber razonar. A veces se dice que ser SCRUM Master es un poco como ser el padre/madre del grupo. Y para los que tienen background de jefes de proyecto, este símil no les parecerá extravagante.


• Conocer bien la teoría de SCRUM.
  
  Sí, es importante. Por eso es recomendable que quien ejerza de SCRUM Master esté certificado o haya atendido alguna formación. Por ejemplo, es básico conocer y ser capaz de explicar la importancia del SCRUM diario. Si tenemos un miembro del equipo que sistemáticamente no atiende el SCRUM diario, no dejarlo pasar ("lo importante es que saca el trabajo adelante"), sino hacer hincapié, razonando, en que ciertas "reglas" de SCRUM hay que seguirlas. Por algo hay pocas.


• Y finalmente, ser expeditivo, o en otras palabras, ser bueno resolviendo problemas.
  
  Tener esa capacidad de "arreglar las cosas", y no me refiero a arreglar descalabros técnicos, sino situaciones comprometidas, obstáculos, dificultades de todo tipo. No en vano, una de las tareas más habituales del SCRUM Master (que se cita y se practica al obtener la certificación) es la de "quitar obstáculos" (en inglés "remove blockers / remove impediments"). Por cierto, que en este ámbito, tener una "lista de obstáculos pública" muchas veces ayuda. Da visibilidad.

There is much talk (especially when recruiting) on the qualities a good SCRUM Master should have, apart from technical expertise.

It is a vital issue and as such, is also discussed in Certified SCRUM Master courses, training courses and in many forums. Because sometimes the soft skills are the most difficult to assess. When we hire a software developer, we usually know exactly which technical skills we need (Java, C++, SQL, scripting languages, etc ...), but when it comes to soft skills, sometimes we just list a series of more or less standard qualities: For example, that we want someone with good communication skills, with enthusiasm and able to be a "team player". I am sure that you have read those in job offers thousands of times.

In the case of a SCRUM Master, it is a very different scenario. His/her soft skills are precisely what will make him/her succeed. If the SCRUM Master has been in the past (or still is) a project manager, he/she surely has practiced many of the qualities needed. But if the SCRUM Master is a software developer with no management experience, things get complicated.

In my experience, some of the qualities that will make a SCRUM Master be successful are:

• Being a good communicator.
  
  Communication is not just “important" ... it is essential! A project manager spends an estimated 90% of the time communicating. I don’t know what % of time a SCRUM Master spends communicating (when he/she acts as SCRUM Master, not when he/she is doing another tasks that might be part of his/her job), but I am sure that it is a very similar percentage.


• Being "good" with people.
  
  Since this definition is too broad and abstract, I will focus on traits that seem to me the most important ones: Be patient, be able to understand that each person is different, knowing how to deal with different characters, listening and being able to reason. Sometimes, it is said that being a SCRUM Master is a bit like being the parent of the group. And for those who have a project management background, this comparison won’t seem too strange!


• Knowing well the theory of SCRUM.
  
  Yes, it is important. It is therefore recommended that the person exercising as SCRUM Master is a Certified SCRUM Master (CSM) or has attended training on SCRUM principles. For example, it is essential to know and be able to explain the importance of daily SCRUM. If we have a team member who consistently does not attend the daily SCRUM, the SCRUM Master should not let it pass ("it does not matter if the team member does not attend daily SCRUM, what matters is that he/she gets the job done"). The SCRUM Master should emphasize why it is important that the SCRUM "rules" are to be followed (there are not that many, anyway!)
  


• And finally, be “a fixer”, or in other words, be good at solving problems.
  
  It is important to have the ability to "fix things" - and I don’t mean to fix technical setbacks, but to solve difficult situations and overcome obstacles of all kinds. Not surprisingly, one of the most common tasks of a SCRUM Master (as explained in training courses or when you get the certification) is to remove blockers / remove impediments. By the way, in this respect, having a "public impediment list” sometimes helps. It gives a lot of visibility to what needs to be fixed.

Estimaciones / Estimations

Es de sobras conocido que la estimación es una de las áreas más problemáticas en todo proyecto de software. Pero en esta entrada no quiero centrarme en los problemas más habituales cuando estimamos (cómo conseguir estimaciones lo más cerca de la realidad posible), sino en un punto directamente relacionado con SCRUM. Un punto en el que he visto, muchas veces, que hay confusión.

Por si fuera poco con los problemas intrínsecos de la estimación, cuando estamos empezando a trabajar con SCRUM surgen dudas, que yo llamo "logísticas", sobre cómo vamos a estimar. ¿En horas? ¿En puntos de historia? ¿Qué relación hay entre las unidades de estimación y estimar en tareas o historias de usuario?

Voy a explicar mi punto de vista, basado en mi experiencia. Pero quiero dejar claro que no hay un método estándar. Es cierto que algunas herramientas (estoy pensando en TFS) pueden predeterminar cómo entrar las estimaciones (por ejemplo en horas), pero no hay una fórmula mágica. Y esto es bueno, porque es flexible.

SCRUM te da la posibilidad de adaptar cómo estimamos a nuestra necesidad. En general, las historias de usuario se estiman en puntos de esfuerzo mientras que las tareas en horas.

Las historias de usuario forman el Product Backlog. Del Product Backlog, las escogeremos para nuestro Sprint (el Product Backlog está ordenado por prioridades del negocio) y compondremos con él el Sprint Backlog.

En la reunión de Sprint Kickoff, analizaremos las historias de usuario y refinaremos su estimación. Aquí es donde yo suelo descomponer las historias de usuario en tareas y asignar horas.

Es decir:

• Las estimaciones de las historias de usuario son más globales y las utilizo para dar estimaciones al negocio. Es muy útil en el caso que el negocio necesite tener buenas estimaciones del proyecto en sí: cuando, por ejemplo, es crítico cumplir plazos.


• Las estimaciones en horas por tareas las utilizaré para controlar el Sprint, con el Burndown Chart.

Esta es una forma de hacerlo, pero no la única. Por ejemplo, en un proyecto que realicé tuvimos suficiente con las estimaciones de historias de usuario, puesto que eran pequeñas, (de 1 o 2 días de duración), y no valía la pena dividirlas en tareas. Como en ese caso tampoco utilizábamos ninguna "herramienta sofisticada" para llevar el tracking del proyecto (nuestro Sprint Backlog era un fichero excel y nuestro Burndown Chart, un gráfico derivado de dicho excel), pudimos cambiar nuestro "modus operandi" y trabajar con puntos de esfuerzo sin mucha complicación.

En general es importante entender los conceptos básicos (historias de usuario, tareas, etc.), pero es más importante aún saber adaptarlas a tu entorno (necesidades del negocio, equipo, etc.). Y, muchas veces, cambiar: A veces el equipo puede tener dificultad estimando en puntos de esfuerzo por estar muy habituado a estimar en horas, mientras que otras veces, al cabo de poco, estimar en puntos de esfuerzo resultará más afinado.

It is widely known that estimation is one of the most problematic areas in any software development project. But in this post, I don't want to focus on the most common problems of estimation (how to obtain estimates as close to reality as possible), but on a question related to SCRUM that I've seen many times.

As if the problems of estimating were not difficult enough, when we begin to work with SCRUM a lot of questions on how to estimate arise. Questions which I like to call "logistical". Do we estimate in hours? In history points? What is the relationship between tasks and user stories?

Let me explain my point of view, based on my experience. But let me make clear that there is no standard method. It is true that some tools (I'm thinking TFS) can predetermine how to set the estimates (for example in hours), but there is no magic formula. And this is good, because it is flexible.

SCRUM gives you the ability to adapt how you estimate to your real needs. In general, user stories are with history points while tasks are estimated in hours.

User stories compose the Product Backlog. Then, every Sprint some user stories are chosen and compose the Sprint Backlog (the Product Backlog is sorted by business priorities).

In the Sprint Kickoff meeting, the user stories will be analyzed and assigned, and the estimations will be "refined" to make them more accurate. This is when I usually break the user stories into tasks and assign hours to them.

That is:

• Estimates of user stories (history points) are more global and I use them for the business. This is very useful when the business has the need for good estimates of the project itself: When, for example, is critical to meet deadlines.


• Estimates of tasks (hours) are more specific and I use them to track the Sprint (Burndown Chart).

As said, this is a scheme that has worked for me, but it is not the only one. In one project I worked, we had enough with user stories estimates, since they were small, (1 or 2 days), and it was not worth splitting them into tasks. As in that case we used no "sophisticated tool" to track the project (our Sprint Backlog was an excel file and our Burndown Chart, a graph produced from that excel), we changed our "modus operandi" and worked with history points without much hassle. But, I repeat, each case is unique.

In general, it is important to understand the basics (user stories, tasks, etc.), but it is more important to learn how to adapt it to your environment (business needs, team, etc.). And don't be afraid to change: Sometimes, the team might have difficulty estimating with history points as they are used to estimate in hours, while other times, after a short period of time, estimation with history points becomes simpler and more accurate.