[Nicolas Noullet]

Hi!

Here is the roadmap:
1. The R6 version that will bring a few bug fixes and a new way to manage teams.
2. A new website: icescrum.com, that will bring together all the best of the current iceScrum / Kagilum websites and communities.
3. The R7 version with a brand new UI/UX and a lot of new features, while keeping the core of iceScrum.

1. and 2. are nearly there: we expect to release them soon! At the same time, we will put online an alpha R7 version for our users to test it and provide feedback so we make sure that we go in the right direction.

We wanted to take all the time necessary to rethink iceScrum, both on technical and UX points of view, in order to make it ready for the future. That is why we had to step back from the usual release schedule. We are sorry for the long wait but we thing that it will be worth it!

[Nicolas Noullet]

Brian,

Just to be sure, you say that “tasks are Planned” but I was asking about the stories ! Can you confirm that stories are “Planned”?

If so, that is very unusual and that should not happen. If you want to make the other stories be “in progress” then you can browse the release plan, move the stories to the next sprint and then move them back to the “in progress” sprint. Please note that this may unlink some “done” tasks from the moved story so you may need to move them back to the correct row.

[Nicolas Noullet]

I guess that “testing” here would mean unit testing the task, since integration and functional testing would rather become another task in the story.

Scrum does not come with engineering practices but quality cannot be ensured without them. Thus, such practices should not be forgotten in order to ensure the success of agile projects.

One of the most important of those practices is Test Driven Development (TDD), where tests are developed alongside with the code. Then, there is not “testing stage”: tests are integrated into the development process and there is not test team: testing is part of each developer’s responsibility. More generally, intermediate stages should be avoided because they create stock, waiting time, reduce the visibility, increase the feedback loop, split the responsibility between different team members or even different teams, etc.

Of course it may seem that I am talking about the ideal of agile projects, and reality is often different. But unlike other tools that just integrate agile terminology into regular project management features, we try to make iceScrum facilitate and encourage good agile practices and we don’t implement features that encourage bad practices while not providing significant value.

[Nicolas Noullet]

Brian,

All the stories of an “in progress” sprint should be at least “In progress”, or done. Can you confirm that the sprint is in progress and you have both “In progress” and “Planned” stories in it?

[Nicolas Noullet]

Hello Brian,

Here are the two requirements to make the “Declare a as done” menu appear:
– The story must be in progress
– The user must be Product Owner

Are you sure that these requirements are met? If so, the menu should be displayed. If it is, does it work?

[Nicolas Noullet]

Bonjour,

Avez-vous comme dans l’autre post des logs mentionnant le connecteur APR?

août 21, 2014 1:39:50 PM org.apache.coyote.AbstractProtocol init
INFOS: Initializing ProtocolHandler [“http-apr-8181”]
août 21, 2014 1:39:50 PM org.apache.coyote.AbstractProtocol init
INFOS: Initializing ProtocolHandler [“ajp-apr-8009”]

Afin d’y voir plus clair, pourriez-vous fournir plus de logs, le fichier de config Tomcat server.xml, version de Java, tout élément supplémentaire qui vous viendrait à l’esprit…

[Nicolas Noullet]

Hello,

I suspect that something is wrong with the underlying data. Such an inconsistency could mislead the operation that retrieves the current sprint and makes it return nothing, despite the sprint being accessible through other means (e.g. direct access by its ID).

I suspect a problem with the orderNumber field or maybe a “shadow sprint” that has is not visible in the user interface.

What DBMS do you use? Could you send me an SQL export of your DB (nnoullet_at_kagilum_dot_com).

[Nicolas Noullet]

Bonjour,

Ce n’est pas possible : les projets iceScrum ont vocations de rester suffisamment petit pour permettre une réelle agilité. L’approche que nous conseillons consisterait donc à découper le gros projet en plusieurs petits projets.

iceScrum Pro propose des fonctionnalités inter-projet : copie de stories entre projets (par ex. pour avoir un projet de base et dispatcher les stories dans des sous projets) et un regroupement de projets sous forme de “bundle”: https://www.icescrum.com/fr/documentation/icescrum-pro/project-bundle/

[Nicolas Noullet]

Hi,

There is no way to do that. Actually we thought a lot about this feature and we concluded that the cons outweigh the pros.

What columns would you want to add?

In many cases, we noticed that this feature is requested in order to create a “REVIEW” column but this column would have very little use: automated tests are expected to be developed at the same time as the code so the tasks are reviewed continuously from their beginning to their end.

[Nicolas Noullet]

Hello Leo,

Yes there is a way. After having enabled Web Services on your project, use one of these requests:

XML output:

curl --header "Content-Type:text/xml" --user login:pass http://[server]/ws/p/[pkey]/project/0/export > export.xml

ZIP output (XML + attachments):

curl --header "Content-Type:text/xml" --user login:pass http://[server]/ws/p/[pkey]/project/0/export?zip=true > export.zip

Nicolas

[Nicolas Noullet]

Concernant le premier point, le burndown sert à montrer le travail restant et c’est particulièrement intéressant quand on commence à travailler (burndown de projet avec une capture en début de sprint) et pour suivre l’avancée du travail (burndown de sprints avec une capture par jour) plutôt qu’en fin de cycle (à la fin du Sprint par ex. où on se concentre effectivement sur le Done, qui est l’objet d’autres indicateurs). Si il s’agit de la fin du dernier sprint du projet alors il n’y a à priori pas d’objet à se concentrer sur le travail restant, ce qui compte c’est ce que contient le produit réalisé. Je pense que c’est cela qui a guidé le choix d’implémentation dans iceScrum (je ne travaillais pas encore sur iceScrum à ce moment là et je suppose, sans garantie, que c’est le Product Owner d’alors, Claude Aubry, qui a suggéré ce comportement).

