Loading Profile...
Twitter,
Facebook, or email.
we use scrumworks 4.3 and experience performance issues right after logging in to the web client. It is very slow when it renders the taskboard screen. Sometimes we get a scripting error. It runs on a VM instance of Windows 2003 with 2gbRAM and MySQL. It does not appear to be a server issue. It seems to be all on client side scripting. It uses 60% of the CPU for 25 - 30seconds when Scrumworks is rendering the screen. Sometimes it comes back with a scripting error (could not finish scripting, do you want to continue? yes\no) If you click no, then everything renders properly.
Any ideas? thanks
I’m
frustrated
Performance issue on 4.3 web client rendering taskboard screen
-
Hi wawa,
How many members of the team do you have?
How many Tasks are within the sprint you are loading? -
-
That could do it.
This isn't a new issue in 4.3 (in fact I don't believe the web client changed at all), it has to do more with how the Web Client was originally designed.
What is happening is that the entire sprint has to load before it can be worked with, so all the tasks, team members, etc. Originally being designed for, at most 10 team members (the usual upward limit of a Scrum team), if we start going over that the client can exhibit the behavior you are seeing.
The errors are occurring because the browser believes that it is timing out, even though it is just taking a long time to load. Sometimes just switching the browser you use can fix the issue. Choosing to continue loading should eventually allow the entire sprint to load, even if the error seems to indicate otherwise.
There are some things you can try. Different browsers, and speeding up the client systems will sometimes do the trick. The only sure fix I know of at this time is to build smaller teams. Of course, if the users continue to choose to keep loading it will work, it will just take a lot of time to load when they start it up.-
thanks for the reply.
If we build smaller teams, it looks like you can only assign 1 team to a sprint. is that right? For reporting purposes, they will want to report on all team members for a particular sprint. -
-
-
-
-
Correct, you could only assign 1 team per sprint. Unfortunately the tool was designed specifically to support the Scrum process, so when we start getting outside of that process the tool isn't necessarily going to be suited to everyone's needs.
While ScrumWorks is very flexible, and becomes more and more flexible over time, in this specific case it is not going to do what you need to do very quickly.
You could however be managing these sprints using the Desktop Client, everything you can do with the Web Client can be done in the Desktop Client. If you do decide to go with the Desktop Client you shouldn't have performance issues with over-sized teams.
To get an idea why the tool was originally built this way I might suggest reading Why Are Scrum Teams Supposed to Be Small?, a blog entry by one of our Scrum coaches here at Danube, Jimi Fosdick. There is a lot more to the topic overall, but I think this cuts to the heart of why Scrum teams are small.-
thanks for your help. Our 24 members are actually divided in 4 teams but they just added all members,tasks and backlog items to one sprint in Scrumworks. Sounds like we need to create 4 unique sprints and assign each team to their respective sprint.
-
-
-
-
-
-
-
Would it add extra processing time if we have a series of members on the team that are ... actually not on the team? That is, we have people that have left the company (mostly interns) and they haven't been removed. Would that add extra delay to processing on the web client?
-
EMPLOYEE
we have the following:
24 active team members
224 tasks
24 backlog items
Too much to render? Maybe we need to reconfig?
thanks