Edit: Previous R6#13 versions are replaced by R6#13.8. We recommend that you update in order to benefit from the following changes:
After Mantis BT and Bugzilla, here comes the Trac integration! You can now import stories automatically from Trac issues and define rules to update the issues according to the changes made on the corresponding stories. More integrations will come soon, stay tuned!
We know it’s been a long time since the previous release but please let us know that we don’t forget you! Actually, we are designing a brand new iceScrum! Here is a glimpse of the new sandbox with custom post-it color:
We would be please to hear your feedback! Stay tuned, there is more to come…
Here comes a new version of iceScrum and iceScrum Pro!
The R6#13 version brings some important bug fixes. We also developed a few improvements that should please you while waiting for the big changes that will come in iceScrum R7!
At first, we expected the previous version (R6#12) to be the last of the R6 series. However, we take all the time that is needed to experiment the ideas gathered last months and ensure that the new interface will make using iceScrum much more easier and pleasant. In the meantime, we don’t want to leave you with annoying bugs so we decided to release another R6 version.
We promised additional bug trackers, after Mantis BT here comes the Bugzilla integration! You can now import stories automatically from Bugzilla issues and define rules to update the issues according to the changes made on the corresponding stories.
Until now, story estimates had to be chosen from either the Fibonacci or the Integer suite, there is now a third option called “Custom values”. Will still strongly recommend the use of the “story points” empirical unit for story estimates. However, it is now entirely up to the teams to choose the values that are meaningful to them.
When custom values are enabled, you can estimate stories by typing any value between 0 and 999.99, with a precision of two decimal places.
Warning: if you use the iceScrum Pro availabilities and if your projects has a negative offset from UTC, which is the case of most projects based in America, then you should read the following:
If your project satisfies these two criteria, then the dates displayed in the availabilities table header are likely to be shifted by one day backwards. Despite being only a display bug, it has annoying consequences.
Here is an example: given a sprint from 11th march to 17th march, the table has 7 columns. The first column corresponds to the 11th and the last column corresponds to the 17th. However, if you project had a negative offset timezone, then the first day is mistakenly labelled 10 and so on until the last column labelled 16.
If your team has entered the availabilities according to these labels (this is likely to be the case) then all the availabilities are also shifted by one. When upgrading to R6#13, the column formerly labelled 10 will be labelled 11, and so on for every day. Consequently, we strongly recommend that your teams check the availabilities entered for current and upcoming sprints and update them accordingly.
We considered an automatic way to fix the values, which would have required moving data around between sprints. However, such an automatic fix would have no way to figure out how your teams may have worked around the issue. Because of that, an automatic data fix may cause additional troubles on top of the identified bug, leading to an inextricable mess. Thus, we abandoned this solution.
We relaxed the permissions so the Scrum Master and the Product Owner can now update availabilities for done sprints and correct the availabilities wherever it is needed (see the improvements section above).
We are sorry for the inconvenience. If you have any question or if you want more information before upgrading, feel free to contact our support team, we will be pleased to help you.