Virtual Sprint Task Board Using a Wii Remote

While I love implementing Scrum in Team System, nothing can quite compare to a physical story wall of sprint task board. The intimacy and tactile nature of moving cards around on the board cannot be replaced. However, a good many of my clients who are implementing Scrum shy away from using note cards and sticky notes. Conchango provides a very cool WPF app that simulates a sprint task board, but even when you have it projected on a large screen, someone still has to sit at the computer to move items around and it is either a logistical nightmare having each person sit down to do this or one person does it while everyone tells them what they did and you start to loose the attributes that make the task board such a great tool.

You could go out and buy a large touch screen monitor and mount it in the Daily Scrum room if you have $3000 to $5000 just lying around. Or you could buy an interactive "smart" white board for about the same cost. If your company is that much invested in Scrum that they will approve such an expense, please let me send you my resume! The rest of us do not have that kind of money to spend and I was very intrigued when someone sent me this link to a YouTube video featuring an interactive story wall using Mingle. Upon further investigation this setup can be easily achieved with less that $100.

Johnny Chung Lee from Carnegie Mellon University came up with an ingenious way to use a Nintendo Wii Remote to create an interactive whiteboard. Here is what you need:

• Bluetooth receiver (~$20 or free if already on your computer)
  
• Nintendo Wii Remote ($35 at Wal-Mart)
  
• Infrared Pen ($18 at Wiiteachers.com)
  
• Johnny's Wiimote Whiteboard Software (free)
  

Getting Connected with Bluetooth

The first laptop I tried this on was a Sony Viao and it came with the standard Windows XP Bluetooth stack which while it will see the Wii Remote it does not really know what to do with it even once it have been connected. I had to download the stack from Bluesoleil to get it the connect and be recognized by the Wiimote Whiteboard Software. The download is only a trial and the purchase the product it was $30 USD. My work laptop did not have Bluetooth so I just decided to buy a Bluetooth receiver so I could then setup everything up on any computer with a USB port. The website WiiBrew has a list of Bluetooth drivers and receivers that are known to work with the Wiimote. I bought the Cirago BTA-3210 USB 2.0 Micro V2.0+EDR Bluetooth Dongle on TigerDirect for around $20 and it comes with the Toshiba Bluetooth drivers.

I inserted the Cirago receiver into my USB port and installed the drivers from the included CD. After a reboot I opened the Bluetooth Settings windows and clicked new connection, I pressed the 1 and 2 buttons on the Wii remote to put it is discovery mode and it was recognized without a hitch.

The IR Pen

I mentioned this project to my wife early on and she ordered me several LED pens from Amazon which was very sweet of her but none of them worked. You need an IR pen with certain specifications. There are many sites with the specs on how to build one, but I just purchased one from Wiiteachers.com for around $18. It is a standard Expo dry erase marker that they gutted and then fitted with the IR light, a switch, and place to put a single AAA battery. There are a few fancier pens out there, but this one was cheap and worked well.

Setting it all Up

Once I had everything (I already had a few Wii remotes at home although the kids did complain when I took one away for work), I setup a projector connected to my laptop, connected the Wii remote via my Bluetooth receiver, ran the Wiimote Whiteboard application, calibrated the IR pen, and was using the pen as a mouse.

A few notes on the setup:

Set the Wii Remote to the side with a clear view of the entire projected screen. The IR sensor has about a 45 degree angle and several times the calibration worked fine but it could not see the outer edges of my screen. I finally mounted (with a rubber band) the Wii remote to my camera tripod and set it over to the side of the wall I was projected on.

When you use the pen you have to make sure you body is not blocking it from the IR sensor on the Wii remote. This was not too much of an issue because I had to be to the side of where I was using the pen anyway as to not cast a shadow over the projected area.

If you bump the Wii remote, the projector, or resize your desktop you will need to recalibrate the pen. This is very easy to do with the Wiimote Whiteboard application. Also if you use it with a Virtual PC image, the desktop resolution on the Virtual PC needs to be the same as the host desktop or the pointer and the pen are off a bit.

The Virtual Sprint Task Board

Once everything was working I opened up my Virtual PC with Team System 2008 and the Conchango Sprint Task Board application. The setup works great and I can easily move tasks from one state to another as well as tap on an item to get the detail pop up window. The scale slider at the top of the board allows you to zoom in and out so you can see the entire board or zoom into a specific set of User Stories.

