[Nicolas Noullet]

Hi,

That’s a good idea thanks, we will consider that when our current work will be done.

In the meantime, you can select all the stories of the backlog by clicking on the first story of the backlog, press shift and then click on the last one. This will display stats about your stories, including the sum of story points.

[Nicolas Noullet]

Hi,

In order to allow authentication by email as an alternative to the username, two different users cannot have the same email address anymore. You should be able to provide an alternative email address for the conflicting user but it doesn’t work in your version.

This issue is solved in the latest 7.0.4.3 version. You can download it here:
https://www.icescrum.com/download/v7-0/ (jar)
https://www.icescrum.com/download/v7-0-war/ (war)

Upgrade procedure: https://www.icescrum.com/documentation/upgrade-guide/

[Nicolas Noullet]

Bonjour,

Il n’y a pas de mise à jour possible d’une base R6 vers la v7. Il est toutefois possible de migrer et conserver vos données, la procédure est expliquée ici :

Migration Standalone

Vous remarquerez donc qu’il faut donc avoir en parallèle un serveur R6 et un serveur v7, et procéder par export / import de projets pour les migrer. Pour des projets en production, nous ne recommandons pas d’essayer de remplacer l’installation R6 existante par la v7 sans avoir testé avant que tout se passe bien au niveau des projets.

[Nicolas Noullet]

Bonjour,

Cela fait effectivement un mois que nous vous avons dit « dans un mois »,la migration du standalone est prête, la doc n’est juste pas encore publiée (j’ai essayé de vous l’envoyer par email mais apparemment le domaine n’existe pas…).

La migration du Cloud devrait arriver dans les jours qui viennent.

[Nicolas Noullet]

Hi,

Apparently you try to install different versions of iceScrum and it will be very hard to help you if you mix things up.

If you have not managed any real data with iceScrum yet, please start by stoping and deleting everything related to iceScrum : all icescrum.jar and these two directories
C:\Users\kempegow\icescrum
C:\Users\kempegow\.icescrum (may be hidden by default in your file explorer but I guarantee that it is here and that you must delete it).

Rebooting your system might ensure that iceScrum really stopped.

Then and only then, please download iceScrum V7 here: https://www.icescrum.com/your-new-icescrum/. Then, start with the command you tried here: https://www.icescrum.com/forums/topic/have-1-7-and-1-8-jdk-installed-installation-fails/.

If it doesn’t work, please don’t do anything else and provide the logs.

[Nicolas Noullet]

Glad that it is enough for you. Actually, this is the expected behaviour as described in the documentation: deleted people might have worked on the current sprint so removing them could be wrong, that’s why they are only removed from upcoming sprints.

We did not manage to reproduce the issue so it is hard to fix at the moment. However, the new version of iceScrum that will be available soon changes a lot under the hood and hopefully the issue will be gone.

[Nicolas Noullet]

That’s really strange, can you check is there is any error in the logs at the time you add them back? (catalina.out and icescrum.log)

Another approach you can try is disabling and then enabling availabilities again. Be careful, you will lose every availability entered for the sprints after the current one.

You can also upgrade to R6#14.11 which offers a new availability + remaining time burndown chart:

[UPDATE] Version R6#14.11

Upgrade guide

[Nicolas Noullet]

Hi Boyd,

Thanks for the clear and detailed explanation!

I agree that the task burnup chart is probably the most valuable of the charts offered by iceScrum in your case. The tendency of the curves is not relevant, as they will grow or stay constant even if works is achieved. However, if you forget about that, the chart still shows the equivalent of total task percentage achievement every day, which may be a good indicator for sprint completion. The thing that is missing as compared to your solution is the weighting of tasks according to the points of the stories they belong to, which we are cautious about because it really depends on the practices of the teams (how they estimate stories, how they split them into tasks etc).

Cheers,

Nicolas

[Nicolas Noullet]

Hello,

Are you using iceScrum on your own server or on our Cloud platform? If the former, which version?

