Les 7 flexibilités du backlog Agile

(English follows)

Comment un backlog Agile peut-il survivre à la tempête d’un projet tout en livrant une solution cohésive? En grande partie, ceci vient de ses multiples niveaux de flexibilité. La vision d’un projet, décrite dans un tel backlog, devient adaptable à plusieurs, ou même à la majeure partie, des changements auxquels un projet fait face. Regardons ces options de flexibilité par ordre d’impact croissant sur la portée et la qualité.

1) Priorité

S’adapter au changement peut se faire de façon simple, avec un impact minimal, via une re-priorisation où, quand c’est possible, la solution est de simplement livrer les histoires dans un ordre différent. Par exemple: nous venons d’apprendre que tout le travail lié à la technologie XYZ doit être complété avant une certaine date. Face à cette nouvelle contrainte, le PO peut mettre les histoires impactées dans le haut du backlog.

2) Découpage d’histoire

Une autre approche d’adaptation au changement avec un impact minimal est de découper une histoire en deux ou plusieurs histoires plus petites. Cette action implique souvent une re-priorisation de ces nouvelles histoires. Faire ceci demande plus de temps qu’un simple changement de priorisation et, globalement, la qualité et la portée peuvent toujours être maintenues si toutes les nouvelles histoires sont livrées.  Par exemple: une histoire n’est pas prête pour la planification de l’itération, car une partie de cette dernière demande encore un peu de recherche. Si possible, le PO peut alors la découper en deux parties autonomes où la première devient prête pour le développement, alors que la deuxième reste bloquée. Pour que ceci soit efficace, d’un point de vue Agile, les deux histoires devraient apporter de la valeur à l’utilisateur.

3) Approaches techniques alternatives

Très souvent, il y a plusieurs recettes technologiques possibles pour réaliser une histoire. Afin d’éviter d’impacter la portée ou la qualité, regardons la solution ne créant pas de dette technique (ceci est couvert au point 7). Plusieurs solutions veut aussi dire différents niveaux d’effort et de qualité. Ceci donne des choix au PO, et donc plus de flexibilité dans le backlog. Par exemple:  une fonctionnalité pose un problème technique pouvant être résolue de plusieurs façons. L’équipe de développement peut donc proposer 2-3 approches au PO en lui donnant les pour et les contre. Une solution peut offrir un développement plus rapide, réduisant ainsi le risque de manquer la date de livraison. Une autre option pourrait offrir d’augmenter la qualité en réduisant le temps d’attente. Une autre solution pourrait résoudre les futurs coûts de maintenance.  En considérant les différents niveaux d’efforts nécessaires, le PO peux maintenant choisir la solution qui a le plus de valeur pour le projet.

4) Fonctionnalités alternatives

Pour chaque fonctionnalité existe souvent plusieurs approches pour atteindre l’objectif, chacune proposant différents niveaux de qualité et d’effort.  Avant d’utiliser cette flexibilité, notez qu’une fonctionnalité alternative inclut fort probablement l’utilisation d’une approche technique alternative (point 3). Par exemple: nous devons donner de l’information à l’utilisateur, mais cette fonctionnalité doit être complétée rapidement. Le PO avait initialement défini une histoire décrivant l’utilisation d’une interface de type popup (histoire de qualité) respectant le style global de l’application. Lors de la création du backlog, l’équipe de développement a aussi proposé une façon plus simple [techniquement] d’écrire l’information dans un espace déjà existant dans l’interface. Appelons cette proposition l’histoire de base. Le PO a maintenant la possibilité d’assurer la livraison de la fonctionnalité en utilisant ”l’histoire de base” et, si le temps et le budget le permettent, il peut toujours prioriser “l’histoire de qualité” plus tard dans le projet.

5) Stratégie de livraison

