Evaluation of IceScrum

[ThomasLehmann]

Hi IceScrum Team!

Our team is now evaluating icesrcrum to see.
All issues I will bring up are basing on scrum trainers and scrum coachs
leading us since january through the whole process (Boris Gloger).

There's no specific order.

• The taskboard is the tool of the TEAM (role). So no other role should be allowed
  to do manipulations on that board. The opposite is the fact.
• No icescrum user should be able to switch the role! Adjusting can be done by the admin.
• The columns "waiting" and "locked" are commonly known as "todo" and "work in progress".
• There are no dots on the tasks. If one task can not be finished the day it get a dot
  next morning (daily scrum). Those dots are indicator for the scrum master to ask the
  TEAM whether it does make sense to split the task: one task for things that has been done yet
  and one task for things still todo. So you can move one task to done and the remaining does
  not have dots anymore.
• Bugs are tasks - not a kind of story! Stories are having business value, bugs not - you do not get money for this!
  Bugs simply need to be done in the context of current story. We use yellow tasks for story tasks
  and red tasks for bugs. A story is not done when all assigned tasks (also bug tasks) are not done.
• There's no readonly mode so anybody is interested in the progress of the team can have a look
  at the taskboard. Maybe without doing a login?
• The task is for one person only. A learning session can be attended by more persons so the TEAM
  is forced to place additional tasks.
• The bord does not display TEAM impediments and dependencies. Note: I'm not talking about those
  impediments which have to be taken by the scrum master. A TEAM impediment is something where
  a TEAM member might block the TEAM because he/she is needed by another TEAM. A dependency is
  when a TEAM member can not do a task because of something required from another TEAM. We are
  using green for those dependencies and magenta for those impediments.
• When the sprint is over, can I move the remaining tasks (stories) to next sprint?
• Icescrum does not work correctly with the Internet Exporer.
• A linux colleague tells me that Icescrum crashes sometimes on his Firefox.

best regards
Thomas

[Stéphane Maldini]

Hi Thomas,

Thanks for this very constructive feedback, I payed attention to it and this is a pleasure to read this kind of issues

I will try to answer to some of the troubles raised :

The taskboard is the tool of the TEAM (role). So no other role should be allowed
to do manipulations on that board. The opposite is the fact.

This is a permissive policy to allow Product Owner, Scrum Master and Team Member to get involved in the product iteration. In small teams for instance like ours, we don't have a room for exclusive role working. In fact, I don't advise this kind of splitting, as everybody is required to make a successfull product.
The only role who have no powers at all is the Stakeholder.

No icescrum user should be able to switch the role! Adjusting can be done by the admin.

I think you do have this feature, log yourself as a Scrum Master, enter in your project then click on the project title link in the top menu (blue bar). You will find this http://www.icescrum.org/wp-content/uploads/2010/02/is2_scrumaster_actions.jpg

The columns "waiting" and "locked" are commonly known as "todo" and "work in progress".

You get a point !

There are no dots on the tasks. If one task can not be finished the day it get a dot
next morning (daily scrum). Those dots are indicator for the scrum master to ask the
TEAM whether it does make sense to split the task: one task for things that has been done yet
and one task for things still todo. So you can move one task to done and the remaining does
not have dots anymore.

Another point, a nice feature would be to split tasks over having dots, even making a split proposal automatically to scrum master (he could see blocking tasks immediately).

Bugs are tasks - not a kind of story! Stories are having business value, bugs not - you do not get money for this!
Bugs simply need to be done in the context of current story. We use yellow tasks for story tasks
and red tasks for bugs. A story is not done when all assigned tasks (also bug tasks) are not done.

I think this is arguable. We calculate technical due with this no money kind of stories. In fact we have decided there are 2 kinds of bugs :
- little fix which is embeddable in sprint with a task
- major or complexe bug which needs planning and do no provide real points (value) but block major use of the product, you can see them on burdown chart (red color) and analyse technical debt

I will continue the thread very soon, have to move atm.
But again thanks for your feedback

[Stéphane Maldini]

# There's no readonly mode so anybody is interested in the progress of the team can have a look
at the taskboard. Maybe without doing a login?

Some work will improve this issue certainly. Actually you can close project with scrum master, only Stakeholder will be able to join and see the project in Read only fashion. If you don't want Stakeholder, you can also hide the project from joining. (R15 stuff, see release notes)

# The task is for one person only. A learning session can be attended by more persons so the TEAM
is forced to place additional tasks.

You can see it as as task responsability, but we have a user story in this way.

# The bord does not display TEAM impediments and dependencies. Note: I'm not talking about those
impediments which have to be taken by the scrum master. A TEAM impediment is something where
a TEAM member might block the TEAM because he/she is needed by another TEAM. A dependency is
when a TEAM member can not do a task because of something required from another TEAM. We are
using green for those dependencies and magenta for those impediments.

Dependency is thing we are planning to add, even if this use is not recommended. It can be a very frequent real use case in fact. We didn't have priorized this issue because we don't want team spending 2hours to plan everything in our tool, we want to be fluent and transparent for long term use.

# When the sprint is over, can I move the remaining tasks (stories) to next sprint?

