[Nicolas Noullet]

Hi,

Thank you for the report and sorry for the bot spam.

There is indeed a consistency issue in the way dates are formatted.

Some inconsistencies are due to the fact that historically iceScrum rendered some content in the backend. Thus, dates are formatted partly according to the locale defined on your profile.

You can change it to “English” (the default one for several years now) instead of “English (United States)” so that all the “03/18” will turn into “18/03”.

We added an item to our Product Backlog to register the need for more consistency.

[Nicolas Noullet]

Bonjour,

Le problème peut venir de l’utilisation de MariaDB, qui est un fork de MySQL pas forcément 100% compatible.

Nous recommandons l’utilisation de MySQL 5.7. La version MySQL 8 n’est pas supportée.

[Nicolas Noullet]

Bonjour,

Juste pour être sûr, le fichier doit s’appeler “config.groovy” et non “groovy.config” !

De plus, il est parfois difficile à manipuler à la main, vous pouvez si vous le souhaitez prendre une licence d’évaluation Enterprise le temps d’utiliser l’interface d’administration https://www.icescrum.com/documentation/server-administration/

Cette interface propose notamment un bouton de test de la connexion au serveur mail qui aide à débugger la configuration.

Je vois au moins un problème dans votre configuration. Le serveur SMTP Gmail requiert une connexion SSL, il faut donc décommenter l’avant dernière ligne.

Cependant, ce n’est pas suffisant. Gmail comporte maintenant des sécurités et par défaut votre nom d’utilisateur et mot de passe ne fonctionnera pas.

C’est totalement indépendant d’iceScrum, il vous faut donc vous rapprocher du support de Gmail et de leur documentation. Il faudra notamment agir dans la configuration de sécurité de Gmail, soit en autorisant les applications non sécurisées à se connecter, soit en définissant un mot de passe dédié (mais de mémoire il faut avoir activité l’authentification à deux facteurs pour cela).

[Nicolas Noullet]

Bonjour Thibault,

Merci pour votre message détaillé, nous en comprenons très bien la teneur car c’est une reflexion que nous avons eue lors de l’implémentation de ce graphique il y a maintenant plusieurs années.

Votre interprétation est bonne : la courbe représente le reste de disponibilités en début de journée. Il aurait été trop complexe et trop peu fiable de rendre ce point dynamique au fur et à mesure de l’avancée de la journée, donc nous étions face à deux options : prendre le reste de disponibilités en début de journée, ou en fin de journée, et nous avons choisi la première.

Concernant votre pratique : “nous utilisons la courbe idéale comme une cible de fin de journée”, la question n’est pas si simple. Elle mérite reflexion, indépendamment de comment est générée cette courbe “idéale” (ici par les disponibilités, ou juste une droite partant du total).

Le problème vient du fait qu’on considère en général comme idéale la droite décroissante partant du total et allant jusqu’à 0. En fait conceptuellement elle est idéale dans le sens “dans un monde parfait”, mais elle n’est pas idéale dans le sens “il faut coller à la courbe”.

En effet, la courbe implique une utilisation à 100% des “ressources”, ou dit autrement elle ne prend en compte aucun mou, aucune marge de manoeuvre. Cela veut dire qu’au moindre écart on est au dessus de la courbe et on risque fortement de ne pas finir le travail prévu à la fin du sprint.

Ainsi, une vraie courbe “idéale à suivre” serait plutôt une droite qui terminerait quelques jours avant la fin du sprint (le nombre jours par rapport à la durée du sprint représenterait alors le mou qu’on se donne). Cependant l’intérêt d’une telle courbe seule serait limité : si on passait au dessus on aurait alors du mal à voir si on peut encore finir.

Le plus intéressant serait donc de combiner les deux et de créer une zone entre ces deux courbes (la vraie courbe idéale + la courbe qui va à 0 au dernier jour) et ainsi bien montrer la “cible”.

Pour en revenir à nos disponibilités, d’après ces observations elle ne doit pas constituer une cible. Elle représente les disponibilités restantes, c’est tout. L’objectif serait d’être assez largement en dessous, surtout au début du sprint, afin d’avoir du mou. Notre outil incorpore d’ailleurs cette notion de mou sur les disponibilités mais elle n’est pas prise en compte dans le graphique pour limiter sa complexité.