Team members updates are expected to be reflected in the availability table, as explained here: https://www.icescrum.com/documentation/availabilities/#team-updates, so you may have come across a bug.

Can you try removing/adding members again?

[Nicolas Noullet]

Hi,

These logs correspond to the startup of iceScrum v7, which is compatible with both Java 1.7 and 1.8 so this is not the cause of the issue.

The error is provided at the very beginning:
Address already in use: bind

It means that another application already uses port 8080 on the host 10.193.115.150. It’s either another application or another iceScrum started in another command. Start iceScrum on another port like so:

java -Xmx512M -jar c:\icescrum\icescrum.jar port=8081

[Nicolas Noullet]

I understand that your context make it difficult to follow the progress of your team and I am willing to help. However, based on nearly a decade of experience in agile project management, I expressed my doubts regarding the solution you suggested.

Here is what I suggested instead:

the ScrumMaster and the team should focus on daily standup meetings, discussions and visual management through the task board evolution in order to keep track of the sprint advancement and forecast failure to deliver stories on time.

I don’t know how you came to the conclusion that I suggested to either start using task estimates or follow only the story point charts, I did not say anything close to that.

Let me reformulate my suggestion: the very best way to follow the advancement of a sprint and the likelihood to finish stories is by looking at the task board on a daily basis and foster communication with and within the team. Transparency, communication, collaboration, inspection etc. (e.g. through visual management and meetings) are the very fundations of the agile philosophy, while charts and estimates are only additional and optional tools that may or may not assist in the process.

The above addresses the fact that you have hard time following the progress of your team. Another point that I would suggest to address is what motivates the need to follow the progress of the team, which is perhaps a tendency to fail to deliver what is planned? If this is the case, this should be addressed too and hopefully the need to follow closely the progress of sprints will fade over time as everybody involved gain confidence in the ability of the team to deliver stories.

[Nicolas Noullet]

Merci pour ce retour. Ceci dit, si la base source et destination ont la même case sensitivité, normalement pas de problème.

[Nicolas Noullet]

Hi,

As you explained, sprint burnup and burndown charts in number of tasks or task remaining time lose relevance when tasks are added / remove throughout the sprint.

However, what you suggest has a few flaws:
– introducing a magic formula between number of tasks (or remaining time?) and story points is questionable
– even with your proposal, adding tasks to a story would have an impact on the chart by lowering the « achieved points », removing tasks on the other hand would increase achieved points, which would result in a curve very similar to the one you get from tasks alone.

I am afraid that there is no really good indicator for sprint progress if tasks are not created accurately in advance, which is the case when there is high uncertainty. In such case, the ScrumMaster and the team should focus on daily standup meetings, discussions and visual management through the task board evolution in order to keep track of the sprint advancement and forecast failure to deliver stories on time.

By the way, in iceScrum v7, a % of advancement is displayed on « in progress » stories, which is computed according to task completion but there is no impact on story points.

[Nicolas Noullet]

Bonjour Christophe,

En fait la sensibilité à la casse dans le cadre de la contrainte d’unicité ne dépend pas d’iceScrum mais de la configuration de la base de données sous-jacente.

Quel SGBD utilisez-vous en version 6?

En tous cas je vous confirme que la migration d’une base sensible à la casse vers non sensible pose problème, indépendamment de la version d’iceScrum.

Les utilisateurs ne sont pas les seuls concernés. En effet, d’autres contraintes d’unicité, tels que le nom des stories peuvent également poser problème si par exemple le même nom a été utilisé à la casse près pour deux stories du même projet.

Pour le moment il n’y a pas de solution automatisée pour régler ce problème, ceci implique donc de faire le ménage lors de la migration.

[Nicolas Noullet]

You are right, the integration is projectwise!

Recent versions of iceScrum are expected to work with the latest versions of Jira.

I contacted you in private to discuss you specific needs.

[Auteur]

Messages