Windows comes with a virtual keyboard that you can use to type using the IR pen. This is not super optimal, but it works for small things like updating a tasks remaining hours. The Windows version is fairly rudimentary so I downloaded the freeware version of Touch-It's virtual keyboard which had some added features like docking, customizable keyboard layouts, etc.

While it is still not the same as an actual physical board with note cards, for those using an Agile management tool already this is a cheap way to get close to it. Here is a short video of me setting this up and using the task board.

TFS API: Work ItemHistory

One of the tasks I had while developing my own version of a Sprint Task Board was to note each work item’s “staleness”. This meant that for any Sprint Backlog task that was in a state of “In Progress” or “Ready for Test” I needed to know the last time its Work Remaining field had been updated.

The Team Foundation Server API provides an easy object model for iterating through a work item’s history. Each WorkItem has a Revisions collection that holds individual snap shots of the work item each time it was updated. The Revisions in the collection are in order or earliest to latest, but there is also a Rev property for each one that is the sequential order. Each Revision has a collection of Fields for each field, both the common system fields and any fields added from a custom process template. When you access an individual Field in the Revision you can see what the original value was (OriginalValue) versus what the value was changed to in the revision (Value). If the field was not changed the values are the same.

Since this is the very first time the work item was saved the OriginalValue property on all fields is null. The ChangedDate is the date we saved this particular revision and the RevisedDate is displayed as the maximum value of the DateTime type since this particular revision has not been revised yet. If we edit the work item on June 3rd the Revisions would look like this:

The RevisedDate for Revision 1 is set to the ChangedDate for Revision 2. The fields for Revision 2 now have their OriginalValues populated with the appropriate values from Revision 1.

So based on the examples above, if we want to know the last time a specific field was updated you would look for the “System.ChangedDate” field’s Value for the latest Revision where that field’s OriginalValue and Value properties are not equal. Here is a LINQ query that would accomplish this for the “Work Remaining” field (this field is an extended field that comes with the Conchango Agile Process Template).

One thing to remember when using the Work Item object model is its effect on performance. Not all fields are loaded initially so depending on how you access the WorkItemStore you may incur additional round trips to the server. This MSDN article does a good job of explaining how this works and what your options are to increase performance.

Conchango's Sprint Task Board

I wanted to thank Crispin for giving me the heads up that Conchango has posted two video demos of their upcoming Sprint Task Board application. As I stated in my last few blog posts, I had been working on something similar but where Conchango has dedicated development resources, I had only a few spare hours here and there between work and handling the new baby. I look forward to the release of this application and will post a review as soon as it is out. I did learn a good deal more about the TFS API while working on my own pet project and I am working on some more in-depth technical posts in the next week or so.

Sprint Task Board Update

I wanted to clarify that the Sprint Task Board project I mentioned last post is by far not an original idea. It is simply a side project for me to create a version that does exactly what I want it to do. There are various other versions of this in Scrum management products like Mingle and ScrumWorks. Conchango has even hinted at one for Team Foundation Server in a reply to one of my forum posts.

Working on this has helped me get deeper into the Team Foundation Server API and I will post soon about some interesting discoveries in the work item history objects.

Sprint Task Board

With the arrival of our new baby I took a few weeks off. During the late nights I started fiddling around with creating my own virtual Sprint Task Board to emulate the physical sticky note boards most scrum (and other agile) teams use. I have always like the immediacy of the task board, but never could relinquish having the data digitally rather than physically. I am not an agile purist plus my current team has some remote members and a physical board would not work for us. I have created the initial draft as an ASP.NET web page which I plan to port to a WPF extension inside of Visual Studio 2008. This rough version allows you to view the current sprint tasks grouped by either the Product Backlog Item it is associated with or the Assigned User. The IDs of the work items link directly to Team System Web Access so that you can view the details. I plan to start refactoring this into an actual application soon and possibly submit it to CodePlex.

The color coding is based on when an "In Progress" or "Ready for Test" task's Work Remaining field was last updated. The scale goes from green to red according to how "stale" the work item is. Work Items with an open Impediment are clearly noted. This should provide a good overview of the sprint's health at a glance.