Thanks for responding, Gareth.
I know some of the folks at Danube, and I have looked at ScrumWorks. It is a great tool, but we wanted process and status transparency throughout the office. We could only get that through a tool like OnTime.
In our office, we have customized OnTime to work with Scrum, and it works well, but honestly Axosoft knows nothing of Scrum, and they are unwilling to tweak the product to support Scrum. I really doubt that many Scrum shops are using OnTime, but that would change quickly if Axosoft were willing to listen to their customer base.
To use OnTime with Scrum, we relabeled "Features" as "Product Backlog", "Tasks" as "Sprint Backlog". We track Impediments through Incidents, however we did not relabled Incidents, as Incidents are also used by customer support. We leveraged user-defined fields to denote teams and members and used the workflows to drive QA and customer interaction.
The major drawbacks are...
- There reporting tool cannot be used to create burndown charts. We create them all using Microsoft Reporting Services and have the automatically e-mailed to team members. We also had to store some data outside of their database tables, as the historical data needed for burndown charts is not tracked by OnTime.
- The Customer Portal does not include Tasks, so Sprint Backlog Items cannot be viewed by customers acting as members (either Pigs or Chickens) of your Scrum team.
- There is no support for calculated user-defined fields, so we had to create a trigger on the database to calculate time remaining.
- Some of their fields (like Estimated and Actual Duration) are not used by Scrum, but OnTime's canned reports, Quick Add Task Bar, etc. expect these fields to be used and cannot be redirected to use user-defined fields.
Everything else—with the aid of a few user-defined fields and custom workflows—works perfectly.
HL Arledge