In an earlier post I mentioned how I currently work using a Scrum-like process. So, I thought I'd share the tools I use and show how powerful this environment is!
But first, a sneak peek on the result. This is the normal dashboard view where the developer interact with the Scrum-process:
This view allows for drag n'drop of sprint activities from "Not Done" to "In Progress" and so forth. It is an easy, quick and rewarding system. There's nothing like making a sprint task green! :-)
So, how is this environment created?
This is the products we've used:
- Visual Studio Team Suite 2008
- SQL Server 2005
- MOSS 2007
- Team Foundation Server 2008
- Scrum for Team System
- Visual Studio Team System 2008 Web Access
- Scrum Dashboard
The Scrum Dashboard (created by the EPiServer team, thanks guys!) makes the whole process visible and fun, which is very important. We have a distributed team so a physical Scrum board is not an option. Also, I strongly believe in giving feedback, and the dashboard gives a nice, green feedback each time a developer finishes a task. :-)
All in all, this environment works like a charm and I'm very pleased.
Drawbacks
The TFS environment is built upon a flat layer of "tasks". It is possible to configure any number of different types of tasks of course, but it is not designed for the dual layer that the Scrum template uses where Sprint Backlog Items are part of Product Backlog Items.
To represent this task structure the Scrum template uses the "Link" functionality available for tasks. Basically, spring backlog items are linked to from the product backlog item and the Scrum template contains an event manager that listens to changes and updates linked items accordingly. For example, when estimated times are changed in a sprint backlog item the product backlog item is updated automatically.
This works fairly well but when you update tasks from TFS you need to truly understand this logic since it is easy to break it. For example when moving a sprint backlog item from one product backlog item to another it is important to work from the sprint backlog item view and not the product backlog item view for some reason. In the first case the event triggers, in the latter the event does not trigger, leaving product backlog items with incorrect values.
Screens
The burn-down chart, from Reporting Services. It shows the actual time, the trend, and the capactity trend. (And yea, got hit with a lot of sickness this sprint...)
The sprint backlog item web editor that opens if you click on an item. Hosted by the "web access" layer and based on the Scrum template. Only one field has been added by me - the "Work Performed" text box. Product backlog items may be edited as well and look similar.Summary
Besides from the somewhat cumbersome TFS management, I have nothing bad to say about this system. On the contrary, I am very pleased by what these open source products have to offer!
2 comments:
Interesting read! Please post more screenshots and tell what you have customized yourself.
Actually, Mads and I are working on a similar, more generic scrum board app. The big difference is perhaps that ours require no expensive M$ licenses to get it working :)
See a tiny screenshot of it here: Where to find a giant, affordable touch screen? (justaddwater.dk, march 2008)
Thanks for your comment Jesper! I added a "screens" section to show off some additional features of the set-up. :-)
And yea, TFS isn't free. I am a BIG fan of Subversion, CruiseControl.Net, NAnt, NUnit, Trac, and so on. That is a good environment as well.
But - TFS is simply a better solution. At least for my project. And, for a multi-project hosted environment, TFS will simply kill the above combination.
Post a Comment