Online Scrum Tool Features You Need

• Non-existence - You've already failed if you're using an online tool. Agile practices are all about face-to-face conversations and work. Emails and IMs are not going to take the place of body language and co-located camaraderie. But assuming that this is not an option, let's move on.
• Flexibility in Tasking - Some teams buy stories and deliver them without using tasks at all. Some teams use tasks as almost a replacement WBS. I'm not going to get into what's right, but suffice it to say that different teams use tasks different ways. Your tool should be able to be real-time updatable of tasks for a story. Developers should be able to add, subtract, and update tasks as needed during the sprint. Or not -- some teams don't want developers tasking. In which case you need to be able to lock them out.
• Seamless Operation With Real Artifacts - A good online scrum tool will be able to seamlessly operate across the computer boundary. Going to the stand-up this morning? You should be able to quickly print and post all of the latest team radiators. The physical stuff should match the online stuff, and updates should take place first on the physical stuff, not in the online world (if possible) There's still that tactile feel of moving a story card that you just don't get with typing in numbers on a web page. The tools should support reality first, virtual reality second.
• Refusal to Generate Stupid Reports - Programmers are good to taking data and generating reams of paperwork. Many times teams are good at producing reams of paperwork. Let's not hook these two groups up! An online scrum tool should only print the absolute minimal number of reports -- basically the things you'd see on the wall if you could visit.
• Refusal to Create Stupid Metrics Around Story Points - If your tool is generating points-per-hour, or defects-per-point, or joining points across teams or any other of that nonsense, trash it. Story points are unit-less. The entire "point" of story points is that you can't combine and slice and dice them. Once you go down this path, you might as well go back to more traditional tools. You've defeated the purpose of unit-less sizing
• Non-Integration With Larger Suites - Would it be cool to know that this use-case corresponded to these stories which resulted in these checkouts which created these bugs? Yes. It would be cool. It's also a pipe-dream and a nightmare to actually get working. Integration is a fool's game. Many billions have been spent by companies chasing this dream. Buy something that does one thing and does it well. Having 4 or 5 tools from different vendors is not the end of civilization as we know it. If you have a large org and want to integrate data, once you get everything working allocate some programming time to only creating the integration points you really need. That way you're forcing yourself to think clearly about priorities, instead of buying everything on the cereal box.
• Use of One U.I. Idiom to do Multiple Things - So let's say you have a free-flowing taskpad, like 37Signals does with BaseCamp. Why not use that for user feedback? Bugs? Issues? Instead of different screens for everything, maybe it's better to use one screen for multiple purposes -- with the appropriate tags, of course.
• Ditch the Bells And Whistles - If you're seeing a theme here, you're right. You don't need instant messaging, tweeting, real-time motion capture, video-conferencing, or karaoke (just kidding!) with your online scrum tool. Just KISS - Keep it Simple Stupid. These tools do not take the place of face to face interaction, and even if they did, you're better off with the teams working out what works best for their unique circumstances than trying to operate something that looks like the cockpit of a 747
• Speed and Adaptability Rule - I, as a complete novice, should be able to set up a team's system inside of 10 minutes, preferably with guided video help. Later on, there should be options for advanced setup, as the team discovers their need for more assistance, not before.
• The Tool Should Provide Lots of Online Advice - If you're sizing stories, there should be some teaching information, preferably in the form of videos, to help you out. If you're determined to pay for some extras, pay for the maximum amount of practical assistance you can give to folks while they're working.
• There should be a free and open community - Don't buy a tool without it having an online community where you can go and complain, get advice, ask for new features, or learn best-practices.

This is just my wish list from my experience. As you can see, many of these are negative features. Beware of purchasing things you do not need! Especially in agile/scrum, people will take features as a checklist for what has to be done. If you put a field on a screen, somebody will think that field has to be filled out each time for a "perfect" project.

If you know of a cool tool drop me a line -- I'll be glad to list it. In a future blog we can do a review of what's available and how they match up. There are some neat ideas out there. I even have a team that's even using Second Life as a collaborative environment.

I'm out of the online scrum tool business for now, but it was an interesting experience. Many times the things I thought the users wanted wasn't that valuable to them. Over and over again I found my ability to make things "cool" was in direct contradiction to users, who only wanted something as simple and easy as possible.

If it just wasn't for those dang users, this programming stuff would be a lot easier.