iceScrum Forums Discuss on iceScrum

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.

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 !