[Nicolas Noullet]

Hi,

The chart should match the sprint actual duration (from activation to closing) and don’t match the manually entered « start date » and « end date ». The former are the boundaries of the period where updates can occur in the sprint, whereas the latter are only expected dates.

That may be the reason why the dates don’t match what you expect?

[Nicolas Noullet]

Kelvin,

I was wrong regarding the link between the unique constraint error and the sprint closing, and I’m glad I was because we now know the cause!

Here is the expected behavior regarding name uniqueness: if a task has a parent story then the task name must be unique in the context of the story, otherwise (urgent or recurrent task) there is no constraint. As you aptly remarked, the « otherwise » case is materialized by a NULL parent_story_id in the icescrum2_task table.

In the ANSI SQL standard, the unique constraint does what we want out of the box: every pair (name, parent_story_id) with a same name and a NULL parent_story_id, such as (« someTaskName », NULL), is considered to be different thus avoiding unique constraint violation. Unfortunately, SQL Server treats NULL as any regular value so two pairs (« someTaskName », NULL) are considered the same and any attempt to create the second pair raises a constraint violation.

The problem is that we use high level abstractions to support a wide range of DBMS and they don’t take into account this peculiarity.

In fact, this leads to the requirement that every urgent / recurrent task name is unique not only at the project level but at the whole server level! 🙁

The way to fix that consists in identifying and removing the existing uniqueness constraint on task name and replacing it by a unique index on the name and parent_story_id columns with a where clause such as WHERE parent_story_id IS NOT NULL. Of course, before doing that, I advise that you back up your DB.

Here is some related reading: http://sqlmag.com/sql-server-2008/unique-constraint-multiple-nulls. By the way, I recently discovered that Oracle behaves like SQL Server…

If you can provide the working SQL queries, we will add them to our documentation!

[Nicolas Noullet]

1. The message in your logs indicates an issue when creating tasks. The task name uniqueness constraint is actually enforced way too rigorously on SQL Server (because it deviates from the SQL standard regarding how nulls are managed for such constraints, I can tell you more about that if you want and even provide a workaround). Unfortunately, I think that task creation does not occur at sprint closing but probably rather comes from the activation of the next sprint afterward.

2. It’s hard to refrain from manual data tweaking, but it’s very hazardous! If you don’t come across new weird issues then I suggest not removing the « fake » stories for the moment to prevent any more significant change. However, you may update the sprint velocity manually (a simple field in the icescrum2_sprint table) after a DB backup, which should be enough to make your release plan look as it should.

3. Sure, but I hope it will go better this time!

Nicolas

[Nicolas Noullet]

Hello Kelvin,

First, I would recommend to upgrade to the latest version: R6#14.11 in order to benefit from the latest features and bug fixes. Here is how to do so: https://www.icescrum.com/documentation/upgrade-guide/.

I am glad that your team enjoy using our tool and I am sorry for the inconvenience caused by this issue.

The expected behavior is that the sprint closing is atomic: it should either work entirely or fail without updating the data. Here I think that something is failing but the error remains « silent », causing some stories to be « half-processed ».

There are three things to think about:

1. Understand the issue: we need to know more about the stories. Do they have tasks and acceptance tests? Do you have the logs (icescrum.log / catalina.out) for the moment when the sprint was closed?
2. Fix the existing data: you analysis is correct! Manual DB update come with great risks, that’s why we usually strongly advise against them. If you really want these stories back in the UI then we can update the data for you if you send us a dump of your DB.
3. Avoid the problem in future sprints: if step 1 leads to the fix of a bug then this will do it. In the meantime, a way to avoid the issue would consist in removing as much work as possible from the sprint closing: that means passing manually every done task to done, then every done acceptance test to done, then every done story to done, then switching to the next sprint any not done story, and finally closing the sprint

Nicolas

[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.

[Nicolas Noullet]

De nada Fábio, hasta luego 🙂

[Nicolas Noullet]

Hi, sorry for the late reply.

There is no documentation that explains how to migrate from icescrum.jar to icescrum.war because every case is different. Sometimes, it will just work out of the box depending on your environment and how you configured it.

In addition to the DB, iceScrum needs files on your filesystem. In most cases, the paths for these files can be configured but if you leave the default location then they depend on the start path of iceScrum and on the user who starts iceScrum. Moving from icescrum.jar to icescrum.war may change one or both of these contexts.

If you use an external DBMS (such as MySQL) then ensuring that the old config.groovy file is taken into account by your new installation should be enough.

If you use the default database (this is strongly not recommended, as stated in our documentation) then your data is stored under prodDba.script and prodDba.properties file in the start path of iceScrum.

If you want the old data to be taken into account in the new installation, first backup every prodDba file to be sure to avoid losing your data, don’t skip the backup step! Then the easiest way to do so is looking for the new prodDba files on your filesystem and replacing them by the old ones.

[Nicolas Noullet]

If you install it on Tomcat 7, iceScrum also requires Java 6 or 7.

The install documentation used to be one document but it has been split into two and the information has not been duplicated. It is now duplicated to avoid any confusion: https://www.icescrum.com/documentation/application-server/

[Nicolas Noullet]

Hi,

You can change the user data (first name, last name, email address) form the user itself, but disabling and deleting through the UI is available only in iceScrum Pro.

We strongly advise against any manual change to the DB, it can seriously break things. As a side note, iceScrum creates a default DB with its embedded DBMS (HSQLDB) but as stated in the documentation, this is not suitable for production, we recommend the use of a proper external DBMS such as MySQL.

• Cette réponse a été modifiée le il y a 6 années et 5 mois par Nicolas Noullet.
• Cette réponse a été modifiée le il y a 6 années et 5 mois par Nicolas Noullet.

[Nicolas Noullet]

Merci pour ton retour, content que tout fonctionne à présent !

[Nicolas Noullet]

Merci pour ton retour, content que tout fonctionne à présent !

[Nicolas Noullet]

Bonjour,

Si j’ai bien compris, vous testez notre solution en ligne ?

Il est possible de créer une équipe avant la création de projet, ce qui permet de trouver plus facilement un nom disponible sans avoir à faire aller-retour : menu « My teams » > « Manage » (« Mes équipes » > « Gérer » en Français).

J’ai essayé Magelan et le nom est disponible, l’équipe s’est bien créée.

Après l’avoir créée, vous devriez la retrouver dans la liste déroulante lors de la création d’un projet.

[Nicolas Noullet]

Hello Francisca,

As shown on the video Part 3, stories are created in the Sandbox, not in the Backlog. Once created in the Sandbox they can be then accepted to the Backlog.

Then, Backlog stories must be estimated as shown in Part 4 so they can be planned into Sprints, for instance in the Release Plan view as shown in Part 5.

To sum up the beginning of the story workflow:

1. Sandbox: Create
2. Sandbox: Accept to backlog
3. Backlog: Prioritize (optional)
4. Backlog: Estimate
5. Release Plan: Plan story from backlog widget to sprint

An estimated story can also be planned into a sprint in is « update » form. This is the regular workflow from the free version, there is a slight difference in iceScrum Pro where you an alternatively create stories directly in the Backlog, skipping the Accept step.

[Nicolas Noullet]

Hi,

Thanks for your contribution and sorry for the delay, we now focus most of our efforts on iceScrum 7.

The index is now created automatically on most DBMS (including MySQL) when you install the latest version (R6#14.11). Thus, you can delete your custom index before upgrading.

[Nicolas Noullet]

Hi Francisca,

Tomcat 7 is the way to go. Can you check the logs? (catalina.out and icescrum.log) and send us any error you find to help find the problem?

[Auteur]

Messages