Add column to kanban

[Gus]

Hello,

in community edition, how to add one column to kanban board? I need add one column « in testing » .
It`s is possible? how to?

Thanks in advance.

Gus.

[Nicolas Noullet]

Hi Gus,

There is no way to add columns to the task Kanban board in iceScrum (both Community and Pro). This is no accident: after many discussions, such feature appears to more harm than good. Here a few reasons why.

It is very beneficial that tasks remain small in size and lead time (time from « Todo » to « Done »).

Avoiding adding steps help prevent « stock » and things kept in stock don’t provide value. In iceScrum, value is produced when stories are done, which requires all its tasks to be done.

Even if Scrum doesn’t provide engineering practices per se, it is recommended to avoid separating development and technical testing activities. This is enforced by practices such as TDD (Test Driven Development).

Thus, a good task would consist in a small unit of development that includes both code and test update without distinction, technical testing (unit tests, integration tests, property-based testing) being part of the development process.

However, if you really need or want to add the « in testing » information on a task, you can do so by changing its color (which has not predefined meaning) or add a tag.

Functional testing is a different matter: it occurs at the story level. It usually cannot be avoided as a separate activity because developers are not in a good position to validate business aspects. Thus, we have plans to add an optional story « Testing » step as part of a new Story Kanban board.

[4sStylZ]

Bonjour,

Je parcours un peu le forum et constate que vous privilégiez la simplicité et les bonnes pratiques agiles, conseillées par les grands guides.

Pour notre part (Je parle au nom d’une équipe de dev) le workflow a été personnalisé grace à 3~4 ans d’itérations sur l’adaptation de la méthode et il ressemble à ça :

* Todo
* Stucked. Cette colonne est la plus sujette à débat. Elle permet de savoir quels sont les équipes / clients / contacts à relancer pour être débloqué sur un sujet. La laisser à In progress nuirait à la lisibilité car certaines taches restent bloquées pour des raisons qui semblent à notre équipe parfaitement rationnelles et maitrisées. Si des taches saturent cette colonne alors le PO et le SM sont là pour veiller à ce que les relances soient faites.
* In progress.
* Waiting for validation.
* In validation.
Ces deux lignes sont là car nous pratiquons la recette croisée. Un dev ne peut merger qu’une tache d’un autre dev. Ce va-et-vient produit par l’audit croisé permanent doit être parfaitement lisible. La fluctuation todo ↔En attente de recette ↔ En cours de recette doit être parfaitement claire sans que les devs n’aient à penser à avertir qu’une tache est disponible pour de la recette ou revient en cours de recette.
* Waiting for delivery. Nous sommes presque en rolling-release mais nous ne pouvons pas nous permettre de délivrer à chaque feature. Nous faisons un lot d’US / de taches, petit si-possible qui lui est livré (environ 3~5 livraisons par sprint de 2 semaines). Pourquoi ne pas mettre ça dans la colonne « In Progress » : Parce que la lecture de cette colonne serait impossible. En trois ou quatre jour il est possible d’avoir bien trop de tache In-progress et c’est pour des raisons techniques d’infra que nous ne pouvons pas livrer en continue. Pourquoi ne pas mettre ça en done ? Car il faut identifier ce qui est livré de ce qui ne lest pas pour préparer des changelog au moment de la livraison
* Done.

Ce workflow « To do → In progress → Done » est pour nous une utopie, a été testé, et ne fonctionne pas chez nous. Pour utiliser IceScrum, nous devrions, j’imagine, utiliser des tricks avec des labels mais cela ne correspondrait pas à notre véritable workflow.

Je crois que c’est entre autre pour cette raison que nous avions migré d’Icescrum à VivifyScrum.
Je vous encourage donc à y songer.

[Nicolas Noullet]

Bonjour,

Merci pour ce commentaire très détaillé et bien étayé. A ma connaissance c’est la première fois que nous recevons un argumentaire qui tient la route pour motiver la possibilité d’ajouter des colonnes dans le Kanban des tâches !

D’après notre expérience, les pratiques de validation / review / merge / recette / déploiement varient énormément d’une équipe à une autre et à ma connaissance aucune méthode ne structure l’ensemble de ces points. Ils dépendent du produit développé, des technologies utilisées, de la maturité de l’équipe, des pratiques d’ingénierie, des outils…

Certaines pratiques suscitent des états intermédiaires. Un des dangers de créer des colonnes dédiées et que cela vient légitimer ces états intermédiaires, ces « stocks » qui coûtent à l’équipe car ils n’apportent pas encore de valeur. Dans Kanban, la reduction de nombre de colonne est d’ailleurs vue comme une amélioration. Bien sûr, des contraintes externes rendent parfois la tâche compliquée, par exemple un déploiement en continu sur une infra matérielle embarquée paraît impossible. Par contre sur l’exemple des blocages, si il est fréquent d’avoir des tâches « stucked » alors cela est un vrai frein à l’agilité de l’équipe. Il serait intéressant de remonter la chaîne des causes de ces blocages et de les prévenir plutôt que d’avoir à les subir.

Comme vous l’avez noté, iceScrum peut supporter un workflow plus riche via par exemple les couleurs des tâches (personnalisées et bientôt associées à un label), ou les tags. Le fait qu’une tâche est bloquée est également représenté dans iceScrum, mais cela vient effectivement remplir la colonne « In progress ».

Comme vous l’avez également noté notre positionnement est différent de nos concurrents, dont certains sont plutôt des gestionnaires de ticket avec une sur-couche agile, d’autre des outils agiles plus orientés sur Kanban que Scrum. Nous prenons bien sûr en compte vos retours dans les perspectives d’évolutions d’iceScrum. En attendant, compte tenu de vos pratiques, un outil plus orienté Kanban semble plus approprié.

Bonne continuation !

[Auteur]

Messages