Scrum Eventing Service woes

In some previous posts, e.g. this one, I talked about performance problems we were having with our TFS server. After upgrading the server everything seemed to be a lot better but because we experienced two more hiccups we decided to move the Scrum Eventing Service (part of Scrum for Team System by Conchango) out of the TFS application pool. The primary reason we did this was to make sure that if we had to send dumps of the TFS process to Microsoft it would not be cluttered by stuff that didn’t belong to Microsoft in the first place.

Maybe it’s a coincidence but since we moved the Eventing Service into a dedicated application pool TFS is behaving just fine. The Eventing Service on the other hand is timing out a lot and fails to update the remaining workload most of the time. Sometimes the Eventing Service takes up to 50% of CPU while, on first sight, it has almost nothing to do. Since we have no idea what is going (wr)on(g) we might decide to either update remaining workload at pre-defined intervals or (worst case scenario) move away from Scrum for Team System. A cry for help on the forum has returned nothing else but radio silence.

Since we want to stay with Scrum as such, this means we will have to evaluate other offerings like this, or this, or build a Process Template from scratch ourselves. I had a quick look at eScrum from Microsoft itself and I must say I was impressed about what they have to offer. They included a lot of stuff which would be deemed overhead and !Scrum by Scrum purists but really is a must when practicing Scrum in an enterprise context.

No comments yet

Leave a comment