iceScrum v7 is coming! Click here to see changes and download it! Enjoy

Version 7 Beta 7


Here comes iceScrum 7.0.0-beta.7.

This version brings the “Team availability” feature back, making a new step towards a final release. It works as before, including the recent addition of the useful Sprint Burndown Chart that compares the remaining time to the remaining availability.

Team availability

Apart from that, this new beta also fixes a few bugs and improves the overall performance of the application.

For any feedback (improvements of defect), you can create a story in our Sandbox: If you have any question, let us know in the comments section below!

We are now implementening the last “must-have” features so are now very close to the functional scope we want for a first public release!

Thanks for all the great feedback we receive. We are very glad to know that this version will be enjoyed both by our longstanding users and the newcomers.


Here is a new iceScrum 7: 7.0.0-beta.6.

A promised, after Git/SVN integration we worked on another big iceScrum Pro feature: integration with bug trackers, namely Bugzilla, Jira, Mantis, Redmine and Trac.


These integrations work quite like before (here is the old documentation for reference:

A nifty addition is that you can now apply a story template (including features, tags, tasks and acceptance tests…) to stories imported from your bug tracker. For the record, story template allow prefilling stories with data taken from an existing story which serves as a model.

Open your project settings and configure your integration!

Import rule from bugzilla

This version comes with other improvements:

  • The “Home” menu is now included in the title bar to be readily at hand when you need it
  • The “Dashboard” menu title has been renamed to be the project name
  • The first menu (you can change menus order by drag and drop from the menu icon) will be opened by default when opening a project
  • Better error handling on the server side
  • Better error handling and rendering to end users
  • Better visual clues for story selection in the task board
For any feedback (improvements of defect), you can create a story in our Sandbox: If you have any question, let us know in the comments section below!

We took some time since the last release, partly because we also released a maintenance version of iceScrum R6 (R6#14.11) and we moved our main office to an awesome new location, you may hear more about it soon!


A new iceScrum 7 beta is here: 7.0.0-beta.5.

As planned, this version comes with Source Code Management and Continuous Integration (Git, SVN, Jenkins…).

For the moment, they work like before (here is the old documentation for those who don’t know about these integrations: Git & SVNJenkins).

That means that you can know link your commits to iceScrum Tasks and Stories and get the latest build status on your project Dashboard!

A commit linked to a task
A commit linked to a task

We did not choose this feature by accident, in the “Eating your own dog food” mindset we can now link our commits to our public project.

Try this version on

For any feedback (improvements of defect), you can create a story in our Sandbox: If you have any question, let us know in the comments section below!

We plan to continue releasing big features to get closer to the general availability, stay tuned!


The fourth version of iceScrum 7 beta is now online: 7.0.0-beta.4.


  • Velocity, capacity & remaining time in Task board
  • Medium post-its by default in backlogs and features view

Bug fixes:

  • Loading logo has no color on IE11
  • On IE11, when displaying details panel, details info are not displayed and post-it layout doesn’t adjust
  • Missing post-it color on IE11
  • Too large details panel on firefox
  • Tab is lost when selecting a story from another in the task board
  • Project validation error is duplicated
  • Validation errors for project name/key and user username/email aren’t explained
  • Wrong ID on feature post-it
  • “In progress” urgent task limit prevents moving any task to “in progress” regardless of the actual limit
  • Emptying a field with rich text doesn’t isn’t effective without refreshing the UI

Open to try this version!

For any feedback (improvements of defect), you can create a story in our Sandbox: If you have any question, let us know in the comments section below!

As promised, we try to push the pace of releases. After making the beta more robust, it’s time to bring big features to get closer to the general availability. Our next sprint is dedicated to porting and improving the SCM integration (Git, SVN, Jenkins…) feature! Stay tuned!


Here comes a third version of iceScrum 7 beta: 7.0.0-beta.3. Unlike previous versions, this one doesn’t bring much visible changes. However, we worked a lot under the hood to provide more consistency and stability. Here are the main improvements and bug fixes:


  • Big overhaul of error management
  • New order in story and task details view to better follow the workflow
  • Better defaults for post-it size in Planning and Task board views

Bug fixes:

  • Task name is too short in details view when the task is done
  • “Context” search by tag / feature doesn’t work properly in Task Board
  • Missing color in table view

Open to try this version!

For any feedback (improvements of defect), you can create a story in our Sandbox: If you have any question, let us know in the comments section below!

We took some time to release this version because of holidays. We should now publish news and improvements at a faster pace, stay tuned!

A week ago, we were glad to publish the first Beta of the version that embodies the future of iceScrum!

iceScrum Version 7 Beta

If you did not hear about it yet, you can read the blog post named “A bright future for iceScrum”.

First, we would like to thank our early users for their encouraging and insightful feedback! We are glad to see that you like this new version and we will do our best to make it even better thanks to your comments.

If you haven’t tried it yet, just use your existing account (or create one, it’s free!) and open

A sample project is automatically created for you and you can play with as you want. This version is free and unlimited and it will not affect your existing subscriptions in any way. Thus, you can also freely create new projects. Just keep in mind that we may not be able to keep your data as this is still an early stage of the Beta.

Release pace

We will try to keep a good pace by releasing new versions often and keeping you updated through blog posts such as this one.

This new version is the occasion to adopt a clear and broadly use version number pattern, inspired by Semantic Versionning. It should help keep up with version updates.


Speaking of updates, we have just deployed the first update of the Beta version: 7.0.0-beta.2. Here are the main improvements and bug fixes:


  • Change and remember display mode for core items: post-its (several size) or table rows


  • User avatar in project context has a border colored according to the user role
  • Sprint list dropdown in Task Board to easily switch between sprint
  • Automatically hide done tasks if more than 4 of them to focus on current work
  • Caret on post-it “gear” icon to make it clear that it’s a menu
  • Display suggestions of stories with similar name when creating a story
  • Improve automatic focus on form after submitting data to avoid unnecessary clicks
  • Remove previous state from browser history after removing an item
  • Display star icon on story post-it only when the use follows it to reduce visual noise

Bug fixes:

  • A registered user cannot create stories on a public project
  • Links in notifications are broken when not in a project
  • Deleting a sprint with not done tasks fails
  • Sprints duration is one day more than the configured duration
  • There is no way to change the default sprint duration for a project
  • The “Auto planning” menu should not be listed on a “in progress” sprint
  • List of stories candidate to be planned don’t follow the backlog priority order
  • Flickering when selecting a story after deleting another one
  • The UI is not refreshed on mobile networks that use cache
  • Missing i18n
  • Changing the feature of a story causes the UI to freeze
  • Removing tags from an item require refreshing the page to be visible
  • “Unauthorized” error doesn’t properly redirect to the home
  • Effort field not displayed in details just after accepting a story
  • Various UI fixes

Go to to try this version!

What’s next?

The beginning of the Beta stage was dedicated to ensure that everything works smoothly.

The first results are really encouraging and so we are preparing the Roadmap to inform you about the steps that will lead to the general availability!

Any comment or question about this version? Let us know in the comments section below!

After years helping companies to adapt their practices and change their mindset toward agile values, a comment we hear very often is “Ok, we know that we don’t follow the recommendations… But our context is quite singular and Agile/Scrum is meant to adapt to everything, right? Thus, we adapt it to our context.”. Unfortunately, it is not as simple as that!

Agile doesn’t mean adaptation to everything

Let’s first draw the relation between the Agile culture and adaptation. The Agile culture consists in a set of values. Accepting and facilitating change is one of these values. It comes from the observation that unlike other domains early software management took inspiration from, it is difficult to plan software development ahead and very unlikely that requirements, expectation, budget, delays, etc. will not vary a lot as the project goes on.

Among the many things that may change during a project, an agile mindset mainly helps anticipate and adapt to changes of delays, budget and functional scope (along with the underlying code). However, this is no magic and one cannot summon agile “we are agile, why don’t you adapt?!” each time an adaptation would be desirable.

dilbert agile triangle

Take a traditional organization, if it considers that agile must adapt to the existing values of the organization, then that is just putting an “agile” label on them, which is meaningless. If an organization wants to be agile, then it must adopt the agile culture and its values. This change, which is often called Agile transition, adoption or transformation, is difficult and has a significant impact on an organization as a whole.

Scrum to the rescue

One of the main goals of Scrum is helping in this process. This methodology is a framework that brings a common terminology and set of rules that make adoption of agile values easier by naming and legitimating practices that favor them.

Just as any framework, it is recommended that novice teams follow the rules. On the other hand, a mature team can bend them because it knows precisely why it is relevant to do so. Sometimes, that means moving from Scrum to a lighter and smoother workflow inspired by Kanban. However, an Agile team may need months or even years to reach this level of maturity.

Theory versus reality

Our experience told us that on the field it’s a whole different story. Disclaimer: this is not a criticism to any organization, but rather our observation of a phenomenon that has intricate roots and implications.

The majority of teams switching to agile do so in a context that is hostile to Agile values. In such case, practices involving a change of mentality are simply put apart in the name of adaptation in favor of “visible” practices (e.g. daily stand-up meeting, post-its, burndown, user stories instead of requirements…). Adopting these practices is a change, but it mainly impacts developers who then grow an aversion to “Agile” as they pay the price of change without any benefit. In the end, if such projects fails or gets delayed, Agile and Scrum are pointed out as the cause and it is concluded that “it doesn’t work”.

There is hope!

Make no mistake, I am not pessimistic and it is definitely possible to avoid this scheme! The first step consists in acknowledging the risks (that’s why we write this blog post!). Then, we really encourage you to reach out for external help through coaching and training (if your team is located in France, check our training services:, we will be glad to help!). Finally, It is also essential to observe the practices provided by agile methodologies (it doesn’t have to be strictly by the book, but if you have to choose, focus on rules that trigger mentality change rather than the easy ones).


We are often told that iceScrum doesn’t do much to help manage bugs / defects, backed by the evidence that it doesn’t provide a separate bug system with its own workflow and that defects are seldom mentioned in the user interface.

Actually, this doesn’t denote an absence of feature, it is a deliberate feature! Well, software developers have a tendency to dismiss negative user feedback by saying “it’s a feature!” so you may be becoming a bit suspicious here… Don’t worry I understand and I don’t ask you to take my word for that, I will rather try to explain our motivations!

Defects in agile methodologies

First, let’s forget about iceScrum and start with traditional project management because I think that most preconceptions about defect management come from there. Since requirements are intended to be all known in advance, the product specification is written once and for all. Throughout the project, this document is the comprehensive source of truth telling what the product is expected to be. Deviations from these requirements observed in the product clearly don’t belong to the same document, that’s why they are filed into bug trackers.

Fast forward to agile methodologies, where there is no such thing as an exhaustive product specification document. Of course you may have formal specification or documentation (I hope so!), but the vision of what the product should be evolves continuously and, rather than a document, it’s the responsibility of the Product Owner to embody this vision.

The product is what it is and any desired deviation from its current state must be submitted to the backlog where it is discussed, prioritized by the Product Owner and planned accordingly so the team eventually implements it in the product. Whether this deviation is a missing feature, a defect to fix, a useless feature to remove, a performance problem or a software quality issue doesn’t matter, and this fact is a major asset.

If you have separate backlogs, how does the Product Owner materialize their vision, how do developers know what to implement next, and how do users or stakeholder know what to expect in upcoming versions of the product? For the backlog to be effective, it must be unique and ordered.

iceScrum and bug trackers

Now the title of this blog should make sense: we usually don’t recommend using bug trackers as you know them (i.e. separate tools with distinct workflow) to manage defects. However, you may already have a bug tracker you are used to and getting rid of it at once may not be desirable. Back to iceScrum, that’s why our tool provides integrations with bug trackers, making the transition smooth.

The supported bug trackers are Mantis, Bugzilla, Trac, Redmine and Jira. If you too want to sponsor the support of another bug tracker, please contact us.

Bug trackers compatible with iceScrum
Bug trackers compatible with iceScrum

The integration is straightforward: people fill bugs in your bug tracker, when they are ready they are imported automatically in your iceScrum backlog where they continue their lives. Changes in iceScrum are synced back to the bug tracker. This way, people who report issues are not forced to learn and use iceScrum when you team start using it, but of course in the long run learning about what really happen to their issues would be beneficial! Read more in the bug tracker documentation.

Defect management in iceScrum

As I said, we don’t recommend any unnecessary special treatments for defects, but iceScrum provides actually two simple ones that we think add value:

  • “Defect story” type, which makes clear that the story is a defect to be fixed. An exclamation mark icon is displayed on the post-it (the icon will become a “bug” in iceScrum R7).
  • Affected version, where you can point to the product version affected by the bug (a version associated to a sprint beforehand or a new version that iceScrum doesn’t know about yet)

Creating an effective defect story is as simple as filling these fields in combination with regular story fields, e.g. a proper description, attached screenshots to demonstrate the issue and a dependency to the done story that it relates to.

A defect story in iceScrum R7
A defect story in iceScrum R7

In iceScrum R7, you will also be able to define story templates to pre-fill stories when you create them so this will give you the ability to define your own default task list, e.g. “Reproduce the bug”, “Write a unit test”, “Solve the bug”…

Finally, some metrics such as the project Burndown Chart allow to keep track of the evolution of defect rates, which of course you want to keep low. Apart from that, a defect story continues its life in iceScrum just as any user story.

Is there any additional special treatment to manage defects that you think would make sense? Tell us in the comment section!

Si vous êtes un agiliste confirmé vous pouvez sans doute passer votre chemin ou lire l’excellent article (en anglais) de mon collègue Nicolas sur le futur d’iceScrum. En revanche, si vous êtes débutant(e) en agilité comme moi, enfin comme moi avant, alors je souhaite partager avec vous ma vision sur ce domaine que j’ai découvert il y a maintenant 3 ans.

N’étant pas issu du monde informatique, j’ai néanmoins pu observer ce grand mouvement vers les méthodes agiles, à travers internet, les réseaux sociaux et bien sûr mes contacts avec les clients et utilisateurs d’iceScrum. Ce qui était il y a peu encore une niche est désormais au centre de l’attention de tous les acteurs de l’informatique, et pas seulement (certains auront peut-être même vu des publicités à la télévision proclamant une certaine “agilité”, nous ne commenterons pas !).

Que ce soit les startups et PME ou les grands groupes en quête d’innovation, l’agilité est maintenant incontournable dans le paysage des entreprises françaises et internationales et c’est tant mieux ! Elle est d’ailleurs plus que jamais d’actualité à l’ère du management éthique et responsable, des entreprises libérées et du bonheur au travail.

En parallèle, les formations “certifiantes” déferlent sur l’Hexagone, bien que j’aie du mal à comprendre comment on peut devenir un super ScrumMaster en 3 jours ou en remplissant des formulaires sur internet alors que c’est un rôle pour lequel l’expérience personnelle et la dimension humaine ont une importance majeure.


Toujours est-il que la communauté agile grandit elle aussi et de plus en plus de villes ont leurs groupes d’agilistes novices ou confirmés qui se réunissent autour d’un petit déjeuner, d’un verre de vin ou d’une table ronde. Des conférences y sont dédiées, telles que l’Agile Tour. Avec Kagilum, j’ai d’ailleurs participé deux fois à l’édition Toulousaine dont nous avons été partenaire pour apporter notre petite pierre à l’édifice de la communauté Agile française. C’est une expérience de partage, d’apprentissage et d’échanges que je vous recommande !

L’agilité gagne aussi bien sûr les outils de gestion de projet dont on ne compte plus les plugins, les adaptations ou les simples renommages “agiles”. La première valeur du manifeste agile est là pour rappeler que les individus et les interactions doivent primer sur les outils, c’est pourquoi nous avons bâti iceScrum sur les valeurs de l’agilité et non pas seulement sur sa terminologie et ses pratiques. Nous pensons d’ailleurs qu’un bon outil peut rendre des services fondamentaux (je ne les évoquerai pas ici) mais qu’il n’est pas suffisant.

En effet, il est primordial de bénéficier d’un accompagnement humain tout au long de la transition agile pour que ce changement majeur soit un succès. Un bon moyen de mettre le pied à l’étrier est de suivre une formation qui fournit une base solide et les éléments fondamentaux pour aborder sereinement les défis de cette transition. Nous proposons depuis plusieurs années des formations qui remplissent ce rôle en enseignant les racines et les principes de l’agilité ainsi que les pratiques de Scrum en les mettant en application (avec iceScrum ou pas, c’est au choix !).

Depuis maintenant 5 ans nous proposons des formations sur la méthode Scrum. Nos formateurs ont sillonné l’Hexagone et répandu les valeurs agiles sur leur chemin. Notre offre de formation a maintenant une page dédiée sur notre site : suivez le menu “Training” en haut de cette page ou cliquez ici pour en savoir plus, et peut-être à bientôt autour d’un planning poker !

Je terminerai en conseillant évidemment à tout agiliste en herbe de lire des ouvrages sur Scrum dont certains sont très instructifs, j’ai moi-même commencé par là. La lecture est une chose mais suggérer des stories et y ajouter des tests d’acceptation, estimer en points, prioriser puis planifier les stories et savoir analyser les différents indicateurs de projets, tout cela nécessite une expérience “vivante”.

Aussi, si vous avez besoin d’un coup de main pour vous lancer, n’hésitez pas à faire appel à notre équipe de formateurs !

You are currently looking at the future of iceScrum! Well… at least a part of it. Indeed, the visual identity of our website will soon be shared by our tool, and it is just one of the many improvements we are preparing for you…

Former logo      New logo

With years of experience and enlightening feedback from our users and customers, our vision of iceScrum kept evolving until a point where the current version, iceScrum R6, had shown its limits. Indeed, it hindered our ability to offer you the great tool we think you deserve: the best of iceScrum but easier to use, multi-support, more consistent, more customizable and more intelligent.

That’s why, more than two years ago, the seed of a brand new version has been planted under the name “iceScrum R7”.

Our idea consists in two simple parts:

  1. Address today’s needs for the best agile project management tool by improving upon iceScrum R6 in every aspect thanks to the experience and feedback we have gathered.
  2. Give iceScrum the ability to adapt to future feedback and to the continuous improvements made in the field of agile methodologies.

To materialize this idea, we chose to:

  1. On the surface: keep the best of iceScrum and deliver it under a more consistent and enjoyable user experience, in addition to sensible new features.
  2. Under the hood: re-build iceScrum on top of modern and robust technology that will give us a solid foundation to ensure years of maintainability and improvability.

Contextual editing of a story in unified & customizable backlog view
Contextual editing of a story in unified & customizable backlog view

As eager we were to fulfill this promise, we did not let down our faithful users and customers and kept improving iceScrum R6. In parallel, we started iterating on the R7, both on the user interface in collaboration with UI/UX experts and early testers that provided an insightful feedback, and on the technical foundations.

Mobile & Tablet support
Mobile & Tablet support

In a lean startup fashion (if you don’t know lean startup yet, we highly recommend that you have a look at it!), we have pivoted a few times until we found an effective and simple way to provide the rich interactions required by agile project management. Sprint after sprint, we delivered user stories and today we are happy to say that iceScrum R7 is very close to beta!

If you want to be part of early R7 testers or if you just have anything to say about theses news, let us know in a comment!