De façon similaire à la flexibilité de priorisation (point 1), le PO peut déplacer les histoires entre les différentes livraisons planifiées.  Ceci n’est possible que si vous avez plusieurs livraison de planifiées ou si vous déployez régulièrement des fonctionnalités en production. Les inconvénients sont: une possible perte de valeur avec la livraison réduite, l’ajout d’effort dans la livraison suivante risque de créer un effet domino poussant lentement des fonctionnalités vers la dernière livraison, la surchargeant jusqu’à ce qu’elle nécessite un ajustement de portée. Par exemple: Un problème technologique empêche la livraison d’une fonctionnalité prévue dans la prochaine livraison (L1). D’autres fonctionnalités dans cette L1 doivent être livrées à temps. Le PO, en accord avec les parties prenantes, a l’option de déplacer les histoires bloquées dans la prochaine livraison (L2). Ce déplacement d’histoire, bien sûr, va créer un débalancement où moins d’effort est maintenant planifié dans une livraison(L1), alors qu’une autre(L2) est surchargée.  Le PO peut rebalancer cette situation en déplaçant quelques histoires, si certaines sont prêtes pour le développement, de L2 vers L1.

6) Réduction de la portée

Une autre façon d’absorber le changement est la re-catégorisation de certaines histoires afin de réduire la portée de façon générale. Un bonne approche pour ajouter une telle couche de priorisation est d’utiliser MoSCoW: Must(Essentiel), Should(Important), Could(Souhaitable), Won’t(Hors portée). Afin de bien comprendre ce que chacune de ces priorités contient, voici des définitions possibles:

  • Essentiel: Histoires définissant le produit minimum viable (PMV ou MVP en anglais)
  • Important: Histoires nécessaires pour atteindre les objectifs du projets
  • Souhaitable: Histoires de qualité en extras
  • Hors portée: Options (point 4) ou histoire simplement hors portée

Nous pouvons maintenant déplacer des histoires entre ces niveaux de priorisation afin d’absorber le changement. Cette action, toutefois, a un impact directe et immédiat sur la qualité du projet.  Voici un exemple: Un problème de gestion du personnel empêche l’équipe de livrer le MVP à la date prévue. Le PO, en accord avec les parties prenantes, déplace quelque histoires de la catégorie Essentiel vers la catégorie Important afin de respecter la capacité réduite de l’équipe de développement. Il est maintenant possible de livrer la portée réduite du MVP à la date prévue.

7) Compromis de solution technique

La dernière flexibilité du backlog est de changer ou de réduire la qualité de la solution technique dans le but de réduire l’effort nécessaire à la livraison d’une histoire. Si vous êtes poussé à utiliser cette mesure extrême, il reste très peu d’espace avant que vous ne créiez une dette technique dans le backlog qui, à son tour, ajoute de la pression sur les futures fonctionnalités. Étant-donné le contre-coup insidieux de cet effet de cascade dans le backlog, le compromis de solution technique est plus néfaste qu’une réduction contrôlée de la portée et pourrait, si la dette technique est gérée de mauvaise façon, résulter en une ou plusieurs réductions de portée. D’un autre côté, si vous avez la capacité de payer cette dette dans les prochaines itérations, ceci est une option viable afin de sauver une fonctionnalité.  Par exemple: Une date limite critique arrive à grands pas et il n’y a pas assez de temps pour terminer les histoires nécessaires. Ayant épuisé ses options, le PO se tourne vers l’équipe de développement et considère des compromis sur la qualité technologique de certaines histoires, afin qu’elles puissent être livrées à temps. Chaque option est évaluée afin de minimiser les impacts dans le backlog. Les compromis choisis sont mis en oeuvre en modifiant la définition des histoires existantes, en créant de nouvelles histoires pour adresser ces compromis et en créant un plan pour ‘payer’ cette dette pendant les 2 prochaines itérations.

 

Phillipe Cantin

 

 

The 7 flexibilities of the Agile Backlog

How does an Agile Backlog weather the storm and still deliver a cohesive solution?  In great part, it is done through its many levels of flexibility.  A project vision, described in such a backlog, becomes adaptable to many, if not most, of the changes facing the project. Let’s look at those flexibility options by order of their increasing impact on the scope and quality.

1) Priority

A cheap and low impact way of adapting to change is through re-prioritization where, when possible, the simple fact of delivering the stories in a different order can resolve a problematic situation.  For example: we just learned that all the work related to technology XYZ must be completed before a certain date.  To solve this, the PO can frontload the backlog with the impacted stories.

2) Story Splitting

Another low impact way of adapting to change is to split stories into 2 or more smaller stories.  This action often implies a re-prioritization of the resulting stories.  Time wise, this is more involving than a simple priority change, but the overall quality and scope can still be maintained if each part of the split story is delivered.  For example: a story is not ready for sprint planning, because part of it needs further studying.  If possible, the PO can split the story in two standalone stories where the first one is ready for development and the second one remains blocked.  For this to be effective, Agile wise, both stories should add value to the user.

