Good Afternoon!

As there were no posts in this forum I thought I'll make one up  

 I am new to OnTime but have worked in a agile environment of sorts for a while. I would be interested if and how other users configure their OnTime workspace to tie in more closely with the iterative nature of agile developement. I am toying with the idea to use OnTime not only for bug tracking at a later stage but also to manage tasks/features/time etc. during agile developement. I've been looking for an agile development management tool for a while but they are either only avaialble online (which is a non starter for me) or very expensive. Has anyone tried something like this with OnTime before and how did you do it?

Thanks,

Mike

I've been working on setting up Ontime for an Agile methodology - initially for new development, not bug tracking.  The first challenge, it seems, is deciding what to define as a project (or sub-project if you want). Lets say we are working on a single major software application where we are planning quarterly releases of new or improved functionality.

We can simply list each new feature as a project when it is identified. We can select the features for the first quarterly release and target those for development. At release time we can gather the features that are actually completed and package them for release.  But this approach doesn't really add much help to the Agile process. The Agile iterations are not easlily identified anywhere.

Alternatively, we can create a Project for each quarterly release and create new features as Sub-projects.  This requires that we know the plan and the development results for the features to be wrapped into a quarterly release before we add a feature. (Perhaps we can move these as necessary later).  This ties our Agile iterations nicely together, but looses any connection between changes to a feature.

Future changes to a feature can result from bugs (lets skip that here), additional functionality, or simple planning to deliver part of a feature before other parts. Some technique is necessary to tie together these partial feature developments. For information purposes it is valuable to be able to find the various pieces of work that have been done on each application feature.

A clear vision of the project and sub-project objectives is necessary to gain any value from using OnTime with Agile Methodologies.

I'm currently trying to figure the best way to use OnTime with Scrum and here's what I've come up with so far (it's important to keep in mind that none of this has progressed beyond the theoretical yet at this point, and I'm neither a ScrumMaster nor an OnTime expert.):

• Product Backlog = list of Features
• Feature item type = Requirement
• The Product Owner and Customer primarily view  the Project at this level
  
• Tasks are performed during Sprints to implement the Requirements included in the Sprint Backlog
• Developers primarily work at this level
• Tasks are created by the developers as they work on implementing Requirements ( not created until the Sprint planning session)
• Developers log all time worked and maintain estimated remaining work against Tasks (this allows incomplete Requirements to be moved around between Sprint folders w/o losing the Sprint work was actually performed in).
• Tasks are listed as Related Items under the appropriate Requirement
  

 Project Folder Hierarchy:

• Root folder = Project (same as usual)
• A new folder is created for each Release below the Root folder.
  
• A new folder is created for each Sprint inside the appropriate Release folder
• All Product Backlog items are initially kept in a at the project's root level
• Requirements are moved to a specific Release or Sprint folder during Release or Sprint planning sessions
  
• Add a custom field called Component to Requirements, Defects & Tasks to keep track of the screen, page, etc that the Item is related to. This allows you to group all Items related to a particular feature together without having to know your exact component folder structure upfront
  

Again this hasn't been tested in the Wild yet, but  In thinking it might work. I'd love to get anyone's feedback or suggestions.

One problem I see, that I don't know a way around, is moving features. I don't think it's easy in Ontime to move a feature to another project. I've had to copy a feature then cancel the original.

It seems like you are creating a lot of "buckets".  I only create sub-project folders for major modules of my application. Can't you use the Version field for each minor release? That information gets old fast after the release date. Then it would be better not to have it in separate buckets. This keeps your "components" together.

I've been thinking about this general issue too.

You first issue is easily solved by changing the project either by editing the item, or using multi edit on a number of its and changing the project.
Copy and move are only required if you need to duplicate the items or change them from a feature to a bug or a task. Or you copy if you want to split an item into two.

In terms of buckets, I have seen this dilemma too. You either use the projects to split your product up into parts (which are not separately released items), or you split it up into different releases. One alternative is to add custom fields to split items into areas/modules etc, but this may not be as "nice", but at least you view from both angles. e.g view all items for this module (by selecting top most porject and grouping or filtering by your custom field), or view by release/iteration, or view by both.