Concernant le deuxième point, c’est une bonne pratique d’anticiper l’estimation des stories (point trop n’en faut bien sûr), et dans le cas de releases qui se suivent sans pause c’est effectivement un problème, l’outil ne devrait obliger à “s’interdire” d’estimer des stories.

[Nicolas Noullet]

Hi Kamlesh,

The story can’t go back to the sandbox nor the icebox :
– The sandbox is the place where ideas are suggested, waiting to be discussed and moved to a relevant “box” (backlog, features, icebox) or deleted. Here the story has gone far from that initial state.
– The icebox is where you store items that provide value so they should not be deleted but they don’t belong to the backlog because they don’t follow the current vision (out of scope but interesting items). Again the story has gone far from that initial state.

Now, only the next sprint and the backlog remain:
– backlog: It should have a top priority and a low estimate that corresponds to the remaining effort (the deployment). There is a practical problem in moving it back to the backlog in iceScrum: you will lose the tasks because tasks can only be associated to a sprint (this limitation will be removed in the next iceScrum release).
– next sprint: this is the preferred solution because it is the standard way to manage a story that has been worked on but that is not done. I consider that business approval is part of the work that makes a story complete, just as technical tasks. If a technical task is not done when closing the sprint then the story is shifted to the next sprint, I don’t see how this cannot apply for a missing business task. In this case the story will “pollute” the next sprints and that I think that this is a good thing because it should be made visible as an anomaly rather than hidden under the carpet.

In both cases this should remain an exception or it will soon become unmanageable and remove all the benefits brought by Scrum and its workflow.

The Product Owner’s role has been created to prevent such situations: she is available for the team (at least for planning sessions, questions and the sprint reviews) and she must be able to make business decisions such as approving a story in the name of business people, stakeholders, users etc.. Business approval is intended to be completed in the same sprint as the technical tasks, at any time during the sprint as soon as all its technical tasks are done or during the sprint review otherwise.

[Nicolas Noullet]

Comme je l’ai indiqué précédemment, il s’agit des valeurs en début de sprint et non fin de sprint.

C’est le total des estimations des stories non finies (backlog + plan de release) qui est utilisé que ce soit dans le burndown de release ou celui de produit. Celui de release apporte peu de valeur si ce n’est un “focus” sur les sprints de la release en cours.

Je ne suis pas à l’origine de cette décision mais j’imagine que le postulat était que toutes les stories estimées ont vocation d’être planifiées dans la release courante (sauf peut être au dernier sprint de la release en cas de continuité immédiate entre les deux releases ?).

Merci pour vos retours en tous cas, ils démontrent que ceci mériterait d’être clarifié dans l’outil. Ceci renforce notre volonté d’améliorer les indicateurs en leur adjoignant des indications sur la manière dont ils sont générés et comment les interpréter.

[Nicolas Noullet]

Bonjour,

Vos observations sont correctes : chaque barre du burndown représente le nombre total des points des stories non finies, c’est à dire l’effort qu’il reste à fournir pour terminer le projet.

Il y a une barre par sprint, l’indicateur représente donc l’évolution du reste à faire global du projet sprint après sprint. C’est donc bien une manière de mesurer l’avancement du projet ! On mesure simplement cet avancement par ce qu’il reste à faire (c’est l’objet du burndown), l’autre moyen étant de mesurer l’avancement par ce qui est fait (c’est l’objet du burnup).

Afin d’obtenir un point dans le graphique dès le début du projet (au début du premier sprint), la valeur est capturée à l’activation des sprints.

C’est au même moment qu’est capturé la capacité du sprint. L’équipe espère alors faire diminuer le nombre de points à faire total du projet à hauteur de la capacité du sprint et faire descendre le burndown. Cependant, ceci ne sera pas forcément le cas pour deux raisons :
– Certaines stories ne seront pas finies : seule la vélocité, c’est à dire les points des stories finies, viendra réellement diminuer le total du reste à faire du projet.
– De nouvelles stories pourront être estimées, ajoutant leurs points au total qui sera capturé à la prochaine barre du burdown. Si on veut s’abstraire de cela pour se focaliser sur le travail de l’équipe, on préférera donc l’indicateur capacité vs. vélocité.

Les indicateurs ont vocation de rendre visible les éléments clé du projet. Cette visibilité doit alors être exploitée par le Scrum Master, les parties prenantes et l’équipe. L’interprétation des indicateurs doit prendre en compte le contexte du projet pour être pertinente.

Par exemple, l’équipe est face à un burndown relativement constant au fil des sprints :
– Si les stories sont relativement bien connues et estimées en début de projet / release, alors le burndown constant indique que l’équipe n’avance pas suffisamment et que le projet risque d’échouer. Des actions doivent donc être décidées pour prévenir ce risque.
– Si le backlog est très vivant et de nouvelles stories sont estimées régulièrement alors le burndown constant indique que l’équipe fait bien avancer le projet : autant de points sont produits que de points sont rajoutés au backlog, équilibrant le total des points à produire.

[Nicolas Noullet]

Hi Leo,

Only Product Owners can update stories they did not create, see https://www.icescrum.com/blog/the-stories-according-to-role-icescrum/.

[Author]

Posts