When story is not closed, R15 will prompt you to move unfinished stories in prdocut backlog, then you can re associate them.We planned for R15#1 (in 2 weeks) something else : sprint specific tasks unfinished auto move to next sprint.

# Icescrum does not work correctly with the Internet Exporer.

Work in progress.

# A linux colleague tells me that Icescrum crashes sometimes on his Firefox.

Mmmh, exploration needed.

And voila
Hope to see you soon,

Best regards

[ThomasLehmann]

Hi Stéphane,

The taskboard is the tool of the TEAM (role). So no other role should be allowed
to do manipulations on that board. The opposite is the fact.

This is a permissive policy to allow Product Owner, Scrum Master and Team Member to get involved in the product iteration. In small teams for instance like ours, we don't have a room for exclusive role working. In fact, I don't advise this kind of splitting, as everybody is required to make a successfull product.
The only role who have no powers at all is the Stakeholder.

The idea is this: the TEAM should be self organized. There's nobody telling the TEAM what to do. Of course the TEAM can also not decide what to do but it can decide how much it can do (selected backlog items). The worst case: no story because of very many bugs!

It is not acceptable if a SM or a PO is starting to place tasks because this is the old style managment where a project leader is telling the TEAM what to do. This is not scrum (for sure). The SM and the PO will not have time in participating by programming and testing and they also should not; because of meetings they are - often - not available and this might block the TEAM.

No icescrum user should be able to switch the role! Adjusting can be done by the admin.

I think you do have this feature, log yourself as a Scrum Master, enter in your project then click on the project title link in the top menu (blue bar). You will find this http://www.icescrum.org/wp-content/uploads/2010/02/is2_scrumaster_actions.jpg

The columns "waiting" and "locked" are commonly known as "todo" and "work in progress".

You get a point !

There are no dots on the tasks. If one task can not be finished the day it get a dot
next morning (daily scrum). Those dots are indicator for the scrum master to ask the
TEAM whether it does make sense to split the task: one task for things that has been done yet
and one task for things still todo. So you can move one task to done and the remaining does
not have dots anymore.

Another point, a nice feature would be to split tasks over having dots, even making a split proposal automatically to scrum master (he could see blocking tasks immediately).

Perfect!

Bugs are tasks - not a kind of story! Stories are having business value, bugs not - you do not get money for this!
Bugs simply need to be done in the context of current story. We use yellow tasks for story tasks
and red tasks for bugs. A story is not done when all assigned tasks (also bug tasks) are not done.

I think this is arguable. We calculate technical due with this no money kind of stories. In fact we have decided there are 2 kinds of bugs :
- little fix which is embeddable in sprint with a task
- major or complexe bug which needs planning and do no provide real points (value) but block major use of the product, you can see them on burdown chart (red color) and analyse technical debt

Well, I did just tell what the scrum trainer and scrum coaches have been telling us. Bugs are not stories.

Ok. Thank you for your answers. I will continue on your second response (soon).

[ThomasLehmann]

# There's no readonly mode so anybody is interested in the progress of the team can have a look
at the taskboard. Maybe without doing a login?

Some work will improve this issue certainly. Actually you can close project with scrum master, only Stakeholder will be able to join and see the project in Read only fashion. If you don't want Stakeholder, you can also hide the project from joining. (R15 stuff, see release notes)

Maybe I'm wrong but can't you visit this forum without being registered? So can't you manage to display the taskboard for the outside world so everybody can see the status of the TEAM, the stories and the bugs. Maybe it's a policy which you have to set to allow this.

# The task is for one person only. A learning session can be attended by more persons so the TEAM
is forced to place additional tasks.

You can see it as as task responsability, but we have a user story in this way.

It's again the same issue as with bugs. A learning session is nothing with a business value. The TEAM has to be aware of such things - to commit to less stories - to be able to do learning sessions, refactoring tasks and stuff like this and of course to fix bugs.

# The bord does not display TEAM impediments and dependencies. Note: I'm not talking about those
impediments which have to be taken by the scrum master. A TEAM impediment is something where
a TEAM member might block the TEAM because he/she is needed by another TEAM. A dependency is
when a TEAM member can not do a task because of something required from another TEAM. We are
using green for those dependencies and magenta for those impediments.

Dependency is thing we are planning to add, even if this use is not recommended. It can be a very frequent real use case in fact. We didn't have priorized this issue because we don't want team spending 2hours to plan everything in our tool, we want to be fluent and transparent for long term use.

I see the point (time). However, we currently have to place a dependency on our board. We have to give a task to that TEAM the depedency is refering to
and we have to place the dependeny on the overall teams board. By the way: this is an important issue I'm missing by that tool. But things can not be done in short and other things - the basic usage - have to be improved first...

# When the sprint is over, can I move the remaining tasks (stories) to next sprint?

When story is not closed, R15 will prompt you to move unfinished stories in prdocut backlog, then you can re associate them.We planned for R15#1 (in 2 weeks) something else : sprint specific tasks unfinished auto move to next sprint.

# Icescrum does not work correctly with the Internet Exporer.

Work in progress.

Fine.

# A linux colleague tells me that Icescrum crashes sometimes on his Firefox.

Mmmh, exploration needed.

Is there something we can give you to see the problem (logfiles etc.)?