I haven't (yet) used releases and iterations as projects but I have been toying with the idea

I have also thought about this and I also don't like to use projects as 'buckets' and drag features and defects across every time. For us projects are software products and their subfeatures that we are working on. What I was asking Axosoft for some time now is to create another Planning tab (or view) perhaps. Possibly, have ability to define iteration duration (2 weeks, 1 months, 3 months etc.). Then it would have some sort of calendar view, where I can select next iteration for example. And then drag (or search) and drop features, tasks, defects into it, thus not copying but linking them to this iteration.

It should show me who is the person assigned to it and Estimated Hours (must be filled in of course), so that we can work out the workload for that person and whether it can be done in this iteration (or changes need to be made, such as re-assign to another person or move to next iteration etc.). So it kind of becoms planning module. So it is more than just User Dashboard where we can see what this person is assigned to do, but it will answer what is to be done in the next iteration. Although we are not formally use Agile methods here, we do require planning and it is hard to do by Priorities only, since person assigned can have more than 10 items with high priority. So we end up using e-mail to follow up Ontime e-mails, basically saying - Developer X, please work this week on Ontime items 23,45,67 and 78 etc. This is not really good method.

I think Ontime would benefit greatly from this, and it is not all that hard to do I think.

Obviously, would also need to create report that can be printed to see iteration list of features, Assignments and estimates. Perhaps then Release Version can be done by iteration automatically (defined once at the top) and all release notes also be easily published from that view (listing all items that made to this release).

What does Axosoft think about it?

Ted Lushchayev

Sattel, Australia

I've been asking for project planning features as well.  I think OT currently only scratches the surface of project/product management.  We use projects in OT to reflect products or product lines (made of multiple products).  Each use case or other type of requirements is a separate Feature ticket under the product folder.  We created a "Planned Iteration" custom field.  We can filter tickets based on iterations or create a release filter to capture several iterations in a specific release.  Works OK, but it means creating filters for each project and for each ticket type.  Yuck - over time, especially since not all projects are on the same iteration.  Some are I33 some are I1, so we have dozens of filters.  Would be great(!) if filters were project specific.  Then we wouldn't have a list with 100 filters that didn't apply to your project.

Some teams created a "Backlog" folder, but to me, Backlog isn't a physical thing, its a view of tickets: one of the opened statuses plus no defined Iteration field.  We have a "type" for features to designate use cases, change requests, QoS, and other classes of requirements.  We can then relate defects to features, change requests to use cases, etc., etc. 

It would be great if OT let us define iterations with different dates for each project.  There should also be Releases defined for each product, also with variable dates, which can include 1 or more iterations.  The project status windows, reports, dashboard, etc. should be able to use the defined iterations or releases for filters. 

I know I'm asking a lot, but there's more.  How about built in integration with both MS Project and MS Project Server.  Would be sweet to point to a project, select a release or iteration and "Create Project Plan."  An MPP file would be created with a Ticket Type and Ticket ID column so we could reference the OT tickets and maybe round trip some information. 

 Then we need a burn down chart!  As developers and other works start logging time, OnTime uses the data to compare against iteration/release dates, staff assigned to the project, and iteration number to create a burndown chart showing how much effort is left in the iteration vs. how many scheduled hours are left.

Here's how I am using OnTime for Scrum:

1. I create a project (or sub-project) for my new project
2. I have versioning setup for each project (create projects picklist, then sub picklists for build number, build number of fix etc.). Then, I create a field template so that I can associate the project with the correct version listing & other custom fields.
3. Every request (or bug report as the project advances) gets entered as an incident - "Incident Reported" workflow step. This is my product backlog. Everytihng within this workflow step is not being worked on presently and is simply backlog.
4. At the beginning of every iteration the owner of the project prioritizes the incidents and I as the developer let the owner know how many items (in the priority listed) i will commit to for the upcoming iteration.
5. The incidents that I commit to get their Workflow Step changed to "Incident Approved"
6. I then go into each incident that I have committed to and add the necessary related items (bugs, features, tasks etc.)
7. Requests always go through the project owner who enters every request as an incident. The project owner is the only one who can prioritize the list.

Works pretty well for me, just wish there was more of a storycarding way of doing things in OnTime

jfkrueger