3) Technical Alternatives

Very often, there are many possible technology recipes to deliver a single story.  To prevent impacting the scope and quality, let’s focus on the solutions that are not creating a technical debt (those are covered on point 7).  Many solutions often means many different efforts and quality levels.  This gives choices to the PO, and thus more flexibility to the backlog.  For example: a given functionality is posing a technical challenge which can be resolved in many different ways.  The Development Team can then propose 2-3 approaches to the PO with pros and cons. A solution may offer a faster development time and lessen risk of missing the delivery date.  Another option can improve the solution quality by giving a faster response time. Another solution may reduce future development and maintenance costs.  By also considering the different effort levels of those solutions, the PO can now pick the one with the most value for the project.

4) Feature alternatives

For each given feature, we often have more than just one way to reach the objective,  each one ranging in quality and effort. Before using this flexibility, it is important to know that a feature alternative will most likely include a technical alternative(point 3) . For example: we need to give feedback to the user, but we need this functionality very rapidly.  The PO may have originally defined a popup UI story (quality story) which fits the overall look and feel of the application.  During the backlog creation, the Scrum Team also proposed a [technically] simpler way of writing the message in the existing prompt line of the UI. Let’s call this proposition the “basic story”.   The PO now has the possibility to meet the deadline by using this “basic story” and, if time and budget allow it, can still prioritize the “quality story” later on in the project.

5) Delivery Strategy

Similar to the prioritization flexibility (point 1), the PO can move the stories between the planned deliveries. This, of course, is only possible when you have many planned deliveries or are pushing new features into production on a regular basis. The downsides are: the possible loss in value of the downsized delivery, the added effort in the following delivery could create a risk and the possible domino effect of slowly trickling features into the last delivery, bloating it until it needs to be re-scoped.  For example: A technological problem prevents the release of a feature planned in the next delivery (D1). Other features in the D1 delivery must be deployed on time.  The PO, in agreement with the stakeholders, has the option of moving the blocked stories to the next delivery (D2). This shifting of stories will create an imbalance where not enough effort is planned in one delivery while we now have too much in the other one.  The PO can balance this by moving forward a few stories, if they are ready for development, from D2 into D1.

6) Scoping Down

Another way to absorb change is the re-categorization of some stories to reduce the overall scope. A good way to add such an extra layer of prioritization is the use of MoSCoW; Must, Should, Could and Won’t.  To better understand what each priority should contain, here is a set of possible definitions:

  • Must: Stories defining the Minimal Viable Product (MVP)
  • Should: Stories necessary to reach the project objectives
  • Could: Stretch goals stories
  • Won’t: Optional stories (flexibility #4: Feature alternatives) or out of scope stories

We can now shift stories between these prioritization levels to absorb change.  This action has a direct and immediate impact on the overall quality of the project. Here’s an example:  A staffing problem is preventing the team from shipping the MVP on the required date.  The PO, in agreement with the stakeholders, moves some stories from the Must category into the Should category to match the scope with the reduced capacity of the Dev Team.  The reduced scope of the MVP can now fit into the new delivery date.

7) Technical Solution Compromises

The final flexibility of the backlog is to change or lower the quality of the technical solution in order to lower the necessary effort to ship a given story. When pushed to this extreme measure, there is very little wiggle room before you start creating a technical debt in the backlog, which in turn puts pressure on the remaining functionalities. Because of this insidious cascading effect in the backlog, Solution Compromise is worse than a controlled Scoping Down and could, if the technical debt is poorly handled, result in one or more Scoping Down. On the other hand, as long as you have the capacity to pay back this debt in future sprints, this is a viable option to save a feature.   For example: A critical deadline is fast approaching and there is not enough time to finish all the necessary stories.  Out of other options, the PO turns to the Dev Team and looks for a way to compromise on the technical quality of some stories in order to fit them in the next delivery.  Each option is weighed to minimize the impact on the backlog.  The chosen compromises are implemented by modifying the definition of the existing stories, creating new stories to address those compromises and a plan is made to “pay” this debt in the next 2 sprints.   

 

Phillipe Cantin

 

Laissez un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s