My first impression is that these are two applications that have come from very different backgrounds. ScrumWorks started off as a java based desktop application. Rally is based on an ASP model where the application and data are all hosted at a remote site. Both applications have grown their feature sets over the last two years with what appears to be 2 different objectives in mind. Rally has taken the approach of adapting to a wide range of customer needs, both Agile and traditional. Their goal seems to be to reach the high end customer and integrate with existing high end systems on the market. Their feature set is very broad and has been adapted to fit in a variety of different scenarios. In addition, Rally has also significantly beefed up their integration support in the last two years. There is no doubt in my mind that when it comes to integration and customization, Rally is the clear winner.
ScrumWorks, on the other hand, has kept focused on a goal of serving just the Scrum and XP community. As a result, they have a much narrower feature set that is easier for the typical Agile team to understand. This is just speculation on my part, but I think it doesn’t require as much training to use ScrumWorks. I would describe the ScrumWorks product as more fit for a specific use – in this case for Scrum and XP projects.
In general, when it comes to ease of use, ScrumWorks benefits from the fact that it has a thick client that can take advantage of OS features that web based applications can’t do quite as easily (Drag and Drop, etc.). So in terms of usability, ScrumWorks is currently the clear winner. However, Rally is not resting on their laurels, and they are implementing new usability enhancements that will quickly come to rival those of ScrumWorks in short order.
When we look at reporting functionality, ScrumWorks comes out ahead. ScrumWorks has a custom report generator utility that allows you to create your own customized reports. All of Rally’s reports are fixed and can’t be changed or added to. Once again, Rally is acutely aware of this issue and not likely to let it rest for long.
Cross Team & Program Management – Both products claim to have some cross team and program management features. Neither product really possesses a strong feature set in this domain. Rally defines a program as a combination of a specified product and a specified release – a very loose definition. ScrumWorks uses a separate mechanism that is completely orthogonal to the Stories and releases – instead you can create arbitrary groupings of features which can represent programs. This is a more flexible approach, but it still doesn’t provide the financial tracking features that I would expect from a full fledged portfolio management tool.
Detailed Feature Comparison
|
Feature |
Rally |
ScrumWorks Pro |
|
Desktop (Fat) Client |
No |
Yes |
|
Web (Thin) Client |
Yes |
Yes – Not all desktop features are available on the web client |
|
Local Database |
No – hosted by a 3rd party |
Yes – Built into the default installation |
|
Impediments Log |
No |
Yes – Tracks dates, resolution, and responsibility |
|
Records blocking issues |
Yes |
Yes |
|
Burn Down Charts |
Yes – Sprint Burndown/Cumulative flow, Release burndown/cumulative flow, Bug & Test Tracking |
Yes – Mike Cohn style ‘enhanced burndown’, Sprint & Release burndown |
|
Customized Reports |
No |
Yes – Customizable report builder GUI |
|
ROI and EVA |
No |
Yes |
|
Time Tracking |
Yes – optional |
Yes – optional, but supported with custom reports |
|
Supported Object Types |
Release, Sprint, Story, Task, Test, Program, Defect, Defect Suite |
Release, Sprint, Story, Task, Theme, Program |
|
Supported Methodologies |
RUP, Scrum, XP |
Scrum, XP |
|
Drag n’ Drop UI |
Limited to certain screens |
Used almost universally |
|
Hierarchical Relationships |
Yes |
No – Uses themes instead |
|
Built in collaboration features |
Yes – Wiki & IM integration |
No |
|
Test management |
Yes |
No |
|
Defect management |
Yes |
No |
|
Program Management Features |
Release Status – not really configurable |
Release Status + configurable feature sets, Good cross product functionality |
|
Sprint Task Tracking |
Yes |
Yes – nice web based task board UI |
|
Assign Business Value |
No |
Yes |
|
Product and Role based permissions |
Yes |
Yes |
|
LDAP Integration |
No |
Yes |
|
Import/Export |
Yes – Excel, XML |
Yes – Excel |
|
Supports Use Cases/Non-functional requirements |
Yes |
No |
|
Notifications |
Yes – RSS, email |
No |
|
Detailed Change History |
Yes |
No – very superficial |
|
Product Integration |
Eclipse, Mercury, Salesforce, Bugzilla |
Bugzilla, JIRA |
|
Pricing |
$65/person/month |
$249/person/year ($21/month) |
|
Admin functions |
User accounts, Roles, Custom features, Workspace management |
User accounts, Roles |
|
Hardware Requirements |
None – externally hosted |
Server must be allocated for clients & web app to connect with |
|
Frequency of Updates |
Quarterly |
Quarterly |
|
Built-in Support for pairing time management |
No |
Yes – There are “Team hours” and “individual hours” |
|
Usability for teams |
OK, some complain of delays and there are complaints about charts |
Good, The thick client offers more natural DnD style of interface – good web interface for task board – natural for teams to adopt |
|
Multiple Teams/Common Backlog |
Possible, but awkward |
Pretty well thought out |
|
Support |
Online, Forums, Coaching, Training |
Online, Forums |
|
Integration Technical Options |
REST, SOAP, Others |
SOAP |
January 9, 2008 at 9:37 pm |
Hello Tom!
Thanks for this evaluation.
Hope all is well!
Best regards,
Laszlo
January 25, 2008 at 4:36 pm |
I think I agree generally with this evaluation (we have been using Scrumworks for a sprint and a half), but the “customization” in reports in Scrumworks is quite limited, to the point of not being very useful as far as I can tell.
I’ve been trying to figure out if I can get what I want from Scrumworks, which is a detailed Product Burndown Graph, showing daily engineer progress against the product backlog, something that Rally just added, see: http://www.rallydev.com/Support_Video/release_training_2007_7/burndown.html.
I asked Scrumworks for this feature, not knowing Rally was going to release it.
I think it’s illustrative to talk about Scrumworks’ reaction to my request, which is that they understand why I want it, but because it is not in the formal Scrum process, they won’t consider it. For rigid purists, that might be a good thing if they think it enforces a policy. For others, of course, it’s not so good. In my mind, it’s really just a different (and useful) way to look at the information that Scrumworks has collected.
In any event, your mileage may vary. I was turned off by my interaction with the Scrumworks folks, but whether that is enough to push me away from using the product, I’m not sure yet.
April 15, 2008 at 3:29 pm |
[...] Tools: XPlanner, Rally, Scrumworks Pro, Thoughtworks Mingle, and Card Meeting. The instructor said non of the tools handles hierarchical backlogs. See also Rally vs Scrumworks. [...]
April 19, 2008 at 12:54 pm |
Rally handles hierarchical backlogs – if I understand what is meant by a hierarchical backlog correctly
October 10, 2008 at 12:04 pm |
Hello everybody,
please have a look at Agilo for Scrum as well. http://www.agile42.com/cms/pages/download/
Its open source and was created based on real customer needs
Have fun
agile
October 16, 2008 at 9:08 pm |
Thanks Tom!
There have many information and very useful.
Regards,
February 26, 2009 at 12:17 pm |
Nice comparison-what about a comparison with VersionOne-another Agile project management tool? http://www.versionone.com I have heard good things about it, so would be nice to see a comparison as well.
February 26, 2009 at 1:52 pm |
Good idea – I just haven’t gotten around to it yet.
Thanks!
June 24, 2009 at 3:40 pm |
I’d LOVE to see you compare Rally to TargetProcess.
I’ve been evaluating Rally vs. ScrumWorks vs. TargetProcess, and having a hard time deciding.
VersionOne would probably work, but I was turned off by its UI (too many pointless popups – clicking entities gives ‘property’ popups that are too generic and not ‘use oriented’). It also has a lack of customizable reports, and erratic performance.
Rally loses points for not allowing us to host our own server unless we by a minimim of 50 user licenses. We’re not that big, but are paranoid about security.
ScrumWorks’ strict adherence to Scrum is both good and bad. It is almost too simple – in fact, for us, it’s ‘the simplest thing that could work’. I am finding the ‘customizable’ reports pretty limiting – I want to make my own modules to plug into the report system! The ability to display those reports via the web, and link directly to images within from other web pages (or wikis, etc) is pretty awesome though. We use that feature to mashup multiple burndown charts onto information radiators in the hallway. If you ask them to do add REAL customizable reports, they tell you ‘everything in the system is already reportable with our modules – use the SOAP interface if you need more’. They don’t seem interested in widening their product feature set much (but they do seem interested in making sure what features set they DO have is usable and performant).
August 4, 2009 at 8:26 pm |
Hi Jeff,
Thanks for the comments about ScrumWorks – it’s really exciting for us to help build a product that the community can use. We are working hard on expanding the Enterprise capabilities of ScrumWorks, as noted in our recent press coverage: http://tinyurl.com/m8uwb6
PS – feel free to give us a call and we’ll work with you.
September 22, 2009 at 4:18 am |
[...] http://agiletools.wordpress.com/2007/12/04/rally-vs-scrumworks/ [...]