Entity Relationships

Those are some good questions. I'm getting ready to plan out the next set of updates, and these will be some good things to consider.

The reason issues are not deleted when a project is deleted is because the project selection is treated as a classification for an issue, but not as a container for the issue. So, when the project is deleted, nothing happens to any of the issues. It would be really simple to add a system configuration option which deletes issues belonging to a project when a project is deleted. I'll make a note of that.

I think a couple things could help you manage multiple projects they way you're describing. A Project filter can be added to both the iteration and releases tabs. You would be able to select projects which have been assigned to a release, and that would filter the list of iterations and releases displayed. It sounds like you'd also like a Releases tab for projects, and an Iterations tab for projects.

I personally, haven't managed multiple projects that are on different iteration/release schedules in a single AgileTrack database. I can probably get an update to you with those additional views, within a week. Do you think that would help?

If you have other suggestions for how the tool can be made better, please pass them on. Thanks.

We manage multiple projects in AgileTrack, and to make it more interesting those projects are for various different companies. That's why we would love to have "Organization" as a project type in order to better manage that. Anyway, the way we deal with releases and iterations is that, well, we don't use them. It's something we want to get to eventually but never seem to do. But even so, AgileTrack is great for managing issues and tasks, especially the time spent.

James

My need is for a project focus. We are a team of 3 developing and supporting 24 applications. Some of those are core projects that are used by several other projects. We also need to support our user base of about 25,000 with any problems they have.

I am not able to work on a single project for very long as I am always switching between projects. So when I walk in the door everyday I need to find out what is deemed *important* today and focus on those tasks. Planning is pretty much useless though I am making an effort to change this.

Some of the things I want from a tool like AgileTrack include:

• Allow project stakeholders to track project progress online
• Create high level plan of project containing major milestones for those managers who refuse to read anything that is not on paper.
• Create requirements/features document from project plan that again can be given to those managers that blah, blah, blah… which can also be used to get a new person up to speed on the project. Or better yet, or in addition to, creating the same as a web site that could be included as part of the project site. We started using Maven for builds and for project site generation along with a project wiki for supporting artifacts.
• Having a project focus.
• Having a project node that acts as a container rather than a tag.
• Allow management of project node tags. For example, I would like to have a feature node that is broken up into user stories. I could then plan to implement a feature as part of a release by assigning stories from that feature to iterations of the release. That doesn't mean that stories from a feature could not be spread across releases if it makes sense.
• Ability to plan iterations, releases, and projects visually using drag and drop. This would allow me to visualize timelines for iterations, releases, and projects being developed in parallel or in serial. This would help plan over months and years.

I think these are tall orders and may not be inline with your goals for AgileTrack and I don't think that they necessarily should be. I think simplicity is always best. It's just I am in a very complex environment that lives to squash simplicity and reason at every turn.

When dealing with Agile Track it is best to quote my cousin Bart, "Don't do as Johnny Don't does." Great advice I find.

Thanks for those comments. It's difficult to keep things simple and still accommodate complex needs and uses. Up to this point, AgileTrack has focused mostly at dealing with "issues" and everything revolves around classifying issues. I'd like the project, iterations, and releases to provide more capability, but don't want to them to dictate process too much.

AgileTrack tries capture information in a flexible way, but let users decide their own process and workflow. It works best at this point with small teams, and its interface isn't geared toward high-level management views. It's evolving over time.

I've very much wanted to create a unique visual planning interface, but haven't got to that point. Iterations/releases need to be reworked to handle different project and schedules. A web interface has been in the works for a while, but still isn't ready.

Thanks for the feedback.