Et pour revenir à la question initiale, dans la pratique les Daily Scrum se font très souvent le matin pour faire le plan d’action de la journée. Si on regarde le graphique à ce moment là et compte tenu de notre choix, alors il montrera le travail total restant ainsi que les disponibilités totales restantes pour la même durée. Par contre au fur et à mesure que la journée avance les données ne seront plus synchronisées. Il n’est pas certain que l’on referait le même choix aujourd’hui, mais compte tenu des équipes qui ont pris l’habitude de l’utiliser, le changer aurait probablement un coût supérieur à la valeur apportée.

Dans tous les cas nous ne recommandons par d’altérer les saisies pour que la courbe tombe bien à zéro, car elle n’est effectivement pas censée y arriver dans l’état actuel des choses !

Pour résumer : la fonctionnalité est certainement imparfaite mais pas autant qu’elle peut le sembler. De plus, indépendamment de cela, je vous recommande de changer la manière d’interpréter les courbes soit disant “idéales”, non plus comme une cible mais une barrière dont il ne faut pas se rapprocher !

[Nicolas Noullet]

Hi,

Acceptance tests have a rich text field where you can enter anything, including a scenario outline. However, the resulting tests are not computed automatically.

You can access Acceptance tests from the API in order to use them and process them externally (https://icescrum.com/documentation/rest-api).

[Nicolas Noullet]

Hi,

Stories cannot be assigned to developers, and they should represent units of value provided to user, so they do not necessarily reflect the software architecture: one story can require both backend and frontend activities. Such stories are the responsibility of the whole team.

On the other hand, one task represent one activity, so it can be assigned to one developer (usually self-assigned rather than assigned by someone else, in order to follow the principle of self-managed team promoted by Scrum).

[Nicolas Noullet]

Bonjour,

J’ai demandé la quantité de stories parce que si c’est normal que la requête prenne un temps proportionnel au nombre de stories, le temps que vous évoquez n’est pas du tout représentatif de ce que l’on constate normalement, on est plutôt à moins d’une seconde pour 100 stories sur un serveur configuré de manière nominale.

Il doit y avoir un problème relatif à votre serveur. Je vais vous contacter par email très prochainement pour la suite du support, cela sera plus adapté.

[Nicolas Noullet]

Bonjour,

Pour ce qui est de l’optimisation de la requête, la plupart des données qui prennent du temps à charger sont celles qui sont justement sur le post-it…

Mais pour envisager des pistes adaptées à votre contexte, combien de stories avez-vous dans les backlogs qui prennent plus de 10 secondes à charger ?

[Nicolas Noullet]

Hi,

Sure feel free to share it on the forum, this would be a great contribution to help the community! Thank you 🙂

Unfortunately turning that into an official guide is not a piece of cake: if we do ubuntu we should do redhat, windows server, for every DBMS, ensure that everything stays up to date, translate it in 3 different languages etc. That is why we do not provide precise guidance on how to configure external tools and we rather rely on the fact that they provide their own official documentations.

[Nicolas Noullet]

Different logs but same error, and same origin!

You can find the tables because part of it is supported, but it is bound to fail eventually. Downgrading to Postgres 11 should do the trick.

[Nicolas Noullet]

Hi,

I have edited your logs in order to reduce noise and avoid disclosing unnecessary information about your setup.

As you can see in what remains, you had two different errors.

The first one seemed to be related to a network issue between iceScrum and your PostgreSQL server. It seems that you managed to solve it as in the next restart we can see that iceScrum managed to reach it.

The second error happens when iceScrum sets up the databases on PostgreSQL. You get this error because you likely use a PostgreSQL version that is not supported by iceScrum, e.g. PostgreSQL 12.

iceScrum supports PostgreSQL version from 9.x to 11.x, see our documentation.

[Nicolas Noullet]

Hello,

I am afraid that this error message does not tell much about what the error actually is. There should be another error before this one. Can you enable verbose logging and restart iceScrum again?

You can enable verbose logging by setting the following in the config.groovy file:
icescrum.debug.enable = true

[Nicolas Noullet]

Merci pour la suggestion, c’est ajouté dans notre Backlog 🙂

[Nicolas Noullet]

Hi John,

Sorry I thought I had answered, probably never clicked on “Submit”…

Value and Rank are différent things. As I said in the other thread, the Rank is the position of the item in the regular Backlog sorting order, which means that the story at the very top left is Ranked “1”, then the next is “2” etc. You can think of it as Music Charts, number 1 is the best !

[Nicolas Noullet]

You are welcome 🙂

[Author]

Posts